On Fri, May 15, 2009 at 11:59 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 15 May 2009, Magnus Damm wrote: > >> Ok. But these messages are only show what is happening during one >> "run". There is no information of what has happened what I can tell. >> So for suspend-to-disk we may end up with one round of PMSG_FREEZE and >> another of PMSG_HIBERNATE. > > You mean that you'd like to know when the system is in the middle of a > power transition, such as during the time while the memory image is > being assembled (PMSG_FREEZE has been sent but not PMSG_HIBERNATE). > Right? > > AFAIK that information isn't stored explicitly anywhere, but it could > be added easily enough. Good! >> >> I'd like to keep the state of each device somewhere. >> > >> > You can't, or at least, you can't keep it anywhere under dev->power. >> > That's because the "state" is very device-specific or bus-specific. >> > It's not possible to come up with any sort of general indicator that >> > applies to all devices. >> >> Not even information like SUSPENDED, FROZEN or OFF? That's pure >> software state IMO. > > Let's put it this way: Yes, SUSPENDED/FROZEN/OFF is software state. > In other words, it's really the state of the _driver_ (since the driver > is software). It isn't the device state; that is, it's not a hardware > state. So yes, you can keep that information -- but it's not what you > said you wanted; above you said you wanted to keep the state of each > _device_ somewhere. I'd like to keep the state of the driver _instance_. Basically what struct device represents. Not struct device_driver. Sorry for being unclear, I mean struct device when I use the word device. Driver and hardware specific state and information should be kept out of common data structures. But that's just common sense, no? Same as keeping bus specific information together with the bus data structures. So to clarify, we have many drivers with multiple driver instances on SuperH. A good example is the CEU platform driver, each driver instance (video capture) is hooked up to a hardware block located somewhere in io memory space. We have one struct device_driver but may have multiple struct devices. I'm interested in the state of struct device. >> I mean "frozen". For the SuperH Mobile SoCs we enter sleep modes >> through the sleep instruction. Since we need run time power management >> we don't control the power of each device though suspend callbacks. >> Actually, there is not much to control except clocks and they are >> handled through the clock framework already. What we want to do is to >> mark the device as idle, and at the time of entering cpuidle we check >> if all devices are idle, and if so we freeze the devices and enter the >> deep sleep mode. > > I don't understand what you mean by "we freeze the devices". How about this: "execute some struct device ->freeze() callbacks and take a note of this by putting driver instances in FROZEN state". Does it make more sense? Thanks, / magnus _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
