From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
Cc: Vishnu Patekar
<vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
will.deacon-5wv7dgnIgG8@public.gmane.org,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org"
<linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH] drivers: pinctrl: add driver for Allwinner A64 SoC
Date: Wed, 6 Jan 2016 22:12:29 +0100 [thread overview]
Message-ID: <20160106211229.GC9631@lukather> (raw)
In-Reply-To: <568BB04B.30100-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]
Hi Andre,
On Tue, Jan 05, 2016 at 12:00:11PM +0000, Andre Przywara wrote:
> Hi Maxime,
>
> On 04/01/16 20:30, Maxime Ripard wrote:
> > Hi Andre,
> >
> > On Mon, Jan 04, 2016 at 10:29:06AM +0000, Andre Przywara wrote:
> >>>> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> >>>> index e080290..130e7bc 100644
> >>>> --- a/drivers/pinctrl/sunxi/Makefile
> >>>> +++ b/drivers/pinctrl/sunxi/Makefile
> >>>> @@ -12,5 +12,6 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20) += pinctrl-sun7i-a20.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A23) += pinctrl-sun8i-a23.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A33) += pinctrl-sun8i-a33.o
> >>>> +obj-$(CONFIG_PINCTRL_A64) += pinctrl-a64.o
> >>>
> >>> Shouldn't this follow pinctrl config name like other sunXi SOCs?
> >>> This should be PINCTRL_SUN??_A64.
> >>
> >> I never really got the reason we use those sunxi names in addition to
> >> the SoC name in the first place, maybe apart from copying from some
> >> Allwinner code.
> >> Since I decided to not look at Allwinner's BSP at all (if avoidable), I
> >> also thought it would be time to drop that sunxi naming, which looks
> >> redundant to me.
> >> Is there any reason why we would need this (beside having a rather
> >> unique identifier prefix)?
> >
> > It's mostly historical.
> >
> >
> > Back when we started this, There was a few SoCs already out: A10,
> > A10s, A12 and A13, which was very similar to the Cortex-A naming
> > scheme (and I think the Cortex-A12 was also announced at the time).
> >
> > We couldn't really use the SoC family either, since there was already
> > multiple SoCs that were part of the same family (the A10s, A12 and
> > A13, part of the sun5i family).
> >
> > In order to avoid any confusion, we chose to go with both to uniquely
> > and without any confusion possible, and we just went on with that
> > naming scheme for consistency.
>
> I see, thanks for the explanation.
> I was wondering since we now move to a new architecture as well to avoid
> this historic "ballast", but I have no problems with adding "_sun50i_"
> to the identifiers and file names.
> To me as only a casual sunxi user I found it mostly hard to memorize the
> connections between the sunxi numbering and the SoC names (I just know
> that the A20 is sun7i ;-). So for finding a specific dts for instance,
> you have to start with the sunxi number to get it TAB completed ...
I guess it doesn't really matter for arm64, since it seems like
there's a sub-folder per SoC family.
However, having an a12.dtsi in arch/arm/boot/dts will probably bring a
lot of confusion :)
I still think that we should maintain the current compatible scheme
though, in order to keep consistency.
> With that being said: Would you prefer to have a sun50i prefix? I see
> that having just "a64" on itself is not very specific.
I'd say that having a DTSI in arch/arm64/boot/dts/sunxi/a64.dtsi would
not bring a lot of confusion. If you're there, you know what you're
dealing with already.
If you feel like it makes the life easier to new or casual users, go
ahead.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] [RFC PATCH] drivers: pinctrl: add driver for Allwinner A64 SoC
Date: Wed, 6 Jan 2016 22:12:29 +0100 [thread overview]
Message-ID: <20160106211229.GC9631@lukather> (raw)
In-Reply-To: <568BB04B.30100@arm.com>
Hi Andre,
On Tue, Jan 05, 2016 at 12:00:11PM +0000, Andre Przywara wrote:
> Hi Maxime,
>
> On 04/01/16 20:30, Maxime Ripard wrote:
> > Hi Andre,
> >
> > On Mon, Jan 04, 2016 at 10:29:06AM +0000, Andre Przywara wrote:
> >>>> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> >>>> index e080290..130e7bc 100644
> >>>> --- a/drivers/pinctrl/sunxi/Makefile
> >>>> +++ b/drivers/pinctrl/sunxi/Makefile
> >>>> @@ -12,5 +12,6 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20) += pinctrl-sun7i-a20.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A23) += pinctrl-sun8i-a23.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A33) += pinctrl-sun8i-a33.o
> >>>> +obj-$(CONFIG_PINCTRL_A64) += pinctrl-a64.o
> >>>
> >>> Shouldn't this follow pinctrl config name like other sunXi SOCs?
> >>> This should be PINCTRL_SUN??_A64.
> >>
> >> I never really got the reason we use those sunxi names in addition to
> >> the SoC name in the first place, maybe apart from copying from some
> >> Allwinner code.
> >> Since I decided to not look at Allwinner's BSP at all (if avoidable), I
> >> also thought it would be time to drop that sunxi naming, which looks
> >> redundant to me.
> >> Is there any reason why we would need this (beside having a rather
> >> unique identifier prefix)?
> >
> > It's mostly historical.
> >
> >
> > Back when we started this, There was a few SoCs already out: A10,
> > A10s, A12 and A13, which was very similar to the Cortex-A naming
> > scheme (and I think the Cortex-A12 was also announced at the time).
> >
> > We couldn't really use the SoC family either, since there was already
> > multiple SoCs that were part of the same family (the A10s, A12 and
> > A13, part of the sun5i family).
> >
> > In order to avoid any confusion, we chose to go with both to uniquely
> > and without any confusion possible, and we just went on with that
> > naming scheme for consistency.
>
> I see, thanks for the explanation.
> I was wondering since we now move to a new architecture as well to avoid
> this historic "ballast", but I have no problems with adding "_sun50i_"
> to the identifiers and file names.
> To me as only a casual sunxi user I found it mostly hard to memorize the
> connections between the sunxi numbering and the SoC names (I just know
> that the A20 is sun7i ;-). So for finding a specific dts for instance,
> you have to start with the sunxi number to get it TAB completed ...
I guess it doesn't really matter for arm64, since it seems like
there's a sub-folder per SoC family.
However, having an a12.dtsi in arch/arm/boot/dts will probably bring a
lot of confusion :)
I still think that we should maintain the current compatible scheme
though, in order to keep consistency.
> With that being said: Would you prefer to have a sun50i prefix? I see
> that having just "a64" on itself is not very specific.
I'd say that having a DTSI in arch/arm64/boot/dts/sunxi/a64.dtsi would
not bring a lot of confusion. If you're there, you know what you're
dealing with already.
If you feel like it makes the life easier to new or casual users, go
ahead.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160106/22bccb52/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Vishnu Patekar <vishnupatekar0510@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Chen-Yu Tsai <wens@csie.org>, Hans de Goede <hdegoede@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
will.deacon@arm.com,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-gpio@vger.kernel.org,
"linux-sunxi@googlegroups.com" <linux-sunxi@googlegroups.com>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-sunxi] [RFC PATCH] drivers: pinctrl: add driver for Allwinner A64 SoC
Date: Wed, 6 Jan 2016 22:12:29 +0100 [thread overview]
Message-ID: <20160106211229.GC9631@lukather> (raw)
In-Reply-To: <568BB04B.30100@arm.com>
[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]
Hi Andre,
On Tue, Jan 05, 2016 at 12:00:11PM +0000, Andre Przywara wrote:
> Hi Maxime,
>
> On 04/01/16 20:30, Maxime Ripard wrote:
> > Hi Andre,
> >
> > On Mon, Jan 04, 2016 at 10:29:06AM +0000, Andre Przywara wrote:
> >>>> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> >>>> index e080290..130e7bc 100644
> >>>> --- a/drivers/pinctrl/sunxi/Makefile
> >>>> +++ b/drivers/pinctrl/sunxi/Makefile
> >>>> @@ -12,5 +12,6 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20) += pinctrl-sun7i-a20.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A23) += pinctrl-sun8i-a23.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
> >>>> obj-$(CONFIG_PINCTRL_SUN8I_A33) += pinctrl-sun8i-a33.o
> >>>> +obj-$(CONFIG_PINCTRL_A64) += pinctrl-a64.o
> >>>
> >>> Shouldn't this follow pinctrl config name like other sunXi SOCs?
> >>> This should be PINCTRL_SUN??_A64.
> >>
> >> I never really got the reason we use those sunxi names in addition to
> >> the SoC name in the first place, maybe apart from copying from some
> >> Allwinner code.
> >> Since I decided to not look at Allwinner's BSP at all (if avoidable), I
> >> also thought it would be time to drop that sunxi naming, which looks
> >> redundant to me.
> >> Is there any reason why we would need this (beside having a rather
> >> unique identifier prefix)?
> >
> > It's mostly historical.
> >
> >
> > Back when we started this, There was a few SoCs already out: A10,
> > A10s, A12 and A13, which was very similar to the Cortex-A naming
> > scheme (and I think the Cortex-A12 was also announced at the time).
> >
> > We couldn't really use the SoC family either, since there was already
> > multiple SoCs that were part of the same family (the A10s, A12 and
> > A13, part of the sun5i family).
> >
> > In order to avoid any confusion, we chose to go with both to uniquely
> > and without any confusion possible, and we just went on with that
> > naming scheme for consistency.
>
> I see, thanks for the explanation.
> I was wondering since we now move to a new architecture as well to avoid
> this historic "ballast", but I have no problems with adding "_sun50i_"
> to the identifiers and file names.
> To me as only a casual sunxi user I found it mostly hard to memorize the
> connections between the sunxi numbering and the SoC names (I just know
> that the A20 is sun7i ;-). So for finding a specific dts for instance,
> you have to start with the sunxi number to get it TAB completed ...
I guess it doesn't really matter for arm64, since it seems like
there's a sub-folder per SoC family.
However, having an a12.dtsi in arch/arm/boot/dts will probably bring a
lot of confusion :)
I still think that we should maintain the current compatible scheme
though, in order to keep consistency.
> With that being said: Would you prefer to have a sun50i prefix? I see
> that having just "a64" on itself is not very specific.
I'd say that having a DTSI in arch/arm64/boot/dts/sunxi/a64.dtsi would
not bring a lot of confusion. If you're there, you know what you're
dealing with already.
If you feel like it makes the life easier to new or casual users, go
ahead.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-01-06 21:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-31 17:17 [RFC PATCH] drivers: pinctrl: add driver for Allwinner A64 SoC Andre Przywara
2015-12-31 17:17 ` Andre Przywara
[not found] ` <1451582246-32373-1-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2016-01-04 6:34 ` Vishnu Patekar
2016-01-04 6:34 ` [linux-sunxi] " Vishnu Patekar
2016-01-04 8:43 ` Maxime Ripard
2016-01-04 8:43 ` Maxime Ripard
[not found] ` <CAEzqOZsE_kDChAbLkwmwjqdDbovv1e0G1tTffhhp25PkwJQ0+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-04 10:29 ` Andre Przywara
2016-01-04 10:29 ` [linux-sunxi] " Andre Przywara
2016-01-04 10:29 ` Andre Przywara
[not found] ` <568A4972.8030602-5wv7dgnIgG8@public.gmane.org>
2016-01-04 20:30 ` Maxime Ripard
2016-01-04 20:30 ` [linux-sunxi] " Maxime Ripard
2016-01-04 20:30 ` Maxime Ripard
2016-01-05 12:00 ` Andre Przywara
2016-01-05 12:00 ` [linux-sunxi] " Andre Przywara
2016-01-05 12:00 ` Andre Przywara
[not found] ` <568BB04B.30100-5wv7dgnIgG8@public.gmane.org>
2016-01-06 21:12 ` Maxime Ripard [this message]
2016-01-06 21:12 ` Maxime Ripard
2016-01-06 21:12 ` Maxime Ripard
2016-03-28 16:15 ` Amit Tomer
2016-03-28 16:15 ` Amit Tomer
[not found] ` <CABHD4K-nD9EvbgOPA2WH0q66csqVv18tmeTOBe87ACr4nuQM0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-28 16:19 ` Chen-Yu Tsai
2016-03-28 16:19 ` Chen-Yu Tsai
[not found] ` <CAGb2v64sv7CuuTC8fZV0spmiC=MYM3iqABr-EOC9oheXQ10C3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-28 16:52 ` Amit Tomer
2016-03-28 16:52 ` Amit Tomer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160106211229.GC9631@lukather \
--to=maxime.ripard-wi1+55scjutkeb57/3fjtnbpr1lh4cv8@public.gmane.org \
--cc=andre.przywara-5wv7dgnIgG8@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
--cc=vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=wens-jdAy2FN1RRM@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.