From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [Patch RFC 2/4] usb: add flag to USBPacket to request complete callback after isoc transfer Date: Fri, 17 Jul 2015 12:14:50 +0200 Message-ID: <55A8D59A.2090404@suse.com> References: <1437061658-11769-1-git-send-email-jgross@suse.com> <1437061658-11769-3-git-send-email-jgross@suse.com> <1437120751.3689.14.camel@redhat.com> <55A8C07D.1010306@suse.com> <1437125009.3689.27.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1437125009.3689.27.camel@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 07/17/2015 11:23 AM, Gerd Hoffmann wrote: >>> --- 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 ... Aah, right. The packet->actual_length is filled during the copy. Is this correct? What does libusb return for the single frames? I assume this will be the amount which was sent out to the device, not the size of the frame given to it. >> - 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. Understood. That's the polling case I mentioned above. Juergen