From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932853AbdC2Mic (ORCPT ); Wed, 29 Mar 2017 08:38:32 -0400 Received: from relmlor3.renesas.com ([210.160.252.173]:64664 "EHLO relmlie2.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932132AbdC2Mi2 (ORCPT ); Wed, 29 Mar 2017 08:38:28 -0400 X-IronPort-AV: E=Sophos;i="5.36,241,1486393200"; d="scan'208";a="238970726" From: Chris Brandt To: jacopo , Geert Uytterhoeven , Linus Walleij CC: Jacopo Mondi , Geert Uytterhoeven , Laurent Pinchart , Rob Herring , "Mark Rutland" , Russell King , Linux-Renesas , "linux-gpio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc Thread-Topic: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc Thread-Index: AQHSoZUtC1Wf1/FjiU2HPM0/L3VSV6GgrGwAgAHuCgCAB3K5AIAAUYwAgADHCICAAFUYgIAALKaAgAASUYCAAAyIAIAAAqkQ Date: Wed, 29 Mar 2017 12:38:21 +0000 Message-ID: References: <1490026491-21742-1-git-send-email-jacopo+renesas@jmondi.org> <1490026491-21742-3-git-send-email-jacopo+renesas@jmondi.org> <20170323160204.GL30223@w540> <20170329120530.GB6247@w540> In-Reply-To: <20170329120530.GB6247@w540> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jmondi.org; dkim=none (message not signed) header.d=none;jmondi.org; dmarc=none action=none header.from=renesas.com; x-originating-ip: [75.60.247.61] x-microsoft-exchange-diagnostics: 1;SG2PR06MB1166;7:4f0xs2UBFIOqsB2ZFwtfiMZaVxuly5p3MI6TKPr4hezSRW32ZuT2XXJ4N9Qd5VIm4zWc+tSSGXVD67Ni7d09vzeUjphU0t8qB+EhGVFH0VZibkuX1DYfTkxBdJOfVA0xFoc7dlPSvarrXRCnMnNl0ZOOdeRoCt65vzbEVHyQOD74hopviVajzGprOempwmxcRpPuZ3pU7TZexnEnP+CGy3WQDLGCCrTj58DeUNwdD9mXPcr/4QuOalurlN8ftSCSQlel4n8DuKrfqDbbi1wcsynnGynS4GPvV1ouKLI3IsnPjud6fD+6f9gwpVZmjEj8dsfKv5cZp1Xrmt7YxzNQAQ==;20:KcYuVhi68SxBhT1Zwp7zCKdDYGlP576TAEyvfvP5cTEdGAHsCyG74ADaiGMMUIdlXjd1bpmPlJEFSmuMcoRclQVFckL/n1LCy/5/X/vSrg1X/9IPXc2eTadyiqKm8zuY4jlu3dyr14M9ROlKsPY3zMS+5T7Gi2gWEywNxco8rog= x-ms-office365-filtering-correlation-id: bbb26e9b-0b90-4432-33cc-08d476a07bf1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075);SRVR:SG2PR06MB1166; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123562025)(20161123560025)(20161123558025)(6072148);SRVR:SG2PR06MB1166;BCL:0;PCL:0;RULEID:;SRVR:SG2PR06MB1166; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(24454002)(189998001)(77096006)(7736002)(305945005)(74316002)(2906002)(6506006)(6116002)(33656002)(6436002)(3846002)(5660300001)(50986999)(76176999)(54356999)(3660700001)(7416002)(25786009)(93886004)(3280700002)(55016002)(54906002)(99286003)(7696004)(8936002)(122556002)(2950100002)(9686003)(8676002)(53936002)(2900100001)(6306002)(102836003)(6246003)(4326008)(86362001)(38730400002)(81166006)(66066001)(229853002);DIR:OUT;SFP:1102;SCL:1;SRVR:SG2PR06MB1166;H:SG2PR06MB1165.apcprd06.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: renesas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 12:38:21.1621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR06MB1166 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v2TCd764009421 Adding my 2 cents here: On Wednesday, March 29, 2017, jacopo wrote: > > > If you really do we may need to go for u64 but ... really? Is there > > > a rational reason for that other than "we did it like this first"? > > > > > > I do not understand the notion of "flags" here. I hope that is not > > > referring > > > > Flags refers to BI_DIR, SWIO_IN, and SWIO_OUT, from > > https://patchwork.kernel.org/patch/9643047/ > > > > 32-bit should be enough to cover pins, function, and flags. > > > > Geert already replied, but to avoid any confusion I'll try to remove from > driver the use of "pin config" when referring to this three flags, which > are just additional informations the pin controller needs to perform pin > muxing properly. They're not related the standard pin config properties > (pull-up/down, bias etc.. actually our hardware does not even support > these natively) > > > > to pin config, because I expect that to use the standard pin config > > > bindings outside of the pinmux value which should just define the > > > pin+function combo: > > > > > > node { > > > pinmux = ; > > > GENERIC_PINCONFIG; > > > }; > > > > > > Example from Mediatek: > > > > > > i2c1_pins_a: i2c1@0 { > > > pins { > > > pinmux = , > > > ; > > > > If we follow this example, then we can list all combinations in > > include/dt-bindings/pinctrl/r7s72100-pinctrl.h, instead of creating > > the value by combining the bits using a macro where we need it in the > DTS. > > > > It's gonna be a long list, though... > > > > I'm strongly in favour of something like > pinmux = , .... ; > > opposed to > pinmux = , ... ; I agree. I like "". > Not only because it will save use from having a loong list(*) of macros > that has to be kept up to date when/if new RZ hardware will arrive, but > also because of readability and simplicity for down-stream and BSP users. > Speaking of which, I would like to know what does Chris think of this. The list of macros would be very long, especially against the different packaging version of the RZ/A1 series. 11 ports, 16-pins for each port, 8 different function options for each pin....2 different package/pin variations. And at the end of the day....there is no benefit for the user over just using a macro. A little about "this controller" for the RZ/A1: In my opinion it's a one-shot usage. I don't foresee future RZ/A SoCs using this exact pin controller. The reason for the "FLAGS" is to work around a quirky hardware design (in my opinion). However, future RZ/A SoCs will use a 'similar' type controller where each pin has 8 function options (but the FLAGs won't be needed anymore...as far as I can see...). So I foresee the DT interface staying more or less the same, but the underlying register setup in the driver Will change (become more simple). Now...if we can only convince the R-Car guys to move to a more simple pin-mux controller... Chris