From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756734AbcBBRi6 (ORCPT ); Tue, 2 Feb 2016 12:38:58 -0500 Received: from down.free-electrons.com ([37.187.137.238]:49419 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755750AbcBBRi4 (ORCPT ); Tue, 2 Feb 2016 12:38:56 -0500 Date: Tue, 2 Feb 2016 18:37:44 +0100 From: Maxime Ripard To: Siarhei Siamashka Cc: =?iso-8859-1?Q?Andr=E9?= Przywara , Karsten Merker , Chen-Yu Tsai , linux-sunxi@googlegroups.com, Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Linus Walleij , Vishnu Patekar , linux-gpio@vger.kernel.org, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org Subject: Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Message-ID: <20160202173744.GB4652@lukather> References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com> <1454348370-3816-6-git-send-email-andre.przywara@arm.com> <20160201182754.GA14737@excalibur.cnev.de> <56AFE0EC.8080207@arm.com> <20160202035852.6984db63@i7> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TqjUw3h+J5USMjbw" Content-Disposition: inline In-Reply-To: <20160202035852.6984db63@i7> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --TqjUw3h+J5USMjbw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: =20 > > >> 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,sun= xi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-= pinctrl.txt > > >> index 9213b27..9050002 100644 > > >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinc= trl.txt > > >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinc= trl.txt > > >> @@ -21,6 +21,7 @@ Required properties: > > >> "allwinner,sun9i-a80-r-pinctrl" > > >> "allwinner,sun8i-a83t-pinctrl" > > >> "allwinner,sun8i-h3-pinctrl" > > >> + "allwinner,a64-pinctrl" =20 > > >=20 > > > Hello, > > >=20 > > > 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. =20 > >=20 > > 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) > >=20 > > 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. > >=20 > > 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. >=20 > 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. >=20 > 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: >=20 > http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG >=20 > 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 --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --TqjUw3h+J5USMjbw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWsOloAAoJEBx+YmzsjxAg3dsP/RHPSaay/cIlI/AwrjIpSLn3 CG84d4YtzdHif4PxWElegOXRBsV4Aae2cGasFqZ77tF7loKE42EINsowF9cEcLf/ qdP8pGV0F1Jjx2o/a1cvAhgLqqyRnV9CQLo9Oh9N/pFVzm2gRQSbRkJbRrId/2bs 0zZOWj9nEudVKk0XIrDli5u/mvaYMPBosHGtxV3xAqBxi5+TN9z9SaCN0iCYRoBl 7cF1FTxIxc5OB/4xlVslOclj6ap+inJoQyl2/z3TaRddm1eDmpFxhWwlBYc2MjO+ xqcHJINQ6cWu4NjzcFnZc0gL58x5wzYmogFVt75xBQRZemdZektghe1/7YAvlK/7 WIRLFvi90iEMUG5WejMQ8x2E+CC/w5roDZrCpFzeuX3KuMI2dPzXJvnPf24S0kRX IPL5YOPc+QZmjyArgUTbXVB6HcbG8hd8Zz+JdA6Q31oS2In8GmKTswjOZJsMe7ud 0WxqX7Uz5CQAyId83NrMbjtPQIKR8edC9rZ8Ze0kie208MRqbXpTiPH5AX8+cATn VW53xfhSs2OELV9MZ2eynB/BU/MOMDZndLAX160qiVZp35xr3aCEigNGqBf9A2Bs R0IXVleHT5G08OBNpc8yrrXj8AA9wwN6HcKIcJX87TeBRWYF/zffIVVG3MLDk/j4 +0OqoGFKgWnRdlKGj4Iu =/tPh -----END PGP SIGNATURE----- --TqjUw3h+J5USMjbw--