From: Andre Przywara <andre.przywara@arm.com>
To: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Cc: Karsten Merker <merker@debian.org>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
Chen-Yu Tsai <wens@csie.org>,
linux-sunxi@googlegroups.com, Arnd Bergmann <arnd@arndb.de>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
Vishnu Patekar <vishnupatekar0510@gmail.com>,
linux-gpio@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
devicetree@vger.kernel.org
Subject: Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
Date: Tue, 2 Feb 2016 14:24:20 +0000 [thread overview]
Message-ID: <56B0BC14.8060007@arm.com> (raw)
In-Reply-To: <20160202035852.6984db63@i7>
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.
next prev parent reply other threads:[~2016-02-02 14:24 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 17:39 [PATCH 00/11] arm64: Introduce Allwinner A64 and Pine64 support Andre Przywara
2016-02-01 17:39 ` [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm Andre Przywara
2016-02-02 14:51 ` [tip:irq/urgent] irqchip/sun4i: Fix compilation outside of arch/ arm tip-bot for Andre Przywara
2016-02-02 15:12 ` [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm Matthias Brugger
2016-02-02 15:32 ` Andre Przywara
2016-02-02 16:50 ` Matthias Brugger
2016-02-01 17:39 ` [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit Andre Przywara
2016-02-02 3:16 ` Herbert Xu
2016-02-02 8:42 ` [linux-sunxi] " LABBE Corentin
2016-02-06 7:46 ` Herbert Xu
2016-02-01 17:39 ` [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for all sunxi SoCs Andre Przywara
2016-02-02 9:44 ` Maxime Ripard
2016-02-04 22:58 ` Alexandre Belloni
2016-02-01 17:39 ` [PATCH 04/11] arm64: Introduce Allwinner SoC config option Andre Przywara
2016-02-02 15:20 ` Matthias Brugger
2016-02-02 15:30 ` Andre Przywara
2016-02-02 16:04 ` Arnd Bergmann
2016-02-01 17:39 ` [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Andre Przywara
2016-02-01 18:27 ` Karsten Merker
2016-02-01 18:45 ` [linux-sunxi] " Karsten Merker
2016-02-01 23:02 ` André Przywara
2016-02-01 22:49 ` André Przywara
2016-02-02 1:58 ` [linux-sunxi] " Siarhei Siamashka
2016-02-02 14:24 ` Andre Przywara [this message]
2016-02-02 17:37 ` Maxime Ripard
2016-02-02 10:00 ` Maxime Ripard
2016-02-02 10:09 ` Chen-Yu Tsai
2016-02-02 16:53 ` Andre Przywara
2016-02-04 16:51 ` Maxime Ripard
2016-02-08 15:54 ` Rob Herring
2016-02-08 15:58 ` Andre Przywara
2016-02-09 17:12 ` Maxime Ripard
2016-02-01 17:39 ` [PATCH 06/11] clk: sunxi: add generic multi-parent bus clock gates driver Andre Przywara
2016-02-01 18:40 ` Jean-Francois Moine
2016-02-01 23:01 ` André Przywara
2016-02-01 17:39 ` [PATCH 07/11] clk: sunxi: add generic allwinner,sunxi name Andre Przywara
2016-02-08 15:57 ` Rob Herring
2016-02-08 16:06 ` Andre Przywara
2016-02-01 17:39 ` [PATCH 08/11] clk: sunxi: improve error reporting for the mux clock Andre Przywara
2016-02-02 18:02 ` Maxime Ripard
2016-02-02 18:05 ` Andre Przywara
2016-02-01 17:39 ` [PATCH 09/11] clk: sunxi: add critical-clocks property to mux clocks Andre Przywara
2016-02-01 17:39 ` [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi Andre Przywara
2016-02-01 19:05 ` [linux-sunxi] " Karsten Merker
2016-02-01 23:03 ` André Przywara
2016-02-02 16:24 ` Jens Kuske
2016-02-02 16:46 ` Andre Przywara
2016-02-02 17:40 ` Jens Kuske
2016-02-05 8:55 ` Chen-Yu Tsai
2016-02-05 8:50 ` Maxime Ripard
2016-02-08 9:42 ` Andre Przywara
2016-02-23 18:45 ` Maxime Ripard
2016-02-01 17:39 ` [PATCH 11/11] arm64: dts: add Pine64 support Andre Przywara
2016-02-01 19:22 ` [linux-sunxi] " Karsten Merker
2016-02-01 23:04 ` André Przywara
2016-02-05 9:03 ` Maxime Ripard
2016-02-05 10:04 ` Andre Przywara
2016-02-08 0:55 ` [linux-sunxi] " Julian Calaby
2016-02-09 20:33 ` Danny Milosavljevic
2016-02-11 10:32 ` Maxime Ripard
2016-02-02 7:57 ` [PATCH 00/11] arm64: Introduce Allwinner A64 and " lists.nick.betteridge
2016-02-02 8:12 ` André Przywara
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=56B0BC14.8060007@arm.com \
--to=andre.przywara@arm.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=mark.rutland@arm.com \
--cc=maxime.ripard@free-electrons.com \
--cc=merker@debian.org \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=siarhei.siamashka@gmail.com \
--cc=vishnupatekar0510@gmail.com \
--cc=wens@csie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).