Date: Sun, 15 Jul 2007 11:18:28 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: "Xiaofan Chen" <xiaofanc@gmail.com> Cc: freebsd-usb@freebsd.org Subject: Re: libusb usb_interrupt_read hangs under FreeBSD Message-ID: <200707151118.28211.hselasky@c2i.net> In-Reply-To: <a276da400707131533h4fb77751r2a288007887438a0@mail.gmail.com> References: <a276da400704030427g6fcfdc37u43bdf0fd1cd69ea8@mail.gmail.com> <200707091835.50445.hselasky@c2i.net> <a276da400707131533h4fb77751r2a288007887438a0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 14 July 2007 00:33, Xiaofan Chen wrote: > On 7/9/07, Hans Petter Selasky <hselasky@c2i.net> wrote: > > Perhaps what happens is that the "*pDst.bRam =3D _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? The USB 2.0 specification is not very clear about what the clear-stall comm= and=20 should do. It almost says that this is device dependant. I think that clear-stall should only clear the data-toggle ! It should not= =20 clear any buffers. That should be done by a seperate control transfer. The thing is: If you start a BULK in transfer for example, then you abort t= his=20 transfer, then what should the next data-toogle be? If it is wrong you will= =20 loose a data-packet without notification! Therefore ugen always clears stal= l=20 first. According to the USB2.0 specification: <cite> =B7 STALL is returned by a function in response to an IN token or after the data phase of an OUT or in response to a PING transaction (see =46igure 8-30 and Figure 8-38). STALL indicates that a function is unable to transmit or receive data, or that a control pipe request is not supported. The state of a function after returning a STALL (for any endpoint except the default endpoint) is undefined. The host is not permitted to return a STALL under any condition. The STALL handshake is used by a device in one of two distinct occasions. The first case, known as "functional stall," is when the Halt feature associated with the endpoint is set. (The Halt feature is specified in Chapter 9 of this document.) A special case of the functional stall is the "commanded stall." Commanded stall occurs when the host explicitly sets the endpoint's Halt feature, as detailed in Chapter 9. Once a function's endpoint is halted, the function must continue returning STALL until the condition causing the halt has been cleared through host intervention. The second case, known as "protocol stall," is detailed in Section 8.5.3. Protocol stall is unique to control pipes. Protocol stall differs from functional stall in meaning and duration. A protocol STALL is returned during the Data or Status stage of a control transfer, and the STALL condition terminates at the beginning of the next control transfer (Setup). The remainder of this section refers to the general case of a functional stall. </cite> > > 2) For the host, how does it know that the buffer data is still correct if > the buffer is not cleared? Clear stall should only clear the data toggle! You need a second control command to reset the buffers and/or the protocol! > > 2) What cause the stall to happen in the first place? It is either a wrong data-toggle bit or a protocol error. The device can se= nd=20 stall at any time! =2D-HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707151118.28211.hselasky>