From owner-freebsd-usb@FreeBSD.ORG Sun Jul 15 09:18:31 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2B7F16A400 for ; Sun, 15 Jul 2007 09:18:31 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 13D8A13C461 for ; Sun, 15 Jul 2007 09:18:30 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 377409740; Sun, 15 Jul 2007 11:18:24 +0200 From: Hans Petter Selasky To: "Xiaofan Chen" Date: Sun, 15 Jul 2007 11:18:28 +0200 User-Agent: KMail/1.9.5 References: <200707091835.50445.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707151118.28211.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: libusb usb_interrupt_read hangs under FreeBSD X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 09:18:31 -0000 On Saturday 14 July 2007 00:33, Xiaofan Chen wrote: > On 7/9/07, Hans Petter Selasky 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: =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. > > 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