<div class="gmail_quote">On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman <span dir="ltr"><<a href="mailto:khilman@deeprootsystems.com" target="_blank">khilman@deeprootsystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="im">Linus Walleij <<a href="mailto:linus.walleij@linaro.org">linus.walleij@linaro.org</a>> writes:</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="im">> piece of hardware, this would be the right thing to do,<br>
> and I think the in-kernel examples are all "simple",<br>
> e.g. arch/arm/mach-omap2/powerdomain* is all about<br>
> power domains and nothing else,<br>
<br>
</div></div>FYI... that code isn't the same as PM domain.</blockquote><div><br>This sort of points to a core problem here. Our terminologies are<br>ambiguous that we cannot understand each others code. As long<br>as <linux/pm_domain.h> begins:<br>
<br>/*<br> * pm_domain.h - Definitions and headers related to device power domains.<br> *<br><br>But arguably that should just be patched (I think there are a few<br>remnants in the code still implying that these things are only about<br>
power).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  That code is for the<br>
*hardware* powerdomains, not the software concept of "PM domain."  In<br>
OMAP, PM domain is implmented at the omap_device level.  And omap_device<br>
is the abstraction of an IP block that knows about all the PM related<br>
register settings, clocks, HW powerdomain, voltage domain, PM related<br>
pin-muxing etc. etc.    All of these things are abstracted in an<br>
omap_device, so that the PM domain implementation for OMAP looks rather<br>
simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.)<br></blockquote><div><br>OK following now...<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> I think the lesser of two evils is the distributed approach, <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The pinctrl examples I've seen mentioned so far are all PM related<br>

(sleep, idle, wakeup, etc.) so to me I think they still belong in<br>
PM domains (and that's how we handle the PM related pins in OMAP.)<br></blockquote><div><br>Well, the pinctrl grabbers in these drivers are using these states also<br>for platforms that do not even select CONFIG_PM.  For example<br>
mach-nomadik is quite happy that the PL011 driver is thusly<br>muxing in its pins. And would require refactoring to use PM<br>domains.<br><br>So basically this requirement comes down to:<br><br>- When dealing with a SoC IP block driver<br>
<br>- That need to multiplex pins<br><br>- Then your SoC must select CONFIG_PM and<br>  CONFIG_PM_RUNTIME and<br>  CONFIG_PM_GENERIC_DOMAINS and implement<br>  proper domain handling hooks.<br><br>Is this correct? And for Mark, Dmitry, does this correspond to<br>
your view?<br><br>It's actually something that needs to be acknowledged by the<br>ARM SoC maintainers, because they will be the ones telling<br>all subarch maintainers to go implement full PM handling<br>with these three frameworks whenever an SoC driver want<br>
to handle pins.<br><br>Bascially all subsystem maintainers dealing with embedded<br>SoCs need to be aligned on this as well...<br><br>And IIUC not only pins but also silicon block clocks?<br><br>I can surely fix these for "my" systems, but it really needs<br>
to be enforced widely or it will be a mess.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> I worry that the per-SoC power domain implementation<br>
> which will live in arch/arm/mach-* as of today will become<br>
> the new board file problem, overburdening the arch/* tree.<br>
> Maybe I'm mistaken as to the size of these things,<br>
> but just doing ls arch/arm/mach-omap2/powerdomain*<br>
> makes me start worrying.<br>
<br>
</div>Yes, I agree that this means more code/data in arch/arm/mach-*, but<br>
IMO, that's really where it belongs.  It really is SoC integration<br>
details, and driver should really not know about it.</blockquote><div><br>OK we need feedback from ARM SoC on this.<br><br>Yours,<br>Linus Walleij<br></div></div>