Re: dev->status.power and future of DPM_

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

>  I'd like the driver core to know which
> callbacks that have been called for each device.

Once you know what part of the hibernation sequence (i.e., which round)  
you've gotten to, the information about callbacks can be obtained from
dev->power.status.  That's what it's meant for.

> >> 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 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".

Alan Stern

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux