From: Jon Nettleton <[EMAIL PROTECTED]>
To: Steve Calfee <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] ehci_hcd proper negotiation down to usb 1.1
Date: Thu, 06 Oct 2005 20:58:01 -0400
On Thu, 2005-10-06 at 15:39 -0700, Steve Calfee wrote:
> At 01:51 PM 10/4/2005 -0400, Alan Stern wrote:
>
> >On Tue, 4 Oct 2005, Jon Nettleton wrote:
>
> >> > > Unloading the
> > >> > ehci_hcd with this cable and just using uhci_hcd produced a
> >functioning
> > > >> device. Using a USB 2.0 cable with the ehci_hcd driver also
produced
> >a
> >> > > functioning device. > > > > It is my understanding that the 1.1
> >>cable should cause the driver to
> >> > > fallback to the 1.1 protocol.
> >> > > No. Using a bad cable should cause the connection to fail, as
you
> >>saw.
> >>
> >>Why is a low speed cable considered bad, when it is just not high
speed?
>
> >There are physical differences between the two types of cable, most
notably
> >in the amount of shielding that protects the data lines from noise.
> >High-speed signals really need that extra shielding; being so quick,
they
> >are easily perturbed by even small amounts of noise and distortion.
>
>
> In terms of cables there is only one USB cable. (ignoring mini
connectors
> and OTG issues for now). There is a USB.org legal cable spec for low
speed,
> but one end must be "captured" in a low speed device. This means that a
low
> speed cable can only be used with that one low speed device. Think USB
mouse
> or keyboard for instance where they have a usb cable coming out of their
> device. The low speed cable allows very low cost devices.
>
> However, there are low quality cables, just as there are low quality
> operating systems :) Cables and hardware can and do fail.
>
> >>Is there a functionality reason not to try to force the hub port down
to
> >>usb 1.1 and try to connect that way? This is honest question I am not
> >>trying to start a flame war on the subject. :-)
>
> >In principle this is possible. Linux doesn't do it, though. And in
any
> >case, full speed and high speed both require the same kind of shielded
> >cable -- it's only low speed that can get away with less shielding.
> >Forcing the connection to low speed is not possible.
>
> >If enough people clamor for a fall-back-to-full-speed feature, maybe
> >someone will implement it. However I suspect that it won't really be
> >popular. People expect their high-speed devices to run at high speed
and
> >won't be happy if they don't.
>
> If you have a low quality cable, it is possible the high speed chirping
will
> not work, so it will fall back to full speed anyway. Flakiness in a
> communications connection is always a problem. The big problem with
> downshifting to full speed is trying to determine when is the
appropriate
> time. And the speed is determined during the device reset, so to
downshift
> would require resetting the device. And then somehow convincing the EHCI
> controller to ignore the chirp, and use a companion for a full speed
device.
> This could be a major source of unintended consequences.
>
> >From the USB 2.0 spec:
>
> 6.4 Cable Assembly
> This specification describes three USB cable assemblies: standard
detachable
> cable, high-/full-speed
> captive cable, and low-speed captive cable.
> A standard detachable cable is a high-/full-speed cable that is
terminated
> on one end with a Series “A” plug
> and terminated on the opposite end with a series “B” plug. A
> high-/full-speed captive cable is terminated
> on one end with a Series “A” plug and has a vendor-specific
> connect means (hardwired or custom
> detachable) on the opposite end for the high-/full-speed peripheral. The
> low-speed captive cable is
> terminated on one end with a Series “A” plug and has a
> vendor-specific connect means (hardwired or
> custom detachable) on the opposite end for the low-speed peripheral. Any
> other cable assemblies are
> prohibited.
>
>
> The spec also forbids extension cables, and I have two devices that came
> with them. Protocols are rules. People violate rules. Expecting an OS to
get
> around violations can be a never ending game.
>
> Regards ~Steve
>
>
One last question on this thread for those that know the drivers and the
hardware. What is the best explanation for the fact that the low
quality cable works flawlessly with the uhci-hcd driver and the same
hardware. Obviously the data transfers run at a slower rate, however
the ehci_hcd driver won't even negotiate a connection. If you don't
have the time to answer this don't bother, I am just curious.
Thanks for your time.
Jon
