From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753944AbdEHRCL (ORCPT ); Mon, 8 May 2017 13:02:11 -0400 Received: from relmlor3.renesas.com ([210.160.252.173]:14136 "EHLO relmlie2.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752682AbdEHRCJ (ORCPT ); Mon, 8 May 2017 13:02:09 -0400 X-IronPort-AV: E=Sophos;i="5.38,309,1491231600"; d="scan'208";a="242117298" From: Chris Brandt To: Andy Shevchenko , jmondi CC: Linus Walleij , Jacopo Mondi , Geert Uytterhoeven , Laurent Pinchart , Rob Herring , Mark Rutland , "Russell King - ARM Linux" , Linux-Renesas , "linux-gpio@vger.kernel.org" , devicetree , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Thread-Topic: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Thread-Index: AQHSvy8kW/T8jbNXV0G/jE8WsCEqd6HZTneAgAEnEICAACrhkIAAE36AgAAKEjCAACHsAIANr5WAgAIa0gCAAAIDAIAAAdTA Date: Mon, 8 May 2017 17:02:02 +0000 Message-ID: References: <1493281194-5200-1-git-send-email-jacopo+renesas@jmondi.org> <1493281194-5200-2-git-send-email-jacopo+renesas@jmondi.org> <20170508160120.GB25206@w540> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=renesas.com; x-originating-ip: [4.59.13.106] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;SG2PR06MB1165;7:/wjD9rvW8csn6fqd3nmatJpa7LkHFiFR0LebBxnNCyof3V9L9lBBoMtwhH8CLAvZ1Nt91xFIPoi7tNBy/clAcq/Tcgd/pTUU8TMz3xfSclvKZu7/BcfFxy7s2LjUx/gXsNz3XlbSpcJpfPzJOc9oqFN821peMp+uZj2Ht6U/A3CJSHQETN1BmLGf78G7pwiEcDNwxz/eWK2/s7bZd0btqzLgelxVd2Ifgf560mI3XzdP07AhP7UTBxbn1e9cLqzIepnbveeT1jX1mg+Yt8NhNwPvOcyiw0r00F7s5oO+s38b8NrdxLXu0iGprDDFDFerERymucwLcXYQAE3fxBT2xA==;20:matRE+KxcRuP0ECuhu4xL6rW5QDGtrUbH4vdbpV4PEkZRZE1PoY7n8D1TgUNRfnUValI4CWqQJU8Aem0KnM0eSqIUzQlKTK/ugi9b14AQkJf+BY+OrCV7GBCJ5ZRkGQ0o4IzCJMSzlsySp44GhLsqxYtIyq8pyTHs4GTpICbdRM= x-ms-office365-filtering-correlation-id: 62466417-2ec4-45c1-f830-08d49633f2ac x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:SG2PR06MB1165; 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)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(6072148);SRVR:SG2PR06MB1165;BCL:0;PCL:0;RULEID:;SRVR:SG2PR06MB1165; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39400400002)(39850400002)(39840400002)(39410400002)(39860400002)(24454002)(377454003)(54356999)(229853002)(2900100001)(99286003)(478600001)(5660300001)(6246003)(54906002)(93886004)(53936002)(7696004)(55016002)(33656002)(9686003)(38730400002)(7416002)(86362001)(102836003)(122556002)(6116002)(3846002)(189998001)(8676002)(2906002)(3660700001)(3280700002)(39060400002)(50986999)(2950100002)(76176999)(4326008)(66066001)(81166006)(74316002)(305945005)(8936002)(7736002)(6436002)(6506006)(53546009)(25786009)(77096006)(41533002);DIR:OUT;SFP:1102;SCL:1;SRVR:SG2PR06MB1165;H:SG2PR06MB1165.apcprd06.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;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: 08 May 2017 17:02:02.3451 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR06MB1165 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 v48H3Wrs019219 On Monday, May 08, 2017, Andy Shevchenko wrote: > On Mon, May 8, 2017 at 7:01 PM, jmondi wrote: > > On Sun, May 07, 2017 at 09:52:49AM +0200, Linus Walleij wrote: > >> On Fri, Apr 28, 2017 at 4:53 PM, Andy Shevchenko > >> wrote: > >> > >> > Linus, for me it looks like better to revert that change, until we > >> > will have clear picture why existing configuration parameters can't > >> > work. > >> > >> Yeah I'll revert the binding for fixes. > > > As it seems we won't be able to proceed with the currently proposed > solution, > > would that be acceptable now that we use the "pinmux" property to add > > flags as BIDIR > > Can you explain what does this *electrically* mean? Bi-Directional: For any pin that needs to drive (send) or sense (receive) signals, the pin mux controller can only enable 1 direction of buffers (in this case, it only the output buffers). Therefore the appropriate bit in the 'bi-directional' register is set in order to enable the signal path in both directions (ie, enable the input buffers). > > and SWIO_[INPUT|OUTPUT] directly there? In the hardware manual, there is a list of pin functions that if you want to use, you cannot use the stand pinmux register method that you use for all the other pins. Instead, you are instructed to do a different procedure. If course electrically, input/output buffers are still turned on/off or whatever, but the root reason of why you need to do this differently for these specific pin/function is not known. The "SWIO_" portion of the naming comes from the hardware manual which refers to this as "Software I/O Control Alternative Mode" (which in my opinion means the HW guys couldn't get the pin directions/buffers to be set automatically for some reason, so they decided it's the SW guys problem now for those pins) > Second question, what makes it differ to what already exists? We have 3 different flags (properties) that need to be specified for some pins in some circumstances. At first, we just tried to pass this additional information in when defining what function the pin should be just for those pins whose direction (ie, buffers) would not be set up automatically. However, this was rejected and we were told to pick from the existing set generic properties. But, 3 different generic pinctrl properties that fit what we needed didn't exist. So, we used the existing "input-enable" and "output-enable", but then created "bi-directional". Chris