On 10/22/2012 02:45 AM, Linus Walleij wrote: > On Fri, Oct 19, 2012 at 12:20 AM, Stephen Warren <[email protected]> > wrote: > >> On 10/18/2012 03:06 AM, Haojian Zhuang wrote: >>> Configure pins by pinctrl driver. >> >> In general, it seems better to use pinctrl "hogs" if the driver is only >> going to statically set up one pinctrl state and never change it. The >> alternative is make every single driver execute these pinctrl calls, >> which could be tedious. > > True. And each platform has to choose how to go ahead with this. > > I always imagined that any system of the "power socket in wall" > type would just use hogs to configure its pins and be done with > it, and there appear to be some platforms like that. (e.g. MIPS and > various power-inaware references come to mind). > > For the Ux500 drivers we have found that all of those that have pin > resources actually have to be handled by the driver. The reason is > that all of them have idle and/or sleep states that need to be > handled at runtime.
Well, presumably the pinctrl driver itself could have both default/idle states, and system sleep could engage the appropriate system-wide setting. > As an additional complication our drivers are used also by > the Versatile and SPEAr family of platforms, so the control > need to be tolerant (accept missing pinctrl handles and states) > as well. (I can see that other drivers take shortcuts by being less > elaborate since there is a 1:1 driver<->platform mapping.) Isn't the driver (or DT binding) supposed to define what pinctrl states must exist, and those state must always exist? There's no requirement for a pinctrl state definition to always actually contain content that changes the state. That's exactly why PIN_MAP_TYPE_DUMMY_STATE exists. > An alternative to embedding the pin handling code into > the drivers is to use bus notifiers as is done with the > shmobile clocking by drivers/base/power/clock_ops.c > I could easily imagine pinctrl_ops.c like that for some > platforms. This mandates still binding the pin table entries > to a device but avoids adding any code to the drivers. > > However this latter approach does not work for us (Ux500) - > the three resources we have: clocks, pins and power domains > are dependent on state switch ordering (sometimes you need > to switch off the clock then set pin state, sometimes the > other way around) and it is not even > the same for all drivers - the notifier approach mandates > that all drivers do the clock, power domain and pin handling > uniformly. That certainly does imply that individual drivers do need to handle this explicitly. Although I still think that only specific drivers actually affected by this should end up actively managing pinctrl; shouldn't anything that can get away with relying on system hogs do so? _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
