we were usug both IHCI and UHCI which is why we didn't mention it.
we DID have a problem one one of them (which seemed unrelated)
but I can't remember which. It was reported by other people around the
same time so we didn't connect it with our driver.
On Tue, 21 Dec 1999, Bill Paul wrote:
> Previously I mentioned that I was having trouble sending full sized
> ethernet frames (1500 bytes) over USB using my ADMtek AN986 Pegasus
> eval board. The problem turned out to be in the uhci driver, however
> I'm not certain exactly how to incorporate my fix.
>
> The problem I was seeing was that large frames would trigger babble
> errors, which would cause an endpoint halt and wedge the RX or TX pipe.
> Julian brought up another driver written by Doug Ambrisko which appeared
> to be able to transfer 1500-byte frames without any trouble. However,
> neither he nor Doug bothered to mention if their test machines had UHCI
> or OHCI hubs. Given what I've learned, I suspect they were OHCI.
> I downloaded a copy of the Intel UHCI spec document from
> ftp://download.intel.com/design/usb/UHCI11D.PDF and scrutinized it
> for a while. On page 17, it describes the MAXP bit in the command
> register. The description reads:
>
> Max Packet (MAXP). 1=64 bytes, 0=32 bytes. This bit selects the
> maximum packet size that can be used for full speed bandwitdh
> reclamation at the end of a frame. This value is used by the
> Host Controller to determine whether it should initiate another
> transaction based on the time remaining in the SOF counter. Use
> of reclamation packets larger than the programmed size will
> cause a Babble error if executed during the critical window at
> frame end. The Babble error results in the offending endpoint
> being stalled. Software is responsible for ensuring that any
> packet which could be executed under bandwidth reclamation be
> within this size limit.
>
> The ADMtek part is documented to use 64-byte USB packets for frame
> transfers. However, /sys/dev/usb/uhci.c:uhci_run() never sets the
> MAXP bit in the command register when it starts the controller running.
> I modified uhci_run() to include the UHCI_CMD_MAXP bit and now the
> ADMtek ethernet controller sends and receives 1500-byte frames with
> no problems.
>
> The question is, how should this be handled? Should the UHCI_CMD_MAXP
> bit be set all the time, or just when high speed devices are attached
> to the bus? The Intel manual seems to imply that it's safe to leave this
> bit enabled all the time, however I can't test this since I only have
> the one USB device. Also, should something similar be done with OHCI
> controllers, or do they handle this sort of thing correctly?
>
> -Bill
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
