From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Thu, 19 Jan 2012 10:20:19 -0800 Subject: Pinmux bindings proposal In-Reply-To: References: <74CDBE0F657A3D45AFBB94109FB122FF17801D202F@HQMAIL01.nvidia.com> <20120119165607.GG22818@atomide.com> Message-ID: <20120119182019.GI22818@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Thomas Abraham [120119 09:05]: > > On 19 January 2012 22:26, Tony Lindgren wrote: > > * Thomas Abraham [120119 04:37]: > >> > >> i2c0: i2c at 18000000 { > >> ? ? ? ? [... other properties ...] > >> ? ? ? ? pinctrl-active = <&pctrl0 5 0 2 3 0>, > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?<&pctrl0 5 1 2 3 0>; > >> ? ? ? ? pinctrl-suspend = <&pctrl0 5 0 2 0 0>, > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? <&pctrl0 5 1 2 0 0>; > >> }; > > > > Maybe we should have just the active/suspend/off flags in the > > same array? Otherwise we'll end up unnecessarily repeating the > > the pin information. See the pins + #pin-args example I posted, > > which is otherwise similar. > > Yes, I agree. That would be better. OK great. > > > >> In the example above, the specifier of pinctrl-* is specific for > >> Samsung io-pad controllers. Its format/syntax would be mainly > >> dependent on the io-pad controller used, the above is only an example > >> for Samsung io-pad controller. In the above node, the format of the > >> pinctrl-* specifier is > >> > >> property-name = >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?pin bank within the pin-controller > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?pin number within the pin-bank > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?pin-mux function number > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?pull up/down config > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?drive strength config>; > > > > Are these all just bits in one register? If so, let's say you > > have 16-bits per pin, we might be able to share the generic > > pinmux-simple.c driver I have almost ready.. > > no, these get written to different registers, one for pinmux, one for > pull up/down and one for drive strength. It would be helpful of your > pinmux-simple.c can support writes to multiple registers also. Hmm yeah that should be doable, and actually we have the old legacy omap1510 set up with three different registers per pin.. The question is: Do we want to add the on/idle/off modes for each pin in .dts, or do we want to have the driver set the dynamic muxing flags separately? > > The format would then be > > > > ? ? ? ?#pin-args <4>; > > ? ? ? ?... > > > > ? ? ? ?/* ? ?controller ?offset on ? idle off */ > > ? ? ? ?pins = <&pinctrl0 0x0030 0x15 0x15 0x7>; > > > >> * Using the pinmux/pinconfig specifier in device nodes to configure hardware. > >> > >> A driver (for a device instantiated from device tree) would require > >> code to be made aware of the pinmux/pinconfig options available. The > >> typical sequence in a probe function would be as below. > >> > >> (a) call of_get_named_gpio() to get the gpio number. In case of > >> Samsung pinctrl driver, the pinctrl driver itself provides the gpiolib > >> functionality and it attaches a gpio specifier translator with the > >> gpio_chip. This translator is capable of translating the pinctrl-* and > >> returning a gpio number. > >> > >> (b) gpio_request() the gpio number obtained in step (a) above. > >> > >> (c) Repeat steps (a) and (b) until all the gpios required by the > >> driver are requested. In case a request fails, give up all the > >> successfully requested gpio and return failure. > > > > Can't the driver do this to request the gpio pins that you > > can get from DT and pinmux? Even if you need to do dynamic pinmuxing > > to GPIO pins for wake-up events, you can do that from the driver > > as long as you get the GPIO number for the pin from mux code. > > Yes, it is the driver that finds out the gpio number from dt and > requests it. Maybe, I did not understand your point here. Oh ok, sorry I misunderstood thinking you want to do all that in the pinmux driver.. > With the approach that I mentioned in the previous email, there are no > pinmux, pin groups or pin desc tables built from dt. Each device node > specifies what needs to configured (pinmux,pinconfig) and the code > using that device node uses pinctrl driver to get those > pinmux/pinconfig values written to the hardware registers. > > Does the dt support for pinmux/pinconfig that you are developing build > the pinmux, pin groups or pin desc tables? Do drivers have to call > pinmux_{get/put}() or pin_config_set() functions even in dt case? Yeah the pinmux/pingroups and functions are built from the DT. Drivers would have to still call pinmux_get and set right now. But some of this could probably be automatically done using runtime PM? Cheers, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: Pinmux bindings proposal Date: Thu, 19 Jan 2012 10:20:19 -0800 Message-ID: <20120119182019.GI22818@atomide.com> References: <74CDBE0F657A3D45AFBB94109FB122FF17801D202F@HQMAIL01.nvidia.com> <20120119165607.GG22818@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Thomas Abraham Cc: "linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org" , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , "s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org" , "kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org" , "cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Dong Aisheng List-Id: devicetree@vger.kernel.org KiBUaG9tYXMgQWJyYWhhbSA8dGhvbWFzLmFicmFoYW1AbGluYXJvLm9yZz4gWzEyMDExOSAwOTow NV06Cj4gCj4gT24gMTkgSmFudWFyeSAyMDEyIDIyOjI2LCBUb255IExpbmRncmVuIDx0b255QGF0 b21pZGUuY29tPiB3cm90ZToKPiA+ICogVGhvbWFzIEFicmFoYW0gPHRob21hcy5hYnJhaGFtQGxp bmFyby5vcmc+IFsxMjAxMTkgMDQ6MzddOgo+ID4+Cj4gPj4gaTJjMDogaTJjQDE4MDAwMDAwIHsK PiA+PiDCoCDCoCDCoCDCoCBbLi4uIG90aGVyIHByb3BlcnRpZXMgLi4uXQo+ID4+IMKgIMKgIMKg IMKgIHBpbmN0cmwtYWN0aXZlID0gPCZwY3RybDAgNSAwIDIgMyAwPiwKPiA+PiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwmcGN0cmwwIDUgMSAyIDMgMD47Cj4g Pj4gwqAgwqAgwqAgwqAgcGluY3RybC1zdXNwZW5kID0gPCZwY3RybDAgNSAwIDIgMCAwPiwKPiA+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8JnBjdHJs MCA1IDEgMiAwIDA+Owo+ID4+IH07Cj4gPgo+ID4gTWF5YmUgd2Ugc2hvdWxkIGhhdmUganVzdCB0 aGUgYWN0aXZlL3N1c3BlbmQvb2ZmIGZsYWdzIGluIHRoZQo+ID4gc2FtZSBhcnJheT8gT3RoZXJ3 aXNlIHdlJ2xsIGVuZCB1cCB1bm5lY2Vzc2FyaWx5IHJlcGVhdGluZyB0aGUKPiA+IHRoZSBwaW4g aW5mb3JtYXRpb24uIFNlZSB0aGUgcGlucyArICNwaW4tYXJncyBleGFtcGxlIEkgcG9zdGVkLAo+ ID4gd2hpY2ggaXMgb3RoZXJ3aXNlIHNpbWlsYXIuCj4gCj4gWWVzLCBJIGFncmVlLiBUaGF0IHdv dWxkIGJlIGJldHRlci4KCk9LIGdyZWF0LgogCj4gPgo+ID4+IEluIHRoZSBleGFtcGxlIGFib3Zl LCB0aGUgc3BlY2lmaWVyIG9mIHBpbmN0cmwtKiBpcyBzcGVjaWZpYyBmb3IKPiA+PiBTYW1zdW5n IGlvLXBhZCBjb250cm9sbGVycy4gSXRzIGZvcm1hdC9zeW50YXggd291bGQgYmUgbWFpbmx5Cj4g Pj4gZGVwZW5kZW50IG9uIHRoZSBpby1wYWQgY29udHJvbGxlciB1c2VkLCB0aGUgYWJvdmUgaXMg b25seSBhbiBleGFtcGxlCj4gPj4gZm9yIFNhbXN1bmcgaW8tcGFkIGNvbnRyb2xsZXIuIEluIHRo ZSBhYm92ZSBub2RlLCB0aGUgZm9ybWF0IG9mIHRoZQo+ID4+IHBpbmN0cmwtKiBzcGVjaWZpZXIg aXMKPiA+Pgo+ID4+IHByb3BlcnR5LW5hbWUgPSA8cGhhbmRsZSBvZiB0aGUgcGluLWNvbnRyb2xs ZXIKPiA+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBpbiBiYW5r IHdpdGhpbiB0aGUgcGluLWNvbnRyb2xsZXIKPiA+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHBpbiBudW1iZXIgd2l0aGluIHRoZSBwaW4tYmFuawo+ID4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGluLW11eCBmdW5jdGlvbiBudW1i ZXIKPiA+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHB1bGwgdXAv ZG93biBjb25maWcKPiA+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGRyaXZlIHN0cmVuZ3RoIGNvbmZpZz47Cj4gPgo+ID4gQXJlIHRoZXNlIGFsbCBqdXN0IGJpdHMg aW4gb25lIHJlZ2lzdGVyPyBJZiBzbywgbGV0J3Mgc2F5IHlvdQo+ID4gaGF2ZSAxNi1iaXRzIHBl ciBwaW4sIHdlIG1pZ2h0IGJlIGFibGUgdG8gc2hhcmUgdGhlIGdlbmVyaWMKPiA+IHBpbm11eC1z aW1wbGUuYyBkcml2ZXIgSSBoYXZlIGFsbW9zdCByZWFkeS4uCj4gCj4gbm8sIHRoZXNlIGdldCB3 cml0dGVuIHRvIGRpZmZlcmVudCByZWdpc3RlcnMsIG9uZSBmb3IgcGlubXV4LCBvbmUgZm9yCj4g cHVsbCB1cC9kb3duIGFuZCBvbmUgZm9yIGRyaXZlIHN0cmVuZ3RoLiBJdCB3b3VsZCBiZSBoZWxw ZnVsIG9mIHlvdXIKPiBwaW5tdXgtc2ltcGxlLmMgY2FuIHN1cHBvcnQgd3JpdGVzIHRvIG11bHRp cGxlIHJlZ2lzdGVycyBhbHNvLgogCkhtbSB5ZWFoIHRoYXQgc2hvdWxkIGJlIGRvYWJsZSwgYW5k IGFjdHVhbGx5IHdlIGhhdmUgdGhlIG9sZCBsZWdhY3kKb21hcDE1MTAgc2V0IHVwIHdpdGggdGhy ZWUgZGlmZmVyZW50IHJlZ2lzdGVycyBwZXIgcGluLi4KClRoZSBxdWVzdGlvbiBpczogRG8gd2Ug d2FudCB0byBhZGQgdGhlIG9uL2lkbGUvb2ZmIG1vZGVzIGZvciBlYWNoCnBpbiBpbiAuZHRzLCBv ciBkbyB3ZSB3YW50IHRvIGhhdmUgdGhlIGRyaXZlciBzZXQgdGhlIGR5bmFtaWMgbXV4aW5nCmZs YWdzIHNlcGFyYXRlbHk/Cgo+ID4gVGhlIGZvcm1hdCB3b3VsZCB0aGVuIGJlCj4gPgo+ID4gwqAg wqAgwqAgwqAjcGluLWFyZ3MgPDQ+Owo+ID4gwqAgwqAgwqAgwqAuLi4KPiA+Cj4gPiDCoCDCoCDC oCDCoC8qIMKgIMKgY29udHJvbGxlciDCoG9mZnNldCBvbiDCoCBpZGxlIG9mZiAqLwo+ID4gwqAg wqAgwqAgwqBwaW5zID0gPCZwaW5jdHJsMCAweDAwMzAgMHgxNSAweDE1IDB4Nz47Cj4gPgo+ID4+ ICogVXNpbmcgdGhlIHBpbm11eC9waW5jb25maWcgc3BlY2lmaWVyIGluIGRldmljZSBub2RlcyB0 byBjb25maWd1cmUgaGFyZHdhcmUuCj4gPj4KPiA+PiBBIGRyaXZlciAoZm9yIGEgZGV2aWNlIGlu c3RhbnRpYXRlZCBmcm9tIGRldmljZSB0cmVlKSB3b3VsZCByZXF1aXJlCj4gPj4gY29kZSB0byBi ZSBtYWRlIGF3YXJlIG9mIHRoZSBwaW5tdXgvcGluY29uZmlnIG9wdGlvbnMgYXZhaWxhYmxlLiBU aGUKPiA+PiB0eXBpY2FsIHNlcXVlbmNlIGluIGEgcHJvYmUgZnVuY3Rpb24gd291bGQgYmUgYXMg YmVsb3cuCj4gPj4KPiA+PiAoYSkgY2FsbCBvZl9nZXRfbmFtZWRfZ3BpbygpIHRvIGdldCB0aGUg Z3BpbyBudW1iZXIuIEluIGNhc2Ugb2YKPiA+PiBTYW1zdW5nIHBpbmN0cmwgZHJpdmVyLCB0aGUg cGluY3RybCBkcml2ZXIgaXRzZWxmIHByb3ZpZGVzIHRoZSBncGlvbGliCj4gPj4gZnVuY3Rpb25h bGl0eSBhbmQgaXQgYXR0YWNoZXMgYSBncGlvIHNwZWNpZmllciB0cmFuc2xhdG9yIHdpdGggdGhl Cj4gPj4gZ3Bpb19jaGlwLiBUaGlzIHRyYW5zbGF0b3IgaXMgY2FwYWJsZSBvZiB0cmFuc2xhdGlu ZyB0aGUgcGluY3RybC0qIGFuZAo+ID4+IHJldHVybmluZyBhIGdwaW8gbnVtYmVyLgo+ID4+Cj4g Pj4gKGIpIGdwaW9fcmVxdWVzdCgpIHRoZSBncGlvIG51bWJlciBvYnRhaW5lZCBpbiBzdGVwIChh KSBhYm92ZS4KPiA+Pgo+ID4+IChjKSBSZXBlYXQgc3RlcHMgKGEpIGFuZCAoYikgdW50aWwgYWxs IHRoZSBncGlvcyByZXF1aXJlZCBieSB0aGUKPiA+PiBkcml2ZXIgYXJlIHJlcXVlc3RlZC4gSW4g Y2FzZSBhIHJlcXVlc3QgZmFpbHMsIGdpdmUgdXAgYWxsIHRoZQo+ID4+IHN1Y2Nlc3NmdWxseSBy ZXF1ZXN0ZWQgZ3BpbyBhbmQgcmV0dXJuIGZhaWx1cmUuCj4gPgo+ID4gQ2FuJ3QgdGhlIGRyaXZl ciBkbyB0aGlzIHRvIHJlcXVlc3QgdGhlIGdwaW8gcGlucyB0aGF0IHlvdQo+ID4gY2FuIGdldCBm cm9tIERUIGFuZCBwaW5tdXg/IEV2ZW4gaWYgeW91IG5lZWQgdG8gZG8gZHluYW1pYyBwaW5tdXhp bmcKPiA+IHRvIEdQSU8gcGlucyBmb3Igd2FrZS11cCBldmVudHMsIHlvdSBjYW4gZG8gdGhhdCBm cm9tIHRoZSBkcml2ZXIKPiA+IGFzIGxvbmcgYXMgeW91IGdldCB0aGUgR1BJTyBudW1iZXIgZm9y IHRoZSBwaW4gZnJvbSBtdXggY29kZS4KPiAKPiBZZXMsIGl0IGlzIHRoZSBkcml2ZXIgdGhhdCBm aW5kcyBvdXQgdGhlIGdwaW8gbnVtYmVyIGZyb20gZHQgYW5kCj4gcmVxdWVzdHMgaXQuIE1heWJl LCBJIGRpZCBub3QgdW5kZXJzdGFuZCB5b3VyIHBvaW50IGhlcmUuCgpPaCBvaywgc29ycnkgSSBt aXN1bmRlcnN0b29kIHRoaW5raW5nIHlvdSB3YW50IHRvIGRvIGFsbCB0aGF0IGluIHRoZQpwaW5t dXggZHJpdmVyLi4KIAo+IFdpdGggdGhlIGFwcHJvYWNoIHRoYXQgSSBtZW50aW9uZWQgaW4gdGhl IHByZXZpb3VzIGVtYWlsLCB0aGVyZSBhcmUgbm8KPiBwaW5tdXgsIHBpbiBncm91cHMgb3IgcGlu IGRlc2MgdGFibGVzIGJ1aWx0IGZyb20gZHQuIEVhY2ggZGV2aWNlIG5vZGUKPiBzcGVjaWZpZXMg d2hhdCBuZWVkcyB0byBjb25maWd1cmVkIChwaW5tdXgscGluY29uZmlnKSBhbmQgdGhlIGNvZGUK PiB1c2luZyB0aGF0IGRldmljZSBub2RlIHVzZXMgcGluY3RybCBkcml2ZXIgdG8gZ2V0IHRob3Nl Cj4gcGlubXV4L3BpbmNvbmZpZyB2YWx1ZXMgd3JpdHRlbiB0byB0aGUgaGFyZHdhcmUgcmVnaXN0 ZXJzLgo+IAo+IERvZXMgdGhlIGR0IHN1cHBvcnQgZm9yIHBpbm11eC9waW5jb25maWcgdGhhdCB5 b3UgYXJlIGRldmVsb3BpbmcgYnVpbGQKPiB0aGUgcGlubXV4LCBwaW4gZ3JvdXBzIG9yIHBpbiBk ZXNjIHRhYmxlcz8gRG8gZHJpdmVycyBoYXZlIHRvIGNhbGwKPiBwaW5tdXhfe2dldC9wdXR9KCkg b3IgcGluX2NvbmZpZ19zZXQoKSBmdW5jdGlvbnMgZXZlbiBpbiBkdCBjYXNlPwoKWWVhaCB0aGUg cGlubXV4L3Bpbmdyb3VwcyBhbmQgZnVuY3Rpb25zIGFyZSBidWlsdCBmcm9tIHRoZSBEVC4gRHJp dmVycwp3b3VsZCBoYXZlIHRvIHN0aWxsIGNhbGwgcGlubXV4X2dldCBhbmQgc2V0IHJpZ2h0IG5v dy4gQnV0IHNvbWUgb2YgdGhpcwpjb3VsZCBwcm9iYWJseSBiZSBhdXRvbWF0aWNhbGx5IGRvbmUg dXNpbmcgcnVudGltZSBQTT8KCkNoZWVycywKClRvbnkKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KZGV2aWNldHJlZS1kaXNjdXNzIG1haWxpbmcgbGlzdApk ZXZpY2V0cmVlLWRpc2N1c3NAbGlzdHMub3psYWJzLm9yZwpodHRwczovL2xpc3RzLm96bGFicy5v cmcvbGlzdGluZm8vZGV2aWNldHJlZS1kaXNjdXNzCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932716Ab2ASSUi (ORCPT ); Thu, 19 Jan 2012 13:20:38 -0500 Received: from mho-01-ewr.mailhop.org ([204.13.248.71]:13195 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932532Ab2ASSUg (ORCPT ); Thu, 19 Jan 2012 13:20:36 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 98.234.237.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1962ndSRQpZteew7F6AbI3V Date: Thu, 19 Jan 2012 10:20:19 -0800 From: Tony Lindgren To: Thomas Abraham Cc: Stephen Warren , Dong Aisheng-B29396 , "linus.walleij@stericsson.com" , "s.hauer@pengutronix.de" , "rob.herring@calxeda.com" , "kernel@pengutronix.de" , "cjb@laptop.org" , "Simon Glass (sjg@chromium.org)" , Dong Aisheng , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "devicetree-discuss@lists.ozlabs.org" Subject: Re: Pinmux bindings proposal Message-ID: <20120119182019.GI22818@atomide.com> References: <74CDBE0F657A3D45AFBB94109FB122FF17801D202F@HQMAIL01.nvidia.com> <20120119165607.GG22818@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Thomas Abraham [120119 09:05]: > > On 19 January 2012 22:26, Tony Lindgren wrote: > > * Thomas Abraham [120119 04:37]: > >> > >> i2c0: i2c@18000000 { > >>         [... other properties ...] > >>         pinctrl-active = <&pctrl0 5 0 2 3 0>, > >>                              <&pctrl0 5 1 2 3 0>; > >>         pinctrl-suspend = <&pctrl0 5 0 2 0 0>, > >>                                 <&pctrl0 5 1 2 0 0>; > >> }; > > > > Maybe we should have just the active/suspend/off flags in the > > same array? Otherwise we'll end up unnecessarily repeating the > > the pin information. See the pins + #pin-args example I posted, > > which is otherwise similar. > > Yes, I agree. That would be better. OK great. > > > >> In the example above, the specifier of pinctrl-* is specific for > >> Samsung io-pad controllers. Its format/syntax would be mainly > >> dependent on the io-pad controller used, the above is only an example > >> for Samsung io-pad controller. In the above node, the format of the > >> pinctrl-* specifier is > >> > >> property-name = >>                            pin bank within the pin-controller > >>                            pin number within the pin-bank > >>                            pin-mux function number > >>                            pull up/down config > >>                            drive strength config>; > > > > Are these all just bits in one register? If so, let's say you > > have 16-bits per pin, we might be able to share the generic > > pinmux-simple.c driver I have almost ready.. > > no, these get written to different registers, one for pinmux, one for > pull up/down and one for drive strength. It would be helpful of your > pinmux-simple.c can support writes to multiple registers also. Hmm yeah that should be doable, and actually we have the old legacy omap1510 set up with three different registers per pin.. The question is: Do we want to add the on/idle/off modes for each pin in .dts, or do we want to have the driver set the dynamic muxing flags separately? > > The format would then be > > > >        #pin-args <4>; > >        ... > > > >        /*    controller  offset on   idle off */ > >        pins = <&pinctrl0 0x0030 0x15 0x15 0x7>; > > > >> * Using the pinmux/pinconfig specifier in device nodes to configure hardware. > >> > >> A driver (for a device instantiated from device tree) would require > >> code to be made aware of the pinmux/pinconfig options available. The > >> typical sequence in a probe function would be as below. > >> > >> (a) call of_get_named_gpio() to get the gpio number. In case of > >> Samsung pinctrl driver, the pinctrl driver itself provides the gpiolib > >> functionality and it attaches a gpio specifier translator with the > >> gpio_chip. This translator is capable of translating the pinctrl-* and > >> returning a gpio number. > >> > >> (b) gpio_request() the gpio number obtained in step (a) above. > >> > >> (c) Repeat steps (a) and (b) until all the gpios required by the > >> driver are requested. In case a request fails, give up all the > >> successfully requested gpio and return failure. > > > > Can't the driver do this to request the gpio pins that you > > can get from DT and pinmux? Even if you need to do dynamic pinmuxing > > to GPIO pins for wake-up events, you can do that from the driver > > as long as you get the GPIO number for the pin from mux code. > > Yes, it is the driver that finds out the gpio number from dt and > requests it. Maybe, I did not understand your point here. Oh ok, sorry I misunderstood thinking you want to do all that in the pinmux driver.. > With the approach that I mentioned in the previous email, there are no > pinmux, pin groups or pin desc tables built from dt. Each device node > specifies what needs to configured (pinmux,pinconfig) and the code > using that device node uses pinctrl driver to get those > pinmux/pinconfig values written to the hardware registers. > > Does the dt support for pinmux/pinconfig that you are developing build > the pinmux, pin groups or pin desc tables? Do drivers have to call > pinmux_{get/put}() or pin_config_set() functions even in dt case? Yeah the pinmux/pingroups and functions are built from the DT. Drivers would have to still call pinmux_get and set right now. But some of this could probably be automatically done using runtime PM? Cheers, Tony