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

[Patrick Mochel]

> 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? 


	Pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/