Stephen Boyd <sboyd@xxxxxxxxxxxxxx> writes: > On 09/25, Thierry Reding wrote: [...] >> The critical part is that we need to enable the clock after the >> partition has been powered, but before the clamps are removed. >> Implementing this with runtime PM support in drivers won't work >> because the power domain driver has to do both the powering up >> and removing the clamps, so there's no place to inject the call >> to enable the clock. > > FWIW, Qualcomm platforms have pretty much the same design. Our > power domain controls live in the same register space as the > clocks and resets. Is Tegra the same way? To power on/off a > domain we need to go and forcefully turn a clock on and assert a > reset or perhaps we need the clock to be off and assert a reset. > It depends on the domain. > > Historically we've supported this by requiring all drivers to > disable their clocks and deassert any resets before calling into > this code (we put this behind the regulator API). Then we're free > to do whatever is necessary to power on/off, eventally leaving > the clocks off if they were forced on and finally giving control > to the drivers so they can manage their own clocks and resets. It > would be better for us to take ownership of the clocks and resets > in the domain so we don't have this prerequisite of clocks being > off before calling into the domain code. I plan to do pretty much > Kevin outlined and use runtime PM, power domains, and per-device > pm QoS to figure out if we should gate clocks (clk_disable), or > if we go to a lower power mode where we unprepare clocks > (clk_unprepare), or if we go to the lowest power mode where we > apply clamps, etc. (called power collapse for us). Then the > drivers just interact with runtime PM and QoS and they aren't > aware of all this SoC glue. Excellent! I'm glad you're heading in that direction. One other important point here is that keeping drivers "simple" like this makes it much easier for them to stay portable across SoCs. Also, neither tegra or qcom are unique here. FWIW, OMAP has similar ordering requirements, and quite a bit of "stuff" to properly get a device and powerdomain to actually power down (and power up) properly. The OMAP implementation pre-dates runtime PM, power domains etc. so we hid all of this behind the omap_hwmod abstraction and the omap_device API where all clocks, resets, and various other magic is handled, and so that device drivers didn't have to care about the details. These days, those APIs are now used by the OMAP pm_domain implementation (which pre-dates genpd), so drivers (still) don't have to care about the details only have to care about runtime PM and QoS. After genpd came along, the goal was to convert OMAP to it, but well, other circumstances have changed things such that those working in that area are, um..., somewhat less focused on OMAP. ;) Kevin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
