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

Patrick Mochel
2003-09-09T21:37:39Z

> 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