lkml.org 
[lkml]   [2003]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you?
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?]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.141 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site