From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GBuKp-0002lG-Mp for qemu-devel@nongnu.org; Sat, 12 Aug 2006 10:19:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GBuKo-0002kv-1i for qemu-devel@nongnu.org; Sat, 12 Aug 2006 10:19:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GBuKn-0002ks-S4 for qemu-devel@nongnu.org; Sat, 12 Aug 2006 10:19:29 -0400 Received: from [65.74.133.4] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GBuQA-0002DP-U2 for qemu-devel@nongnu.org; Sat, 12 Aug 2006 10:25:03 -0400 From: Paul Brook Subject: Re: [Qemu-devel] qemu usb-linux.c vl.h hw/esp.c hw/lsi53c895a.c ... Date: Sat, 12 Aug 2006 15:19:24 +0100 References: <44DDCA19.4030903@bellard.org> In-Reply-To: <44DDCA19.4030903@bellard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608121519.24867.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org [following up to record the discussion on IRC] On Saturday 12 August 2006 13:31, Fabrice Bellard wrote: > About async USB, maybe some simplifications are possible. When you have > a real USB controller, there is always a single current request and you > don't neep to have provisions to handle several ones (of course more > complicated host controllers could do that, but it is not useful to > model it now). Moreover, the devices must reply to the request > immediately so the request are asynchronous just because it takes a few > uS to send the data, not because the device blocks (I am not sure it is > clear for you). Right. It depends which level of the USB spec you're looking at. At the low level (frames) USB is a bus system. Each TD is send on the bus in turn, and the device responds immediately (with a NAK if it is not ready to handle the request). However at a higher level (endpoints) USB Bulk (and Control) transfers can be considered to be concurrent packet streams. This is closer to the level at which the current async support was intended to work. With OHCI this matches the interface presented by the host controller. With UHCI a bit of guesswork is needed to recover this from the low-level frame/queue structures. Paul