[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 04/12] usb: Add support for input pipelining
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [PATCH 04/12] usb: Add support for input pipelining |
Date: |
Tue, 09 Oct 2012 15:31:20 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120825 Thunderbird/10.0.7 |
Hi,
>>> 2a) The combining entity needs to know when the hcd is done with
>>> queuing up packets for an ep.
>>
>> Yes. We can add a USBDeviceClass method for that.
>
> Ok, this assumes that the combining / uncombining gets moved down
> into the usb-device level code. Which clearly has your preference,
> but I don't completely agree with, so lets have that discussion first,
> once we've decided what to do there, details like this will likely
> sort out themselves.
Yes.
>> The core can and should do that for packets it owns (USBPacketState ==
>> USB_PACKET_QUEUED) because they are not (yet) passed to the USBDevice.
>>
>> Packets owned by USBDevice (USBPacketState == USB_PACKET_ASYNC) must be
>> handled by the USBDevice itself.
>
> Getting offtopic a bit here, but this not how we currently handle
> things, currently the hcd code cancels packets after a queue halt,
Ah, right. Well, that should continue to work. USB_RET_NOT_USED would
make the hcd code just free the packet, and anything not-yet freed will
be zapped by the queue halt handling.
> Notice that arguments 2 and 3 could be made for combining output packets
> too, but what we do their now is nice and KISS, and the possible speed
> improvement is not worth the complication IMHO.
Handling in/out eps the same way has its merits too (code sharing).
> So again lets try to split the discussion in answering multiple questions:
>
> 1) I believe it is better, and would greatly prefer to, do the combining
> on the qemu side rather then on the usb-redir-host side, do you agree?
Your call, you know the bits much better than I do.
Your arguments make sense.
> 2) If you agree with 1, then I assume you agree we will want to share
> the combining code between host-linux.c (or host-* for that matter) and
> redirect.c ?
I'm not sure there is that much to share.
A helper function which takes a USBEndpoint and returns an iovec for all
USBPackets lined up there would probably be useful. Likewise for one
for completing the packets (takes xfer length + status, then fill
USBPacket->result & call usb_packet_complete for each packet).
But beyond that?
> 3) If you agree with 2, then all we need is a place for the shared logic
> to live, we could put it in a new file called input-pipeline.c ?
Just stick the helpers into hw/usb/core.c?
cheers,
Gerd
- [Qemu-devel] [PATCH 02/12] usb-redir: Add support for 32 bits bulk packet length, (continued)
- [Qemu-devel] [PATCH 02/12] usb-redir: Add support for 32 bits bulk packet length, Hans de Goede, 2012/10/08
- [Qemu-devel] [PATCH 01/12] usb-redir: When a packet contains data on a stall, ignore the stall, Hans de Goede, 2012/10/08
- [Qemu-devel] [PATCH 07/12] uhci: Add support for input queuing, Hans de Goede, 2012/10/08
- [Qemu-devel] [PATCH 08/12] ehci: Get rid of packet tbytes field, Hans de Goede, 2012/10/08
- [Qemu-devel] [PATCH 03/12] usb-host-linux: Only enabling pipeling for output endpoints, Hans de Goede, 2012/10/08
- [Qemu-devel] [PATCH 04/12] usb: Add support for input pipelining, Hans de Goede, 2012/10/08
[Qemu-devel] [PATCH 06/12] uhci: Move checks to continue queuing to uhci_fill_queue(), Hans de Goede, 2012/10/08
[Qemu-devel] [PATCH 05/12] uhci: Properly unmap packets on cancel / invalid pid, Hans de Goede, 2012/10/08
[Qemu-devel] [PATCH 12/12] ehci: Speed up the timer of raising int from the async schedule, Hans de Goede, 2012/10/08
[Qemu-devel] [PATCH 09/12] ehci: Set int flag on a short input packet, Hans de Goede, 2012/10/08
[Qemu-devel] [PATCH 10/12] ehci: Add support for input queuing, Hans de Goede, 2012/10/08
[Qemu-devel] [PATCH 11/12] ehci: Improve latency of interrupt delivery and async schedule scanning, Hans de Goede, 2012/10/08