Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman wrote: > [Me] >> Well, the pinctrl grabbers in these drivers are using these states also >> for platforms that do not even select CONFIG_PM. For example >> mach-nomadik is quite happy that the PL011 driver is thusly >> muxing in its pins. And would require refactoring to use PM >> domains. > > If CONFIG_PM is disabled, then is it safe to assume that the pins in > question are probably only done once at init time. I assume during > ->probe(). ? Sadly no. Consider drivers/tty/serial/amba-pl011.c Many ARM platforms have several instances of PL011, and not all of them have CONFIG_PM & friends, so it's a good example. Here the driver will probe and currently fetch a pinctrl handle and looks up two states: "default", which refers to the situation you describe, and optionally "sleep" which will put pins into a low-power state. The driver will currently put the pins into the "sleep" state when .shutdown() is called by something (userspace or in-kernel users). So in the new suggested scheme using runtime PM, this would have to be replaced by pm_runtime_get[_sync]() and pm_runtime_put() hints and the current pin handling deleted, and for each platform using this driver instead implement a PM domain to do the same thing. Else you loose this runtime power optimization. This is what I refer to the all-or-nothing charcter of runtime PM domains... but maybe it's a good thing, I haven't quite made my mind up about it. > (...) if what we want/need are only ways to introduce SoC-specific > integration details into non-PM transitions (e.g. probe/remove), maybe > bus notifiers would suffice here. e.g. you'd get a bus notifier when > the device is added/attached and any init-time pinctrl setup could be > done then. This still keeps drivers clean of SoC-specific integration > data/code, and also allows that to happen whether or not PM features are > enabled. It doesn't cut it for any of our drivers as shown above, but it would work for the patch in $SUBJECT. It sounds like the way silicon clocks are handled on SH am I right? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Linus Walleij writes: > On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman > wrote: > >> Linus Walleij writes: > > >> >> > piece of hardware, this would be the right thing to do, >> > and I think the in-kernel examples are all "simple", >> > e.g. arch/arm/mach-omap2/powerdomain* is all about >> > power domains and nothing else, >> >> FYI... that code isn't the same as PM domain. > > > This sort of points to a core problem here. Our terminologies are > ambiguous that we cannot understand each others code. As long > as begins: > > /* > * pm_domain.h - Definitions and headers related to device power domains. > * > > But arguably that should just be patched (I think there are a few > remnants in the code still implying that these things are only about > power). Agreed. The terminology is confusing, and any situations like this in the code/comments/docs should be patched. When PM domains were introduced, I was the first to complain that we shouldn't use the term power domain so as not to be confused with HW concepts, so we settled on the term 'PM domain.' Ultimately, it's just a configurable grouping of devices whose callbacks happen during PM transitions. >> >> That code is for the >> *hardware* powerdomains, not the software concept of "PM domain." In >> OMAP, PM domain is implmented at the omap_device level. And omap_device >> is the abstraction of an IP block that knows about all the PM related >> register settings, clocks, HW powerdomain, voltage domain, PM related >> pin-muxing etc. etc.All of these things are abstracted in an >> omap_device, so that the PM domain implementation for OMAP looks rather >> simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.) > > > OK following now... > >> >> > I think the lesser of two evils is the distributed approach, >> >> The pinctrl examples I've seen mentioned so far are all PM related >> >> (sleep, idle, wakeup, etc.) so to me I think they still belong in >> PM domains (and that's how we handle the PM related pins in OMAP.) > > > Well, the pinctrl grabbers in these drivers are using these states also > for platforms that do not even select CONFIG_PM. For example > mach-nomadik is quite happy that the PL011 driver is thusly > muxing in its pins. And would require refactoring to use PM > domains. If CONFIG_PM is disabled, then is it safe to assume that the pins in question are probably only done once at init time. I assume during ->probe(). ? > > So basically this requirement comes down to: > > - When dealing with a SoC IP block driver > > - That need to multiplex pins > > - Then your SoC must select CONFIG_PM and > CONFIG_PM_RUNTIME andb > CONFIG_PM_GENERIC_DOMAINS and implement > proper domain handling hooks. > > Is this correct? I would say yes. Currently, PM domains are the way to hook SoC-specific integration details into PM transitions. However, if what we want/need are only ways to introduce SoC-specific integration details into non-PM transitions (e.g. probe/remove), maybe bus notifiers would suffice here. e.g. you'd get a bus notifier when the device is added/attached and any init-time pinctrl setup could be done then. This still keeps drivers clean of SoC-specific integration data/code, and also allows that to happen whether or not PM features are enabled. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Linus Walleij linus.wall...@linaro.org writes: On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Linus Walleij linus.wall...@linaro.org writes: piece of hardware, this would be the right thing to do, and I think the in-kernel examples are all simple, e.g. arch/arm/mach-omap2/powerdomain* is all about power domains and nothing else, FYI... that code isn't the same as PM domain. This sort of points to a core problem here. Our terminologies are ambiguous that we cannot understand each others code. As long as linux/pm_domain.h begins: /* * pm_domain.h - Definitions and headers related to device power domains. * But arguably that should just be patched (I think there are a few remnants in the code still implying that these things are only about power). Agreed. The terminology is confusing, and any situations like this in the code/comments/docs should be patched. When PM domains were introduced, I was the first to complain that we shouldn't use the term power domain so as not to be confused with HW concepts, so we settled on the term 'PM domain.' Ultimately, it's just a configurable grouping of devices whose callbacks happen during PM transitions. That code is for the *hardware* powerdomains, not the software concept of PM domain. In OMAP, PM domain is implmented at the omap_device level. And omap_device is the abstraction of an IP block that knows about all the PM related register settings, clocks, HW powerdomain, voltage domain, PM related pin-muxing etc. etc.All of these things are abstracted in an omap_device, so that the PM domain implementation for OMAP looks rather simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.) OK following now... I think the lesser of two evils is the distributed approach, The pinctrl examples I've seen mentioned so far are all PM related (sleep, idle, wakeup, etc.) so to me I think they still belong in PM domains (and that's how we handle the PM related pins in OMAP.) Well, the pinctrl grabbers in these drivers are using these states also for platforms that do not even select CONFIG_PM. For example mach-nomadik is quite happy that the PL011 driver is thusly muxing in its pins. And would require refactoring to use PM domains. If CONFIG_PM is disabled, then is it safe to assume that the pins in question are probably only done once at init time. I assume during -probe(). ? So basically this requirement comes down to: - When dealing with a SoC IP block driver - That need to multiplex pins - Then your SoC must select CONFIG_PM and CONFIG_PM_RUNTIME andb CONFIG_PM_GENERIC_DOMAINS and implement proper domain handling hooks. Is this correct? I would say yes. Currently, PM domains are the way to hook SoC-specific integration details into PM transitions. However, if what we want/need are only ways to introduce SoC-specific integration details into non-PM transitions (e.g. probe/remove), maybe bus notifiers would suffice here. e.g. you'd get a bus notifier when the device is added/attached and any init-time pinctrl setup could be done then. This still keeps drivers clean of SoC-specific integration data/code, and also allows that to happen whether or not PM features are enabled. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman khil...@deeprootsystems.com wrote: [Me] Well, the pinctrl grabbers in these drivers are using these states also for platforms that do not even select CONFIG_PM. For example mach-nomadik is quite happy that the PL011 driver is thusly muxing in its pins. And would require refactoring to use PM domains. If CONFIG_PM is disabled, then is it safe to assume that the pins in question are probably only done once at init time. I assume during -probe(). ? Sadly no. Consider drivers/tty/serial/amba-pl011.c Many ARM platforms have several instances of PL011, and not all of them have CONFIG_PM friends, so it's a good example. Here the driver will probe and currently fetch a pinctrl handle and looks up two states: default, which refers to the situation you describe, and optionally sleep which will put pins into a low-power state. The driver will currently put the pins into the sleep state when .shutdown() is called by something (userspace or in-kernel users). So in the new suggested scheme using runtime PM, this would have to be replaced by pm_runtime_get[_sync]() and pm_runtime_put() hints and the current pin handling deleted, and for each platform using this driver instead implement a PM domain to do the same thing. Else you loose this runtime power optimization. This is what I refer to the all-or-nothing charcter of runtime PM domains... but maybe it's a good thing, I haven't quite made my mind up about it. (...) if what we want/need are only ways to introduce SoC-specific integration details into non-PM transitions (e.g. probe/remove), maybe bus notifiers would suffice here. e.g. you'd get a bus notifier when the device is added/attached and any init-time pinctrl setup could be done then. This still keeps drivers clean of SoC-specific integration data/code, and also allows that to happen whether or not PM features are enabled. It doesn't cut it for any of our drivers as shown above, but it would work for the patch in $SUBJECT. It sounds like the way silicon clocks are handled on SH am I right? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
