On Thu, 5 Jan 2006, Pavel Machek wrote:

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

quoted

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.

quoted

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.

quoted

I don't understand what you're saying. If I have a driver that Iwant to

                                         ~~~~~~~~~~~~~~~~~~

quoted

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.

quoted

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