From: Sarah Sharp <hidden> Date: 2012-05-17 04:52:20
On Wed, May 16, 2012 at 04:20:19PM -0700, Greg Kroah-Hartman wrote:
On Wed, May 16, 2012 at 03:45:28PM -0700, Sarah Sharp wrote:
quoted
[Resending with a smaller Cc list]
Hub-initiated LPM is not good for USB communications devices. Comms
devices should be able to tell when their link can go into a lower power
state, because they know when an incoming transmission is finished.
Ideally, these devices would slam their links into a lower power state,
using the device-initiated LPM, after finishing the last packet of their
data transfer.
If we enable the idle timeouts for the parent hubs to enable
hub-initiated LPM, we will get a lot of useless LPM packets on the bus
as the devices reject LPM transitions when they're in the middle of
receiving data. Worse, some devices might blindly accept the
hub-initiated LPM and power down their radios while they're in the
middle of receiving a transmission.
The Intel Windows folks are disabling hub-initiated LPM for all USB
communications devices under a xHCI USB 3.0 host. In order to keep
the Linux behavior as close as possible to Windows, we need to do the
same in Linux.
How is the USB core on Windows determining that LPM should be turned off
for these devices? Surely they aren't modifying each individual driver
like this is, right? Any way we also can do this in the core?
No, I don't think they're modifying individual drivers. Maybe they
placed a shim/filter driver below other drivers?
Basically, I don't know the exact details of what the Windows folks are
doing. The recommendation from the Intel Windows team was simply to
turn hub-initiated LPM off for "all communications devices". Perhaps
the Windows USB core is looking for specific USB class codes? Or maybe
it has some older API that lets the core know it's a communications
device?
I'm not really sure we can do it in the USB core with out basically
duplicating all the class/PID/VID matching in the communications driver.
I think just adding a flag might be the best way. I'm open to
suggestions though.
Or, turn it around the other way, and only enable it if we know it's
safe to do so, in each driver, but I guess that would be even messier.
On Wed, May 16, 2012 at 09:52:20PM -0700, Sarah Sharp wrote:
On Wed, May 16, 2012 at 04:20:19PM -0700, Greg Kroah-Hartman wrote:
quoted
On Wed, May 16, 2012 at 03:45:28PM -0700, Sarah Sharp wrote:
quoted
[Resending with a smaller Cc list]
Hub-initiated LPM is not good for USB communications devices. Comms
devices should be able to tell when their link can go into a lower power
state, because they know when an incoming transmission is finished.
Ideally, these devices would slam their links into a lower power state,
using the device-initiated LPM, after finishing the last packet of their
data transfer.
If we enable the idle timeouts for the parent hubs to enable
hub-initiated LPM, we will get a lot of useless LPM packets on the bus
as the devices reject LPM transitions when they're in the middle of
receiving data. Worse, some devices might blindly accept the
hub-initiated LPM and power down their radios while they're in the
middle of receiving a transmission.
The Intel Windows folks are disabling hub-initiated LPM for all USB
communications devices under a xHCI USB 3.0 host. In order to keep
the Linux behavior as close as possible to Windows, we need to do the
same in Linux.
How is the USB core on Windows determining that LPM should be turned off
for these devices? Surely they aren't modifying each individual driver
like this is, right? Any way we also can do this in the core?
No, I don't think they're modifying individual drivers. Maybe they
placed a shim/filter driver below other drivers?
They can do this in their driver by just watching the device class type.
Basically, I don't know the exact details of what the Windows folks are
doing. The recommendation from the Intel Windows team was simply to
turn hub-initiated LPM off for "all communications devices". Perhaps
the Windows USB core is looking for specific USB class codes? Or maybe
it has some older API that lets the core know it's a communications
device?
I'm not really sure we can do it in the USB core with out basically
duplicating all the class/PID/VID matching in the communications driver.
I think just adding a flag might be the best way. I'm open to
suggestions though.
You can detect something as "simple" as a class type, which I bet is all
that Windows is going to be able to do as well.
quoted
Or, turn it around the other way, and only enable it if we know it's
safe to do so, in each driver, but I guess that would be even messier.
Yeah, I think it would be messier.
Ok, this is probably the best solution for us as well, sorry for the
noise.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Sarah Sharp <hidden> Date: 2012-05-17 16:29:41
On Thu, May 17, 2012 at 07:49:51AM -0700, Greg Kroah-Hartman wrote:
On Wed, May 16, 2012 at 09:52:20PM -0700, Sarah Sharp wrote:
quoted
On Wed, May 16, 2012 at 04:20:19PM -0700, Greg Kroah-Hartman wrote:
quoted
On Wed, May 16, 2012 at 03:45:28PM -0700, Sarah Sharp wrote:
quoted
The Intel Windows folks are disabling hub-initiated LPM for all USB
communications devices under a xHCI USB 3.0 host. In order to keep
the Linux behavior as close as possible to Windows, we need to do the
same in Linux.
How is the USB core on Windows determining that LPM should be turned off
for these devices? Surely they aren't modifying each individual driver
like this is, right? Any way we also can do this in the core?
No, I don't think they're modifying individual drivers. Maybe they
placed a shim/filter driver below other drivers?
They can do this in their driver by just watching the device class type.
quoted
Basically, I don't know the exact details of what the Windows folks are
doing. The recommendation from the Intel Windows team was simply to
turn hub-initiated LPM off for "all communications devices". Perhaps
the Windows USB core is looking for specific USB class codes? Or maybe
it has some older API that lets the core know it's a communications
device?
I'm not really sure we can do it in the USB core with out basically
duplicating all the class/PID/VID matching in the communications driver.
I think just adding a flag might be the best way. I'm open to
suggestions though.
You can detect something as "simple" as a class type, which I bet is all
that Windows is going to be able to do as well.
quoted
quoted
Or, turn it around the other way, and only enable it if we know it's
safe to do so, in each driver, but I guess that would be even messier.
Yeah, I think it would be messier.
Ok, this is probably the best solution for us as well, sorry for the
noise.
No worries. :)
One of the problems with this patch is that several mailing lists
rejected it because of the large number of recipients in the Cc list,
even when just the mailing lists were on the Cc list. Should I break it
up into a series of patches per driver?
Also, do I need to wait on acks from the other maintainers for this
change? My instinct is no, since it shouldn't change the behavior of
their drivers with the USB devices that are out there today, but I don't
want to step on anyone's toes.
Sarah Sharp
On Thu, May 17, 2012 at 09:29:22AM -0700, Sarah Sharp wrote:
One of the problems with this patch is that several mailing lists
rejected it because of the large number of recipients in the Cc list,
even when just the mailing lists were on the Cc list. Should I break it
up into a series of patches per driver?
No need to do that, I can just take it.
Also, do I need to wait on acks from the other maintainers for this
change? My instinct is no, since it shouldn't change the behavior of
their drivers with the USB devices that are out there today, but I don't
want to step on anyone's toes.
Don't worry about it, we change USB drivers in other trees all the time :)
greg k-h