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

Pavel Machek
2003-09-09T22:56:41Z

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