On Thu, Oct 10, 2013 at 4:35 PM, Roger Quadros <rog...@ti.com> wrote: > On 10/10/2013 05:04 PM, Linus Walleij wrote:
>> As an innocent bystander who has no clue what the _reconfigure_io_chain() >> is about can you tell me what this is all about? > > The OMAP SoC has a mechanism to monitor and wakeup from a low power state by > creating > an IO ring of all the pads. But there is one bit in one of the control > registers that > needs to be toggled each time the pad configuration is changed to re-arm the > IO ring. > This is exactly what _reconfigure_io_chain() does. OK I get it, I checked the function in the machone. >> Is this another one of the OMAP forked paths where you must call back into >> the machine with a special callback from each and every driver? > > _reconfigure_io_chain() is not available for public use and is not called by > any driver yet. > However, it somehow needs to be called from this pinctrl-single driver each > time the > wakeup configuration for any pad is changed. Actually this is one of those things where the complexity of the platform seems to start to leak into the nice picture of one-register-per-pin. If this was *not* pinctrl-single but pinctrl-omap.c, it would make sense to move this _reconfigure_io code and the PRM registers it is touching down into the pinctrl driver, because it seems like absolutely no-one else is using it. Both the other occurences seem to be in omap_hwmod.c, and seems to be related to pin muxing, which is now supposed to be handled by the pin control driver, right? I think the real solution to this would be something like: - Add the compatible strings "pinctrl-single-omap3" and "pinctrl-single-omap4" to drivers/pinctrl/pinctrl-single.c, - Pass an additional <&ersand> resource for the prm thing to the single driver in the OMAP platform. - Move this _reconfigure_io code out of the mach-omap2 machines and hwmod and down into the pinctrl-single driver, it can be #ifdef ARCH_OMAP with stubs or whatever, the important thing is that it lives with the pinctrl driver. This does the right thing and let the pinctrl driver handle the io ring, instead of artificially trying to hide that in the mach-omap2 directory which is only creating a mess of things. I know this is sort of breaking the promise of pinctrl-single.c only handling single registers but we just need to accept the fact that if this idea is not perfect, trying to hide the facts of life isn't any good either. What do you say about this Tony? Good/bad/Linus is a moron? ;-) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
