Hi,
I have worked with both the Philips UDA1321 and UDA1325. They both have
very long reset times, during which they do not respond to bus traffic. I
think it is around 300ms of reset times. I don't recall if it was both from
power on AND USB bus reset or just power on. Windows retries enumeration
several times, with very long timeouts.
The Windows reset conditions are more complicated than you show below. I
have only checked on Win98 and Win98SE, but on those versions, after a
device is detected, as device 0, Windows asks for the device descriptor,
but only reads 8 bytes and doesn't request the rest of the descriptor.
Device writers get confused by this because windows asks for n bytes for
the device descriptor and only reads the first 8. Windows hosts lie, but
retry and reset in several different modes trying to get enumeration to
work. Windows will re-read 300 byte descriptors several times, presumably
for the different levels of drivers in the OS.
On the other side, many devices (such as the Philips audio chips above) lie
about their capabilities. That is, the descriptors say they have
capabilities that in fact crash the chip.
Many devices have software controlled pull-up resistors to allow long
powerup/reset times and then they announce themselves on the bus by pulling
up D+ or D- to show their speed and readiness for enumeration. I think
retrying enumeration for all devices is needed, cause several things can
cause a device to fail once, and then enumerate later when it is ready.
At 09:53 PM 6/9/01 +0200, you wrote:
>Hi,
>I'm currently fighting with the timing in hub.c...
>
>The Polestar USB audio device (with the Philips UDA1321) doesn't work anymore
>with the current hub code (it worked a long time ago), the result after a
>plugin is the usual "USB device not accepting new address". This happens
>with both UHCI and OHCI, so it's not a HCD issue.
>
>When inserting a wait_ms(300) in usb_hub_port_reset, it gets detected at the
>second try, with a larger delay is works at the first try. However this long
>delay is not applicable with the current "single-device handling" of hub.c,
>since it would take too long for more than a few connected devices... But
>the long delays are obviously needed for some devices.
>
>Any ideas (ehm.. volunteers) to solve that issue?
>
>Another observation:
>
>Some early engineering samples of the Ericsson USB-Bluetooth modules also
>have problems, they used to work after manually shorting D- to GND, but that
>doesn't also work anymore. I haven't found a workaround for that yet.
>
>However, the modules are properly detected in Windows 2000, so Linux
>apparently does something wrong.
>
>BTW: The USB-analyzer showed a very interesting init sequence for Windows:
>
>20ms USB-Reset
>Get device descriptor (64bytes)
>15ms USB-Reset
>Set address
>Get device descriptor
>...
>
>--
> Georg Acher, [EMAIL PROTECTED]
> http://www.in.tum.de/~acher/
> "Oh no, not again !" The bowl of petunias
>
>_______________________________________________
>[EMAIL PROTECTED]
>To unsubscribe, use the last form field at:
>http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
