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 +, 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
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 +, 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.
Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
On Mon, Feb 08, 2016 at 03:58:18PM +, Andre Przywara wrote: > 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 +, 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? The former will be fine. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
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 +, 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 >> --- >> .../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 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. >> - reg: Should contain the register physical address and length for the >>pin controller. >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms >> index fc7cf4b..03f0f9d 100644 >> --- a/arch/arm64/Kconfig.platforms >> +++ b/arch/arm64/Kconfig.platforms >> @@ -2,6 +2,7 @@ menu "Platform selection" >> >> config ARCH_SUNXI >> bool "Allwinner sunxi 64-bit SoC Family" >> +select PINCTRL_A64 > > Same as above, just with the name of the Kconfig option. > s/PINCTRL_A64/PINCTRL_SUN50I_A64/ ? I can see the reasoning behind this particular one, as A64 is not very specific. And indeed I had planned to replace this, but forgot it over merging all the stuff together. However I'd rather go with the generic "sunxi" as a stub name (PINCTRL_SUNXI_A64), as the "50" in there is now completely stupi^Wconfusing and also kills my favorite sun.i regexp ;-) I can see that the term "sunxi" is a shorthand for Allwinner in Linux, so it looks reasonable to me to use that. >> select SUNXI_MMC >> help >>This enables support for Allwinner sunxi based SoCs like the A64. >> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig >> index f8dbc8b..68873f2 100644 >> --- a/drivers/pinctrl/sunxi/Kconfig >> +++ b/drivers/pinctrl/sunxi/Kconfig >> @@ -64,4 +64,8 @@ config PINCTRL_SUN9I_A80_R >> depends on RESET_CONTROLLER >> select PINCTRL_SUNXI_COMMON >> >> +config PINCTRL_A64 > > see above > >> +bool >> +select PINCTRL_SUNXI_COMMON >> + >> endif >> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile >> index ef8
Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
Hi Andre, On Mon, Feb 01, 2016 at 10:49:16PM +, 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 +, 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 > >> --- > >> .../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.dtsi in arch/arm/boot/dts, it would be about a Cortex-A, 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 signature.asc Description: Digital signature
Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
On Tue, Feb 2, 2016 at 6:00 PM, Maxime Ripard wrote: > Hi Andre, > > On Mon, Feb 01, 2016 at 10:49:16PM +, 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 +, 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 >> >> --- >> >> .../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.dtsi in arch/arm/boot/dts, it would be > about a Cortex-A, 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
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 +, 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 +, 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
---
.../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 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.dtsi in arch/arm/boot/dts, it would be
> about a Cortex-A, and definitely not an SoC from some random
> vend
Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
Hi Andre, On Tue, Feb 02, 2016 at 04:53:58PM +, 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 signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
On 01/02/16 18:45, Karsten Merker wrote:
> Hello,
>
> I by mistake pressed "send" on my previous mail when I intended
> to further edit it, so here comes a followup.
> I definitely need more coffee ;-).
Or less? ;-) vv Thinking of twitchy fingers...
> On Mon, Feb 01, 2016 at 07:27:54PM +0100, Karsten Merker wrote:
>> On Mon, Feb 01, 2016 at 05:39:24PM +, Andre Przywara wrote:
>
>>> +static const struct sunxi_pinctrl_desc a64_pinctrl_data = {
>>> + .pins = a64_pins,
>>> + .npins = ARRAY_SIZE(a64_pins),
>>> + .irq_banks = 3,
>>> +};
>>> +
>>> +static int a64_pinctrl_probe(struct platform_device *pdev)
>>> +{
>>> + return sunxi_pinctrl_init(pdev,
>>> + &a64_pinctrl_data);
>>> +}
>>> +
>>> +static const struct of_device_id a64_pinctrl_match[] = {
>>> + { .compatible = "allwinner,a64-pinctrl", },
>
> s/allwinner,a64-pinctrl/allwinner,sun50i-a64-pinctrl/ ?
As mentioned in the other mail, allwinner should be enough to make the
naming unique. Especially as this is about DT namings, which should be
valid outside of the Linux world even.
Cheers,
Andre.
>
>>> + {}
>>> +};
>>> +MODULE_DEVICE_TABLE(of, a64_pinctrl_match);
>>> +
>>> +static struct platform_driver a64_pinctrl_driver = {
>>> + .probe = a64_pinctrl_probe,
>>> + .driver = {
>>> + .name = "a64-pinctrl",
>>> + .of_match_table = a64_pinctrl_match,
>>> + },
>>> +};
>>> +module_platform_driver(a64_pinctrl_driver);
>>> +
>>> +MODULE_AUTHOR("Andre Przywara ");
>>> +MODULE_DESCRIPTION("Allwinner A64 pinctrl driver");
>>> +MODULE_LICENSE("GPL");
>>
>> For the above function names one could also think about using the
>
> s/function names/variable definitions/
>
>> existing naming scheme including the SoC family as we do in the
>> other sunxi pinctrl drivers, but as they are only internal to the
>> driver, that would really just be a matter of cosmetics :-).
>
> Regards,
> Karsten
>
Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
On Mon, 1 Feb 2016 22:49:16 + 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 +, 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 > >> --- > >> .../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 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? -- Best regards, Siarhei Siamashka
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 + > 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 +, 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 --- .../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 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 a
Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
Hi, On Tue, Feb 02, 2016 at 03:58:52AM +0200, Siarhei Siamashka wrote: > > > On Mon, Feb 01, 2016 at 05:39:24PM +, 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 > > >> --- > > >> .../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 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 signature.asc Description: Digital signature
