On Thu, Sep 11, 2014 at 10:22:32AM +0100, Grant Likely wrote: > On Wed, 10 Sep 2014 17:57:23 +0100, Mark Brown <broonie@xxxxxxxxxx> wrote: > > It's not quite as simple as just disabling PM - for example in the > > clocks case we've also got to worry about what happens with rate changes > > (which is going to get more and more risky as we get smarter about being > > able to push configuration changes back up the tree), regulators have a > > similar thing with voltage changes. With simple enables and disables we > > have to worry about things like handling users who actively want to > > power things on and and off but may potentially be sharing a resource > > with an undeclared dependency. > I think we can be okay with the above. This is a best-effort situation > where we don't want to tear down how firmware has set up the board if > it can be reasonably assumed that something depends on it (simplefb). > However, if clocks or regulators are shared with other devices and those > drivers ask for other settings, then there is simply no recourse. In > that situation there must be a driver for the video device that takes > care of any constraints. When things break I'm not sure that users are going to understand that something that used to work for them was only provided on a best effort basis, I think they will expect things to carry on working. It's not going to be great if enabling some driver for a device that happens to be in the same power domain as a component used in a framebuffer causes the display to vanish, or if better power management in an existing driver causes breakage. It's relatively OK to have a brief hiccup during boot but usage seems to have expanded beyond that point and I think we need to take robustness more seriously. Given that we have straightforward ways to communicate resource usage it seems sensible to add robustness to the system by making use of them.
Attachment:
signature.asc
Description: Digital signature
