qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 04/12] usb: Add support for input pipelining
Date: Tue, 09 Oct 2012 16:19:51 +0200	[thread overview]
Message-ID: <50743287.905@redhat.com> (raw)
In-Reply-To: <50742728.2020601@redhat.com>

Hi,

On 10/09/2012 03:31 PM, Gerd Hoffmann wrote:

<snip>

>>> 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.
>

Right.

<snip>

>> 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.
>

It is not much, but you rightly called it "magic" before, as it is somewhat
tricky code, so better to write (and debug) it once :)

> 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).

That is more or less what I had in mind yes :)

> 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?

I think core.c is getting a bit crowded, so I'll go with a new file for
the next revision, if you don't like that moving the functions someplace
else is easy :)

I'll start working on a new reworked version of the patchset which hopefully
will be more to your liking :)

Regards,

Hans

  reply	other threads:[~2012-10-09 14:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-08  7:51 [Qemu-devel] [PATCH 00/12] RFC: usb: input pipelining support and other speedups Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 01/12] usb-redir: When a packet contains data on a stall, ignore the stall Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 02/12] usb-redir: Add support for 32 bits bulk packet length Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 03/12] usb-host-linux: Only enabling pipeling for output endpoints Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 04/12] usb: Add support for input pipelining Hans de Goede
2012-10-08 12:50   ` Gerd Hoffmann
2012-10-08 14:50     ` Hans de Goede
2012-10-09  9:21       ` Gerd Hoffmann
2012-10-09 10:40         ` Hans de Goede
2012-10-09 13:31           ` Gerd Hoffmann
2012-10-09 14:19             ` Hans de Goede [this message]
2012-10-08  7:51 ` [Qemu-devel] [PATCH 05/12] uhci: Properly unmap packets on cancel / invalid pid Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 06/12] uhci: Move checks to continue queuing to uhci_fill_queue() Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 07/12] uhci: Add support for input queuing Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 08/12] ehci: Get rid of packet tbytes field Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 09/12] ehci: Set int flag on a short input packet Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 10/12] ehci: Add support for input queuing Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 11/12] ehci: Improve latency of interrupt delivery and async schedule scanning Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 12/12] ehci: Speed up the timer of raising int from the async schedule Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50743287.905@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).