xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Patch RFC 2/4] usb: add flag to USBPacket to request complete callback after isoc transfer
Date: Fri, 17 Jul 2015 11:23:29 +0200	[thread overview]
Message-ID: <1437125009.3689.27.camel@redhat.com> (raw)
In-Reply-To: <55A8C07D.1010306@suse.com>

> > --- a/hw/usb/host-libusb.c
> > +++ b/hw/usb/host-libusb.c
> > @@ -451,6 +451,7 @@ static void usb_host_req_complete_iso(struct
> > libusb_transfer *transfer)
> >       }
> >       if (xfer->ring->ep->pid == USB_TOKEN_IN) {
> >           QTAILQ_INSERT_TAIL(&xfer->ring->copy, xfer, next);
> > +        usb_wakeup(xfer->ring->ep, 0);
> >       } else {
> >           QTAILQ_INSERT_TAIL(&xfer->ring->unused, xfer, next);
> >       }
> 
> Hmm, I can see the benefit of this call to avoid polling.
> 
> OTOH I don't see how to find the packages already processed via this
> mechanism. To help in my case I'd need:
> 
> - the call being made in the else clause

Hmm.  This is for IN transfers, notifying the host adapter "I have data
for you, please hand me one (or more) USBPacket which I can fill".

Why do you need it for OUT transfers too?  usb-host has copyed and
queued up the data already, there is nothing to pass back ...

> - some way to have a package reference in the endpoint (assuming
>    to use the bus .endpoint_wakeup callback which is called by
>    usb_wakeup(), too).

Yes, endpoint callback would be more useful for this.
PortOps needs this for remote wakeup implementation.

>    The problem here is that host-libusb.c would call usb_wakeup()
>    not for each packet, but for each libusb I/O, which is combining
>    multiple packets given to usb_handle_packet().

You can call just call usb_handle_packet() multiple times, either
calculate how often based on time and bandwidth, or continue calling
until you get no more data back.

cheers,
  Gerd

  reply	other threads:[~2015-07-17  9:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16 15:47 [Patch RFC 0/4] usb, xen: add pvUSB backend Juergen Gross
2015-07-16 15:47 ` [Patch RFC 1/4] usb: support device specification via <bus>-<port> Juergen Gross
2015-07-17  6:59   ` Gerd Hoffmann
2015-07-17  7:32     ` Juergen Gross
2015-07-17  8:28       ` Gerd Hoffmann
2015-07-17 10:06         ` Juergen Gross
2015-07-17 10:23           ` Gerd Hoffmann
2015-07-17 10:25             ` Juergen Gross
2015-07-16 15:47 ` [Patch RFC 2/4] usb: add flag to USBPacket to request complete callback after isoc transfer Juergen Gross
2015-07-17  8:12   ` Gerd Hoffmann
2015-07-17  8:44     ` Juergen Gross
2015-07-17  9:23       ` Gerd Hoffmann [this message]
2015-07-17 10:14         ` Juergen Gross
2015-07-16 15:47 ` [Patch RFC 3/4] xen: introduce dummy system device Juergen Gross
2015-07-16 15:47 ` [Patch RFC 4/4] xen: add pvUSB backend Juergen Gross

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=1437125009.3689.27.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=jgross@suse.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /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).