On Fri, May 15, 2009 at 12:28 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 14 May 2009, Magnus Damm wrote: > >> So let's look at it from a different angle then. Today there are many >> SoCs on the market from multiple vendors, and they all need to be >> power managed somehow. Upstream linux is not very good at it, > > The reason is that there aren't enough runtime power management > implementations for anybody to know how a good design should work. > What parts belong in the core, what parts belong in the driver, what > parts belong in arch-specific code, and so on? There's no consensus > and so there's no upstream development. I guess that itself may be a result of the good old embedded snapshot development strategy... Fortunately many embedded developers know better today. >> some >> vendors have many out-of-tree patches for these things. For SuperH we >> have no power management code out-of-tree so _now_ we have a good >> chance of implementing something upstream that multiple architectures >> can make use of. > > Maybe. If you're really clever about it... I'm pretty confident that we can come up with something. >> Paul Walmsley, Kevin Hilman and I discussed this during last Embedded >> Linux Conference last month. From architecture perspective both Arm >> and SuperH need to be able enter deep sleep states. For this to happen >> we need the ability to save and restore device context during run >> time. >> >> Do you have any recommendation for us? > > Device context cannot be saved and restored in a centralized manner, as > far as I can see. The requirements vary too widely among the different > buses and device types. There's no choice but to rely on individual > drivers or bus subsystems to take care of the details. I totally agree. I'd like to extend the platform bus and see where that takes us. > So while it might make sense to have a central core invoke various > methods to tell drivers when certain power-management events need to > happen, the actual details of these events (like the device context or > power state) cannot be handled by the core. As a corollary, you > shouldn't try to put a bunch of new runtime-PM-related fields in the > core data structures. And you should think twice about reusing the > fields designed for system PM, because the issues are rather > different. Right. I will avoid putting device or bus specific data in common data structures. =) > Even so, there are plenty of difficulties. What should the various > methods be? What should the "certain power-management events" be? > When should they occur? To be truly acceptable upstream, your > solutions will have to work on everything from a SoC to a > supercomputer. Yes, but we have examples like NUMA which runs on both ends of the spectrum. > Solving these problems in the domain of USB alone was reasonably > straightforward, because there we know exactly what the possible states > and power transitions are. Even so, it involved a good deal of code > and it evolved over a long period of time. Doing the equivalent for an > entire system will require a tremendous development effort. Fortunately we have data sheet, time and upstream development experience already. I agree that going from where we are now to perfect will take a long time. But step by step. Thanks for your comments and help! / magnus _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
