Greg, see below...
On Thu, 1 Feb 2007, Oliver Neukum wrote:
> Am Donnerstag, 1. Februar 2007 15:51 schrieb Alan Stern:
> > On Wed, 31 Jan 2007, Oliver Neukum wrote:
> >
> > > This would call mod_timer() for every completed in-URB. Are you
> > > sure this is better than an approach maintaining a periodical timer
> > > and check for IO in the meantime?
> >
> > I think we can have it both ways. Add an atomic bitflag to the usb_device
> > structure and have the autosuspend work routine check whether the flag is
> > set. If it is, just restart the timer. The HID driver can simply set the
> > flag whenever an URB is received.
>
> This is exactly what I am doing in the HID driver, just with a private
> timer. It is true that the timer could be switched off if other interfaces
> preclude suspending the device anyhow, but apart from that I just
> don't see the point in putting a specialised mechanism into generic code.
For one thing, it would allow you to avoid adding an extra timer and
simplify the changes to the HID driver.
The mechanism isn't as specialized as all that. It's a polling-based
system for autosuspend in addition to the current notification-based
system. And the generic part amounts to little more than two lines of
code.
> > There are other changes we should make that would go along with this.
> >
> > The existing bitfields in usb_device should be changed over
> > to atomic bitflags, to make them SMP-safe.
>
> Is this needed?
Maybe not. But if we add this "don't-autosuspend-yet" bitflag then it
won't hurt to convert the others as well, and I always feel a little
unsafe having bitfields that aren't explicitly under the protection of
some lock.
> > We should add a similar "suspend" attribute file. Writing
> > "1" would immediately suspend and "0" would immediately resume
> > the device. This will allow userspace to micro-manage the
> > device state and will replace the deprecated power/state file.
>
> In which way will this avoid that interface's principal problems?
It's a separate matter; it has nothing specifically to do with usbhid.
But people have been talking about things like suspending the mouse from
userspace, and this would give them a way to do it.
> Currently, we know that a driver has either requested autosuspend
> and thus should be prepared to suspend or the guarantees for
> a system wide freeze are valid. We'd need to audit all drivers.
All the USB drivers that support PM. I don't think much work would be
needed. The hub driver wouldn't need any changes. It probably would be
necessary to add some sort of resume-on-demand to usb-storage, so that new
I/O requests could be allowed to proceed.
> > We should write sysfs_add_to_group(), so that these two
> > attributes can be added to the existing device/power
> > subdirectory. (sysfs_remove_from_group() doesn't seem to
> > be needed, but it could be written as well.)
>
> I will not comment on sysfs stuff without prior discussion with the
> sysfs people. I am simply not competent to do so.
Greg should be able to decide. Will there be any problem with creating a
sysfs_add_to_group() routine? Or maybe modify the current
sysfs_create_group() so that it doesn't return an error when the group
already exists but simply merges the new group with the existing one?
> > How does this sound?
>
> A bit too complex with too much change in very important generic code.
I have lumped together a lot of things which obviously would have to be
implemented in separate patches. The major questions concern:
adding the "don't-autosuspend-yet" bitflag as an optimization
to avoid lots of timer manipulation;
adding the "suspend" attribute for USB devices;
adding sysfs_add_to_group() or modifying sysfs_create_group().
Alan Stern
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
