Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Jul 2007 18:33:13 -0400
From:      "Xiaofan Chen" <xiaofanc@gmail.com>
To:        "Hans Petter Selasky" <hselasky@c2i.net>
Cc:        freebsd-usb@freebsd.org
Subject:   Re: libusb usb_interrupt_read hangs under FreeBSD
Message-ID:  <a276da400707131533h4fb77751r2a288007887438a0@mail.gmail.com>
In-Reply-To: <200707091835.50445.hselasky@c2i.net>
References:  <a276da400704030427g6fcfdc37u43bdf0fd1cd69ea8@mail.gmail.com> <200707051724.30175.hselasky@c2i.net> <a276da400707071725x2b2b8ab3ife6c5459d06042bd@mail.gmail.com> <200707091835.50445.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 7/9/07, Hans Petter Selasky <hselasky@c2i.net> wrote:
>
> Perhaps what happens is that the "*pDst.bRam = _UCPU;"
> command clears the FIFO
> contents of the USB interrupt endpoint in addition to clearing the stall!?
>
> If the sequence is like this:
>
> Write to interrupt endpoint.
> Reply command is written to FIFO.
> Clear interrupt endpoint stall.
> There is no data to read, because the FIFO has been emptied as a part of the
> stall command.
>
> Xiaofan Chen: Could you check the datasheet for the chip that is used, what
> the stall command actually does?
>

Sorry that I have three more questions:
1) What is the correct method to correctly respond to clear halt feature request
in the firmware so that it can still recover from the stall?

2) For the host, how does it know that the buffer data is still correct if the
buffer is not cleared?

2) What cause the stall to happen in the first place?

Xiaofan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a276da400707131533h4fb77751r2a288007887438a0>