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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
