Re: [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you?

[Pavel Machek <pavel@suse.cz>]

Hi!

> > Patrick: As we discussed on IRC, the actual PM state constants you
> > defined don't match the old "S" levels, thus this code in ide-disk
> > suspend notifier:
> > 
> >                 if (rq->pm->pm_state == 4)
> >  
> > to avoid stopping the platter on  suspend-to-disk will not work.
> > 
> > Should I fix the above to use a PM_* constant or will you fix the
> > constants ?
> 
> It should definitely be checking for a defined constant. 
> 
> However, I don't think we necessarily want to pass the system state we're 
> entering to the drivers. It's per-driver policy to decide what device 
> state to enter for each system state, which are orthogonal to the runtime 
> device states that it could enter. 
> 
> For most devices, it's going to be 'off' (aka 3) for either suspend-to-ram 
> or -disk. But, some devices will have varying or non-standard behavior. 
> Like IDE drives or those few instances of ATI video devices on some power 
> books that can only go into D2 instead of D3 on STR. 
> 
> To remedy this, I say we commit to the fact that it is the device state 
> that's being passed down to the drivers. But, we get that state for each 
> device from a field in the devices' power structures: 
> 
> 
> struct dev_pm_info { 
> 	...
> 	u32	str_state;
> 	u32	std_state;
> };
> 
> The bus will be able to set these on device registration, or the driver on 
> binding. We can also expose them through sysfs to let userspace policy 
> modify them. Otherwise they will default to the standard (3 aka 'off'). 
> 
> What do you think? 

I do think this is a bit complicated. I believe passing level, along
with type of the suspend (aka swsusp vs. S4bios) should be enough.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]