On Thu, May 9, 2013 at 3:14 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote: >> On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote: >> >> > However, if a device that shuts down resources after init has >> > completed and then cannot turn those resources back on when another >> > driver requests them then it sounds like there is a bigger design >> > problem. We're in a hotplug world and most of the time a driver cannot >> > assume that a resource will never get requested after initcalls have >> > completed. It sounds like a design bug in the driver if it cannot >> > handle that use case. >> >> Even if the driver copes fine it can still be desirable to avoid the >> power down/up cycle if it involves some user visible effect - things >> like blinking the display off then on for example. That said I am a >> little suspicious about this approach, it doesn't feel as robust as it >> should to go round individual callers. > > What if the driver for something like your display is a module which > needs to be loaded from userland? > > Where the design bug lies is in the "lets probe all the drivers and then > shut down resources which drivers haven't claimed". That contains an > implied assumption: that all drivers have been loaded and probed at the > point where you shut down those resources. > > That simply may not be true in todays kernel - it's not true for a start > if you have modular drivers, and you have built most of the drivers as > modules (as a distro would want to with single zImage). It's > coincidentally not true if you have deferred probing and some drivers > defer. > > The real problem is this: at what point has the system actually finished > "booting" in the sense that all drivers for a platform have been > initialised? With user loadable modules and deferred probing, that's > actually a very fuzzy concept. > > As you can't really tell when that point has been reached, how can you > decide to shut down resources which "aren't being used" in a sane way > without avoiding the down/up cycle? Basically, you can't. > > So, trying to solve the problem may be totally fruitless because you > can't actually solve it - you can only put a sticky plaster over it and > hope that it catches most of the problem. But reality is that you can't > have both a shutdown of unused resources _and_ avoid the down/up cycle. +1. You can /minimize/ up-down cycles with the kind of optimization that is being attempted here, but the driver still *must* deal with bringing resources back up if they get requested "later than you would otherwise like". g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
