Re: [linux-pm] [patch] pm: fix runtime powermanagement's /sysinterface

[Patrick Mochel]

On Thu, 5 Jan 2006, Pavel Machek wrote:

> On Ät 05-01-06 14:15:39, Patrick Mochel wrote:

> > It should be replaced with a file exported by the bus driver that exports
> > the actual states that the device supports. The parsing can easily happen
> > at this point, because the bus knows what a good value is.
>
> (1) would change core<->driver interface

It's broken anyway for runtime power management.

> (2) is quite a lot of work

In the long run, it's not.

> (3) ...with very little benefit, until drivers support >2 states

Without it, you are preventing drivers from being able to support > 2
states.

> I want to fix invalid values being passed down to drivers, not rewrite
> half of driver model.

Please don't exaggerate the issue.

> If you want to rewrite driver model for >2 states, great, but that is
> going to take at least a year AFAICS, so please let me at least fix
> the bugs in meantime.

It's a band-aid; it is not a long-term solution.

> > The userspace interface is broken. We can keep it for compatability
> > reasons, but there needs to be a new interface.
>
> I assumed we could fix the interface without actually introducing >2
> states support. That can be done in reasonable ammount of code.

The interface is irreparably broken. You can't fix it with an infinite
number of band aids.

> > I don't understand what you're saying. If I have a driver that Iwant to
>                                          ~~~~~~~~~~~~~~~~~~
> > make support another power state and I'm willing to write that code, then
> > there is a clear benefit to having the infrastructure for it to "just
> > work".
>
> I do not see such drivers around me, that's all. It seems fair to me
> that first driver author wanting that is the one who introduces >2
> states support to generic infrastructure.

Just because you personally have not seen such things does not mean they
do not exist.

> > If you want a more concrete example, consider the possibility where it may
> > be possible to reinitialize the device from D1 or D2, but not from D3. For
> > the radeon, this is true in some cases (if I understand Ben H
> > correctly).
>
> ...which seems like one more reason to only export "on" and "off" in
> radeon case. We don't want userspace to write "D3" to radeon, then
> wondering why it failed.

User application translates e.g. -EINVAL into "State not supported."

> Passing "on"/"off" down to radeon lets the driver decide what power
> state it should enter.

Driver implements power state policy? Sounds like that policy would find a
much more comfortable home in userspace.

Thanks,


	Patrick

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