Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1323352 > unrolled thread

[PATCH 00/11] arm64: Introduce Allwinner A64 and Pine64 support

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/11] arm64: Introduce Allwinner A64 and Pine64 support Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:40 +0100
    [PATCH 06/11] clk: sunxi: add generic multi-parent bus clock gates driver Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [PATCH 06/11] clk: sunxi: add generic multi-parent bus clock  gates driver Jean-Francois Moine <moinejf@free.fr> - 2016-02-01 19:50 +0100
        Re: [PATCH 06/11] clk: sunxi: add generic multi-parent bus clock  gates driver André Przywara <andre.przywara@arm.com> - 2016-02-02 00:10 +0100
    [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC  .dtsi Karsten Merker <merker@debian.org> - 2016-02-01 20:10 +0100
        Re: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC  .dtsi André Przywara <andre.przywara@arm.com> - 2016-02-02 00:10 +0100
      Re: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC  .dtsi Jens Kuske <jenskuske@gmail.com> - 2016-02-02 17:30 +0100
        Re: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC  .dtsi Andre Przywara <andre.przywara@arm.com> - 2016-02-02 17:50 +0100
          Re: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC  .dtsi Jens Kuske <jenskuske@gmail.com> - 2016-02-02 18:50 +0100
          Re: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi Chen-Yu Tsai <wens@csie.org> - 2016-02-05 10:00 +0100
      Re: [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-02-05 10:00 +0100
        Re: [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi Andre Przywara <andre.przywara@arm.com> - 2016-02-08 10:50 +0100
    [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      [tip:irq/urgent] irqchip/sun4i: Fix compilation outside of arch/  arm tip-bot for Andre Przywara <tipbot@zytor.com> - 2016-02-02 16:00 +0100
      Re: [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm Matthias Brugger <matthias.bgg@gmail.com> - 2016-02-02 16:20 +0100
        Re: [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm Andre Przywara <andre.przywara@arm.com> - 2016-02-02 16:40 +0100
          Re: [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm Matthias Brugger <matthias.bgg@gmail.com> - 2016-02-02 18:00 +0100
    [PATCH 08/11] clk: sunxi: improve error reporting for the mux clock Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [PATCH 08/11] clk: sunxi: improve error reporting for the mux  clock Andre Przywara <andre.przywara@arm.com> - 2016-02-02 19:10 +0100
      Re: [PATCH 08/11] clk: sunxi: improve error reporting for the mux  clock Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-02-02 19:10 +0100
    [PATCH 07/11] clk: sunxi: add generic allwinner,sunxi name Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [PATCH 07/11] clk: sunxi: add generic allwinner,sunxi name Rob Herring <robh@kernel.org> - 2016-02-08 17:00 +0100
        Re: [PATCH 07/11] clk: sunxi: add generic allwinner,sunxi name Andre Przywara <andre.przywara@arm.com> - 2016-02-08 17:10 +0100
    [PATCH 11/11] arm64: dts: add Pine64 support Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [linux-sunxi] [PATCH 11/11] arm64: dts: add Pine64 support Karsten Merker <merker@debian.org> - 2016-02-01 20:30 +0100
        Re: [linux-sunxi] [PATCH 11/11] arm64: dts: add Pine64 support André Przywara <andre.przywara@arm.com> - 2016-02-02 00:10 +0100
      Re: [PATCH 11/11] arm64: dts: add Pine64 support Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-02-05 10:10 +0100
        Re: [PATCH 11/11] arm64: dts: add Pine64 support Andre Przywara <andre.przywara@arm.com> - 2016-02-05 11:10 +0100
          Re: [linux-sunxi] Re: [PATCH 11/11] arm64: dts: add Pine64 support Julian Calaby <julian.calaby@gmail.com> - 2016-02-08 02:00 +0100
    [PATCH 04/11] arm64: Introduce Allwinner SoC config option Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [PATCH 04/11] arm64: Introduce Allwinner SoC config option Matthias Brugger <matthias.bgg@gmail.com> - 2016-02-02 16:30 +0100
        Re: [PATCH 04/11] arm64: Introduce Allwinner SoC config option Andre Przywara <andre.przywara@arm.com> - 2016-02-02 16:40 +0100
          Re: [PATCH 04/11] arm64: Introduce Allwinner SoC config option Arnd Bergmann <arnd@arndb.de> - 2016-02-02 17:10 +0100
    [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Karsten Merker <merker@debian.org> - 2016-02-01 19:30 +0100
        Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for  Allwinner A64 SoC Karsten Merker <merker@debian.org> - 2016-02-01 19:50 +0100
          Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for  Allwinner A64 SoC André Przywara <andre.przywara@arm.com> - 2016-02-02 00:10 +0100
        Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC André Przywara <andre.przywara@arm.com> - 2016-02-02 00:00 +0100
          Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver  for Allwinner A64 SoC Siarhei Siamashka <siarhei.siamashka@gmail.com> - 2016-02-02 03:00 +0100
            Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for  Allwinner A64 SoC Andre Przywara <andre.przywara@arm.com> - 2016-02-02 15:30 +0100
            Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for  Allwinner A64 SoC Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-02-02 18:40 +0100
          Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-02-02 11:10 +0100
            Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Chen-Yu Tsai <wens@csie.org> - 2016-02-02 11:20 +0100
            Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Andre Przywara <andre.przywara@arm.com> - 2016-02-02 18:00 +0100
              Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-02-04 20:00 +0100
                Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Andre Przywara <andre.przywara@arm.com> - 2016-02-08 17:00 +0100
                Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Rob Herring <robh@kernel.org> - 2016-02-08 17:00 +0100
    [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit Herbert Xu <herbert@gondor.apana.org.au> - 2016-02-02 04:20 +0100
      Re: [linux-sunxi] [PATCH 02/11] crypto: sunxi-ss: prevent  compilation on 64-bit LABBE Corentin <clabbe.montjoie@gmail.com> - 2016-02-02 09:50 +0100
      Re: [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit Herbert Xu <herbert@gondor.apana.org.au> - 2016-02-06 08:50 +0100
    [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for all sunxi SoCs Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
      Re: [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for  all sunxi SoCs Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-02-02 10:50 +0100
      Re: [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for  all sunxi SoCs Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-02-05 00:00 +0100
    [PATCH 09/11] clk: sunxi: add critical-clocks property to mux clocks Andre Przywara <andre.przywara@arm.com> - 2016-02-01 18:50 +0100
    Re: [PATCH 00/11] arm64: Introduce Allwinner A64 and Pine64 support André Przywara <andre.przywara@arm.com> - 2016-02-02 09:20 +0100
    Re: [PATCH 00/11] arm64: Introduce Allwinner A64 and Pine64 support lists.nick.betteridge@gmail.com - 2016-02-02 09:40 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#1324122 — Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

Hi,

On 02/02/16 01:58, Siarhei Siamashka wrote:
> On Mon, 1 Feb 2016 22:49:16 +0000
> André Przywara <andre.przywara@arm.com> wrote:
> 
>> On 01/02/16 18:27, Karsten Merker wrote:
>>
>> Hi Karsten,
>>
>> thank you very much for your feedback!
>>
>>> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:  
>>>> Based on the Allwinner A64 user manual and on the previous sunxi
>>>> pinctrl drivers this introduces the pin multiplex assignments for
>>>> the ARMv8 Allwinner A64 SoC.
>>>> Port A is apparently used for the fixed function DRAM controller, so
>>>> the ports start at B here (the manual mentions "n from 1 to 7", so
>>>> not starting at 0).
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>>>>  arch/arm64/Kconfig.platforms                       |   1 +
>>>>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>>>>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>>>>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
>>>>  5 files changed, 613 insertions(+)
>>>>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> index 9213b27..9050002 100644
>>>> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> @@ -21,6 +21,7 @@ Required properties:
>>>>    "allwinner,sun9i-a80-r-pinctrl"
>>>>    "allwinner,sun8i-a83t-pinctrl"
>>>>    "allwinner,sun8i-h3-pinctrl"
>>>> +  "allwinner,a64-pinctrl"  
>>>
>>> Hello,
>>>
>>> on all other Allwinner SoCs we use the SoC family as part of the
>>> compatible, as well as in the names of the Kconfig options. To
>>> keep things consistent, I would like to propose doing the same on
>>> Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
>>> allwinner,a64-pinctrl.  
>>
>> Yes, I have been told this already. However I don't like this idea so
>> much, for the following reasons:
>> a) It is mostly redundant. The actual SoC (marketing) name is unique,
>> there is no sun6i-a20 or sun7i-a23.
>> b) It is not even helpful. If I got Maxime correctly, then the newer
>> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
>> which is frankly the least interesting part from a Linux support
>> perspective. I would see some sense if it would reflect the generation
>> of IP blocks used, but so it is even more confusing to see that
>> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
>> different beast. The Allwinner marketing name tells you that, but the
>> sunxi one does not.
>> c) It is very confusing for people not dealing with it everyday. Just
>> because I own a BananaPi I know that the A20 is sun7i, but I am totally
>> lost when it comes to all the other names. And even now it took me about
>> a minute to find the appropriate Wiki page which explains part of that
>> story.
>> d) Most importantly ;-): It kills TAB completion, unless you know the
>> sunxi number, which is mostly not true as pointed out in c)
>>
>> So while I see that just a<somenumber> is not really very specific, I'd
>> rather do away with current naming scheme for the future. In this
>> particular case we have the vendor name as a name space identifier
>> already, so there is no possible confusion with ARM Cortex naming, for
>> instance.
>>
>> Also as this is now moving into the arm64 world, I'd like to use the
>> opportunity to fix things that are not really optimal, the naming is one
>> of them.
> 
> One of the problems is that A64 name is not unique. We have reasons
> to believe that there are also H64 and R18 out there using exactly
> the same die, but possibly available in different packaging (a different
> ball grid pitch? or maybe a different set of peripherals routed to the
> outside?). Early prototypes of the Pine64 board were using Allwinner R18
> and the Jide Remix Mini HTPC box is using Allwinner H64.

So if the differences are actually hidden from software, why would we
care? See below for an example on using DT to cover this.

> The bootloader sources from Allwinner are also referring to A64 as
> AW1689, which makes some sense because it is the chip id number that
> is accessible for runtime identification via reading the SRAM_VER_REG
> hardware register:
> 
>     http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG
> 
> So would it be a good idea to use "aw1689" as a compatible property
> in the DT instead of "a64"? Or maybe have "aw1689-a64" and
> "aw1689-h64", which would be similar to the existing "sun5i-a13"
> and "sun5i-a10s" naming convention?

I would be fine with that if it really reflects something in the
hardware. And I like it more than the rather arbitrary sun50i name. But
on the other hand it seems to be completely unknown so far (Google just
turns up this email and your sunxi-fel setup, basically). So I am not
sure we should introduce yet another naming scheme.

So looking at the compatible definition in the DT, this looks like a
perfect example of a fall-back name to me:
For the Pine64 we use "allwinner,a64", any other board could use say a:
"allwinner,h64", "allwinner,a64" compatible naming.
So as long as we don't need any h64 specifics, going with the A64
support code is fine. Should later the need arise to fix something for
the H64 only, we can add this easily and be covered automatically.

FWIW, I just have received this Remix Mini PC thing, which I ordered to
see what's with the H64 and to make sure the SoC/board abstraction is
right. So let me see what this version register looks like there and how
it behaves with the proposed kernel patches (should I be able to hack it).

Cheers,
Andre.

[toc] | [prev] | [next] | [standalone]

#1324325 — Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Tue, Feb 02, 2016 at 03:58:52AM +0200, Siarhei Siamashka wrote:
> > > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:  
> > >> Based on the Allwinner A64 user manual and on the previous sunxi
> > >> pinctrl drivers this introduces the pin multiplex assignments for
> > >> the ARMv8 Allwinner A64 SoC.
> > >> Port A is apparently used for the fixed function DRAM controller, so
> > >> the ports start at B here (the manual mentions "n from 1 to 7", so
> > >> not starting at 0).
> > >>
> > >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > >> ---
> > >>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
> > >>  arch/arm64/Kconfig.platforms                       |   1 +
> > >>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
> > >>  drivers/pinctrl/sunxi/Makefile                     |   1 +
> > >>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
> > >>  5 files changed, 613 insertions(+)
> > >>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > >> index 9213b27..9050002 100644
> > >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > >> @@ -21,6 +21,7 @@ Required properties:
> > >>    "allwinner,sun9i-a80-r-pinctrl"
> > >>    "allwinner,sun8i-a83t-pinctrl"
> > >>    "allwinner,sun8i-h3-pinctrl"
> > >> +  "allwinner,a64-pinctrl"  
> > > 
> > > Hello,
> > > 
> > > on all other Allwinner SoCs we use the SoC family as part of the
> > > compatible, as well as in the names of the Kconfig options. To
> > > keep things consistent, I would like to propose doing the same on
> > > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
> > > allwinner,a64-pinctrl.  
> > 
> > Yes, I have been told this already. However I don't like this idea so
> > much, for the following reasons:
> > a) It is mostly redundant. The actual SoC (marketing) name is unique,
> > there is no sun6i-a20 or sun7i-a23.
> > b) It is not even helpful. If I got Maxime correctly, then the newer
> > sunxi generation numbers depend on the ARM _cores_ used in the SoC,
> > which is frankly the least interesting part from a Linux support
> > perspective. I would see some sense if it would reflect the generation
> > of IP blocks used, but so it is even more confusing to see that
> > sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
> > different beast. The Allwinner marketing name tells you that, but the
> > sunxi one does not.
> > c) It is very confusing for people not dealing with it everyday. Just
> > because I own a BananaPi I know that the A20 is sun7i, but I am totally
> > lost when it comes to all the other names. And even now it took me about
> > a minute to find the appropriate Wiki page which explains part of that
> > story.
> > d) Most importantly ;-): It kills TAB completion, unless you know the
> > sunxi number, which is mostly not true as pointed out in c)
> > 
> > So while I see that just a<somenumber> is not really very specific, I'd
> > rather do away with current naming scheme for the future. In this
> > particular case we have the vendor name as a name space identifier
> > already, so there is no possible confusion with ARM Cortex naming, for
> > instance.
> > 
> > Also as this is now moving into the arm64 world, I'd like to use the
> > opportunity to fix things that are not really optimal, the naming is one
> > of them.
> 
> One of the problems is that A64 name is not unique. We have reasons
> to believe that there are also H64 and R18 out there using exactly
> the same die, but possibly available in different packaging (a different
> ball grid pitch? or maybe a different set of peripherals routed to the
> outside?). Early prototypes of the Pine64 board were using Allwinner R18
> and the Jide Remix Mini HTPC box is using Allwinner H64.
> 
> The bootloader sources from Allwinner are also referring to A64 as
> AW1689, which makes some sense because it is the chip id number that
> is accessible for runtime identification via reading the SRAM_VER_REG
> hardware register:
> 
>     http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG
> 
> So would it be a good idea to use "aw1689" as a compatible property
> in the DT instead of "a64"? Or maybe have "aw1689-a64" and
> "aw1689-h64", which would be similar to the existing "sun5i-a13"
> and "sun5i-a10s" naming convention?

If someone cannot find out the family name that is documented on
several places, I'm not sure he'll find the obscure, internal code
name.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1323920 — Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

[Multipart message — attachments visible in raw view] — view raw

Hi Andre,

On Mon, Feb 01, 2016 at 10:49:16PM +0000, André Przywara wrote:
> On 01/02/16 18:27, Karsten Merker wrote:
> 
> Hi Karsten,
> 
> thank you very much for your feedback!
> 
> > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:
> >> Based on the Allwinner A64 user manual and on the previous sunxi
> >> pinctrl drivers this introduces the pin multiplex assignments for
> >> the ARMv8 Allwinner A64 SoC.
> >> Port A is apparently used for the fixed function DRAM controller, so
> >> the ports start at B here (the manual mentions "n from 1 to 7", so
> >> not starting at 0).
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >> ---
> >>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
> >>  arch/arm64/Kconfig.platforms                       |   1 +
> >>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
> >>  drivers/pinctrl/sunxi/Makefile                     |   1 +
> >>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
> >>  5 files changed, 613 insertions(+)
> >>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> index 9213b27..9050002 100644
> >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> @@ -21,6 +21,7 @@ Required properties:
> >>    "allwinner,sun9i-a80-r-pinctrl"
> >>    "allwinner,sun8i-a83t-pinctrl"
> >>    "allwinner,sun8i-h3-pinctrl"
> >> +  "allwinner,a64-pinctrl"
> > 
> > Hello,
> > 
> > on all other Allwinner SoCs we use the SoC family as part of the
> > compatible, as well as in the names of the Kconfig options. To
> > keep things consistent, I would like to propose doing the same on
> > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
> > allwinner,a64-pinctrl.
> 
> Yes, I have been told this already. However I don't like this idea so
> much, for the following reasons:
> a) It is mostly redundant. The actual SoC (marketing) name is unique,
> there is no sun6i-a20 or sun7i-a23.

At the same time, the family name is mostly valid too.

We do share some DTSI across some SoCs already by their family name
(sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and
A33, etc.)

> b) It is not even helpful. If I got Maxime correctly, then the newer
> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
> which is frankly the least interesting part from a Linux support
> perspective. I would see some sense if it would reflect the generation
> of IP blocks used, but so it is even more confusing to see that
> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
> different beast. The Allwinner marketing name tells you that, but the
> sunxi one does not.

The opposite can be said too.

The A31 is quite different from the A33, while the A83 is much closer
to the H3 than it is to the A80. Their marketing scheme is messy. In
all aspects. We have a scheme that worked, I'd really like to stick
with it.

> c) It is very confusing for people not dealing with it everyday. Just
> because I own a BananaPi I know that the A20 is sun7i, but I am totally
> lost when it comes to all the other names. And even now it took me about
> a minute to find the appropriate Wiki page which explains part of that
> story.
> d) Most importantly ;-): It kills TAB completion, unless you know the
> sunxi number, which is mostly not true as pointed out in c)

Both of these are true, but are about the DT filenames, and not the
compatibles. I'd agree with you on this one now that we have
per-vendor subfolders in boot/dts, but it was not the case before, and
I'm pretty sure that to anyone that is not aware of the Allwinner SoCs
names, having an A<number>.dtsi in arch/arm/boot/dts, it would be
about a Cortex-A<number>, and definitely not an SoC from some random
vendor.

So, droping it in the filenames, why not. But I'd really like to keep
the same compatible scheme.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1323939 — Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

On Tue, Feb 2, 2016 at 6:00 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Andre,
>
> On Mon, Feb 01, 2016 at 10:49:16PM +0000, André Przywara wrote:
>> On 01/02/16 18:27, Karsten Merker wrote:
>>
>> Hi Karsten,
>>
>> thank you very much for your feedback!
>>
>> > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:
>> >> Based on the Allwinner A64 user manual and on the previous sunxi
>> >> pinctrl drivers this introduces the pin multiplex assignments for
>> >> the ARMv8 Allwinner A64 SoC.
>> >> Port A is apparently used for the fixed function DRAM controller, so
>> >> the ports start at B here (the manual mentions "n from 1 to 7", so
>> >> not starting at 0).
>> >>
>> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> >> ---
>> >>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>> >>  arch/arm64/Kconfig.platforms                       |   1 +
>> >>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>> >>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>> >>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
>> >>  5 files changed, 613 insertions(+)
>> >>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> >> index 9213b27..9050002 100644
>> >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> >> @@ -21,6 +21,7 @@ Required properties:
>> >>    "allwinner,sun9i-a80-r-pinctrl"
>> >>    "allwinner,sun8i-a83t-pinctrl"
>> >>    "allwinner,sun8i-h3-pinctrl"
>> >> +  "allwinner,a64-pinctrl"
>> >
>> > Hello,
>> >
>> > on all other Allwinner SoCs we use the SoC family as part of the
>> > compatible, as well as in the names of the Kconfig options. To
>> > keep things consistent, I would like to propose doing the same on
>> > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
>> > allwinner,a64-pinctrl.
>>
>> Yes, I have been told this already. However I don't like this idea so
>> much, for the following reasons:
>> a) It is mostly redundant. The actual SoC (marketing) name is unique,
>> there is no sun6i-a20 or sun7i-a23.
>
> At the same time, the family name is mostly valid too.
>
> We do share some DTSI across some SoCs already by their family name
> (sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and
> A33, etc.)
>
>> b) It is not even helpful. If I got Maxime correctly, then the newer
>> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
>> which is frankly the least interesting part from a Linux support
>> perspective. I would see some sense if it would reflect the generation
>> of IP blocks used, but so it is even more confusing to see that
>> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
>> different beast. The Allwinner marketing name tells you that, but the
>> sunxi one does not.
>
> The opposite can be said too.
>
> The A31 is quite different from the A33, while the A83 is much closer
> to the H3 than it is to the A80. Their marketing scheme is messy. In
> all aspects. We have a scheme that worked, I'd really like to stick
> with it.
>
>> c) It is very confusing for people not dealing with it everyday. Just
>> because I own a BananaPi I know that the A20 is sun7i, but I am totally
>> lost when it comes to all the other names. And even now it took me about
>> a minute to find the appropriate Wiki page which explains part of that
>> story.
>> d) Most importantly ;-): It kills TAB completion, unless you know the
>> sunxi number, which is mostly not true as pointed out in c)
>
> Both of these are true, but are about the DT filenames, and not the
> compatibles. I'd agree with you on this one now that we have
> per-vendor subfolders in boot/dts, but it was not the case before, and
> I'm pretty sure that to anyone that is not aware of the Allwinner SoCs
> names, having an A<number>.dtsi in arch/arm/boot/dts, it would be
> about a Cortex-A<number>, and definitely not an SoC from some random
> vendor.
>
> So, droping it in the filenames, why not. But I'd really like to keep
> the same compatible scheme.

If we do end up dropping it from the filenames, can you (André) update
MAINTAINERS to add "arch/arm64/boot/dts/sunxi/" to the sunxi entry?

Thanks.
ChenYu

[toc] | [prev] | [next] | [standalone]

#1324276 — Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

Hi,

On 02/02/16 10:00, Maxime Ripard wrote:
> Hi Andre,
> 
> On Mon, Feb 01, 2016 at 10:49:16PM +0000, André Przywara wrote:
>> On 01/02/16 18:27, Karsten Merker wrote:
>>
>> Hi Karsten,
>>
>> thank you very much for your feedback!
>>
>>> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:
>>>> Based on the Allwinner A64 user manual and on the previous sunxi
>>>> pinctrl drivers this introduces the pin multiplex assignments for
>>>> the ARMv8 Allwinner A64 SoC.
>>>> Port A is apparently used for the fixed function DRAM controller, so
>>>> the ports start at B here (the manual mentions "n from 1 to 7", so
>>>> not starting at 0).
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>>>>  arch/arm64/Kconfig.platforms                       |   1 +
>>>>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>>>>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>>>>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
>>>>  5 files changed, 613 insertions(+)
>>>>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> index 9213b27..9050002 100644
>>>> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> @@ -21,6 +21,7 @@ Required properties:
>>>>    "allwinner,sun9i-a80-r-pinctrl"
>>>>    "allwinner,sun8i-a83t-pinctrl"
>>>>    "allwinner,sun8i-h3-pinctrl"
>>>> +  "allwinner,a64-pinctrl"
>>>
>>> Hello,
>>>
>>> on all other Allwinner SoCs we use the SoC family as part of the
>>> compatible, as well as in the names of the Kconfig options. To
>>> keep things consistent, I would like to propose doing the same on
>>> Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
>>> allwinner,a64-pinctrl.
>>
>> Yes, I have been told this already. However I don't like this idea so
>> much, for the following reasons:
>> a) It is mostly redundant. The actual SoC (marketing) name is unique,
>> there is no sun6i-a20 or sun7i-a23.
> 
> At the same time, the family name is mostly valid too.
> 
> We do share some DTSI across some SoCs already by their family name
> (sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and
> A33, etc.)
> 
>> b) It is not even helpful. If I got Maxime correctly, then the newer
>> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
>> which is frankly the least interesting part from a Linux support
>> perspective. I would see some sense if it would reflect the generation
>> of IP blocks used, but so it is even more confusing to see that
>> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
>> different beast. The Allwinner marketing name tells you that, but the
>> sunxi one does not.
> 
> The opposite can be said too.
> 
> The A31 is quite different from the A33, while the A83 is much closer
> to the H3 than it is to the A80. Their marketing scheme is messy. In
> all aspects. We have a scheme that worked, I'd really like to stick
> with it.

But also H3 and A64 are closely related, still having a totally
different sunxi name.
I guess we could give examples and counter-examples for hours, and just
making it possible to have two contradicting rationales lets me think
this whole naming scheme is inconsistent ;-)
I see that it may have fulfilled a purpose in the past (sun3i-sun7i,
maybe sun8i), but I am not very happy with proliferating this into the
(arm64) future.
Allwinner A<something> is a perfectly google-able and well understood
naming, also unique. So why add some mysterious sun{4,5,6,7,8,9,50}i to it?
So I will amend identifiers/filenames where the name was just A64,
without any Allwinner reference (like in the pinctrl driver). I am in
for using sunxi as a shorthand for Allwinner, since this is a) shorter,
b) is already all over the kernel and c) doesn't give direct credit to a
company that apparently doesn't care ;-)

>> c) It is very confusing for people not dealing with it everyday. Just
>> because I own a BananaPi I know that the A20 is sun7i, but I am totally
>> lost when it comes to all the other names. And even now it took me about
>> a minute to find the appropriate Wiki page which explains part of that
>> story.
>> d) Most importantly ;-): It kills TAB completion, unless you know the
>> sunxi number, which is mostly not true as pointed out in c)
> 
> Both of these are true, but are about the DT filenames, and not the
> compatibles. I'd agree with you on this one now that we have
> per-vendor subfolders in boot/dts, but it was not the case before, and
> I'm pretty sure that to anyone that is not aware of the Allwinner SoCs
> names, having an A<number>.dtsi in arch/arm/boot/dts, it would be
> about a Cortex-A<number>, and definitely not an SoC from some random
> vendor.

I completely agree on that, but this is in
arch/arm64/boot/dts/allwinner, so it's pretty unique. Other vendors in
there seem to think the same. I also see that just an "a" as a prefix is
pretty short, so should we go with "aw" instead?
But actually I would just leave it as it is.

> So, droping it in the filenames, why not. But I'd really like to keep
> the same compatible scheme.

And I still don't get this: in the DT compatible scheme we always have a
vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
why should we add an arbitrary and confusing sun50i naming to it (when
it actually should be more like "sun8i-a64").

Cheers,
Andre.

[toc] | [prev] | [next] | [standalone]

#1327103 — Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

[Multipart message — attachments visible in raw view] — view raw

Hi Andre,

On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote:
> > So, droping it in the filenames, why not. But I'd really like to keep
> > the same compatible scheme.
> 
> And I still don't get this: in the DT compatible scheme we always have a
> vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
> or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
> why should we add an arbitrary and confusing sun50i naming to it (when
> it actually should be more like "sun8i-a64").

I don't decide on their marketing names. And I know you want to start
anew with the arm64 SoCs, but the truth is, you don't. Most of the
compatibles in the DTSI are from earlier SoCs, and we have to keep
that legacy and remain consistent with it. With all the good and bad
things a legacy imply.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1329225 — Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

Hi,

On 08/02/16 15:54, Rob Herring wrote:
> On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote:
>> Hi Andre,
>>
>> On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote:
>>>> So, droping it in the filenames, why not. But I'd really like to keep
>>>> the same compatible scheme.
>>>
>>> And I still don't get this: in the DT compatible scheme we always have a
>>> vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
>>> or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
>>> why should we add an arbitrary and confusing sun50i naming to it (when
>>> it actually should be more like "sun8i-a64").
>>
>> I don't decide on their marketing names. And I know you want to start
>> anew with the arm64 SoCs, but the truth is, you don't. Most of the
>> compatibles in the DTSI are from earlier SoCs, and we have to keep
>> that legacy and remain consistent with it. With all the good and bad
>> things a legacy imply.
> 
> I have to agree. Unless there is some agreement to move to another 
> naming scheme, then just follow the same pattern. If sunXi is just a 
> made up name outside of Allwinner to provide some logical grouping of 
> SoCs, then yes, that probably should not have been done.

So I still don't like it, but will not waste my time or energy on that
front.

Maxime, do you want "allwinner,sun50i-a64" or would
"allwinner,sunxi-a64" be OK as well?

Cheers,
Andre.

[toc] | [prev] | [next] | [standalone]

#1329233 — Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote:
> Hi Andre,
> 
> On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote:
> > > So, droping it in the filenames, why not. But I'd really like to keep
> > > the same compatible scheme.
> > 
> > And I still don't get this: in the DT compatible scheme we always have a
> > vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
> > or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
> > why should we add an arbitrary and confusing sun50i naming to it (when
> > it actually should be more like "sun8i-a64").
> 
> I don't decide on their marketing names. And I know you want to start
> anew with the arm64 SoCs, but the truth is, you don't. Most of the
> compatibles in the DTSI are from earlier SoCs, and we have to keep
> that legacy and remain consistent with it. With all the good and bad
> things a legacy imply.

I have to agree. Unless there is some agreement to move to another 
naming scheme, then just follow the same pattern. If sunXi is just a 
made up name outside of Allwinner to provide some logical grouping of 
SoCs, then yes, that probably should not have been done.

Rob

[toc] | [prev] | [next] | [standalone]

#1323367 — [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit

The driver for the sunxi-ss crypto engine is not entirely 64-bit safe,
compilation on arm64 spits some warnings.
The proper fix was deemed to involved [1], so since 64-bit SoCs won't
have this IP block we just disable this driver for 64-bit.

[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399988.html
     (and the reply)

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/crypto/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 07d4942..737200f 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -487,7 +487,7 @@ config CRYPTO_DEV_IMGTEC_HASH
 
 config CRYPTO_DEV_SUN4I_SS
 	tristate "Support for Allwinner Security System cryptographic accelerator"
-	depends on ARCH_SUNXI
+	depends on ARCH_SUNXI && !64BIT
 	select CRYPTO_MD5
 	select CRYPTO_SHA1
 	select CRYPTO_AES
-- 
2.6.4

[toc] | [prev] | [next] | [standalone]

#1323756 — Re: [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit

On Mon, Feb 01, 2016 at 05:39:21PM +0000, Andre Przywara wrote:
> The driver for the sunxi-ss crypto engine is not entirely 64-bit safe,
> compilation on arm64 spits some warnings.
> The proper fix was deemed to involved [1], so since 64-bit SoCs won't
> have this IP block we just disable this driver for 64-bit.
> 
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399988.html
>      (and the reply)
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

I still use COMPILE_TEST to test compile these drivers.  So while
I don't have a problem with this patch per se, please continue to
ensure that it doesn't generate warnings on 64-bit platforms.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [prev] | [next] | [standalone]

#1323889 — Re: [linux-sunxi] [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit

On Mon, Feb 01, 2016 at 05:39:21PM +0000, Andre Przywara wrote:
> The driver for the sunxi-ss crypto engine is not entirely 64-bit safe,
> compilation on arm64 spits some warnings.
> The proper fix was deemed to involved [1], so since 64-bit SoCs won't
> have this IP block we just disable this driver for 64-bit.
> 
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399988.html
>      (and the reply)
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Corentin LABBE <clabbe.montjoie@gmail.com>

> ---
>  drivers/crypto/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 07d4942..737200f 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -487,7 +487,7 @@ config CRYPTO_DEV_IMGTEC_HASH
>  
>  config CRYPTO_DEV_SUN4I_SS
>  	tristate "Support for Allwinner Security System cryptographic accelerator"
> -	depends on ARCH_SUNXI
> +	depends on ARCH_SUNXI && !64BIT
>  	select CRYPTO_MD5
>  	select CRYPTO_SHA1
>  	select CRYPTO_AES
> -- 
> 2.6.4
> 
> -- 

[toc] | [prev] | [next] | [standalone]

#1328245 — Re: [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit

On Mon, Feb 01, 2016 at 05:39:21PM +0000, Andre Przywara wrote:
> The driver for the sunxi-ss crypto engine is not entirely 64-bit safe,
> compilation on arm64 spits some warnings.
> The proper fix was deemed to involved [1], so since 64-bit SoCs won't
> have this IP block we just disable this driver for 64-bit.
> 
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399988.html
>      (and the reply)
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Applied.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [prev] | [next] | [standalone]

#1323368 — [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for all sunxi SoCs

At the moment the "sun6i" RTC drivers depends on having two specific
SoC families selected.
The Allwinner A64 SoC has the same RTC, so extend the Kconfig option
to allow inclusion of the driver for all Allwinner SoCs.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/rtc/Kconfig | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 376322f..526eaf4 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1360,10 +1360,11 @@ config RTC_DRV_SUN4V
 
 config RTC_DRV_SUN6I
 	tristate "Allwinner A31 RTC"
-	depends on MACH_SUN6I || MACH_SUN8I
+	default MACH_SUN6I || MACH_SUN8I
+	depends on ARCH_SUNXI
 	help
-	  If you say Y here you will get support for the RTC found on
-	  Allwinner A31.
+	  If you say Y here you will get support for the RTC found in
+	  some Allwinner SoCs like the A31 or the A64.
 
 config RTC_DRV_SUNXI
 	tristate "Allwinner sun4i/sun7i RTC"
-- 
2.6.4

[toc] | [prev] | [next] | [standalone]

#1323913 — Re: [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for all sunxi SoCs

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 01, 2016 at 05:39:22PM +0000, Andre Przywara wrote:
> At the moment the "sun6i" RTC drivers depends on having two specific
> SoC families selected.
> The Allwinner A64 SoC has the same RTC, so extend the Kconfig option
> to allow inclusion of the driver for all Allwinner SoCs.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1327288 — Re: [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for all sunxi SoCs

On 01/02/2016 at 17:39:22 +0000, Andre Przywara wrote :
> At the moment the "sun6i" RTC drivers depends on having two specific
> SoC families selected.
> The Allwinner A64 SoC has the same RTC, so extend the Kconfig option
> to allow inclusion of the driver for all Allwinner SoCs.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/rtc/Kconfig | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1323369 — [PATCH 09/11] clk: sunxi: add critical-clocks property to mux clocks

The only reason we match the different root compatible strings when
registering the different sunxi clock types is to provide a list of
critical clocks.
Tell the mux clock (for a start) to get this property from the
device tree, allowing new SoCs to refer to the generic fallback
compatible string when the DT provides the critical clock information.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 9416e0f3..e1e5a8f 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -644,6 +644,11 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
 		goto out_unmap;
 	}
 
+	if (of_property_read_bool(node, "critical-clocks")) {
+		pr_debug("marked clock %s as critical\n", clk_name);
+		clk_prepare_enable(clk);
+	}
+
 	of_clk_add_provider(node, of_clk_src_simple_get, clk);
 	clk_register_clkdev(clk, clk_name, NULL);
 	return;
@@ -1064,6 +1069,10 @@ CLK_OF_DECLARE(sun8i_a23_clk_init, "allwinner,sun8i-a23", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_h3_clk_init, "allwinner,sun8i-h3", sun6i_init_clocks);
 
+/*
+ * Those SoCs here either don't have a specific critical clock to
+ * protect or they mark the critical clocks as such in their DT.
+ */
 static void __init sunxi_generic_init_clocks(struct device_node *node)
 {
 	sunxi_init_clocks(NULL, 0);
-- 
2.6.4

[toc] | [prev] | [next] | [standalone]

#1323877

On 02/02/16 07:57, lists.nick.betteridge@gmail.com wrote:
> Just a quick question - will there be any support for enabling booting into virtualisation mode to run xen and the like?

This is a firmware issue. The SoC itself provides everything you need
and even Allwinner choosing ARM Trusted Firmware (ATF) to do PSCI
handling shows how to do it - but for whatever reason they hacked it to
_not_ enter the kernel (or Xen, for that matter) in EL2.

But this should be fixable - either by using U-Boot's PSCI support or by
doing a proper ATF port. I am tempted to look at the latter.

Rest assured that using KVM was the primary reason I backed the Pine64,
so this definitely will be supported some day. Booting Xen does not make
much difference in this respect then.

Cheers,
Andre

[toc] | [prev] | [next] | [standalone]

#1323885

[Multipart message — attachments visible in raw view] — view raw

Just a quick question - will there be any support for enabling booting into virtualisation mode to run xen and the like?

Cheers
Nick

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web