mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Felipe Balbi <felipe.balbi@linux.intel.com>,
	oneukum@suse.com, Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC v2] usb: xhci: add Immediate Data Transfer support
Date: Wed, 06 Feb 2019 11:08:02 +0100	[thread overview]
Message-ID: <294f2492f8d3b7022bf659dcb473c45a34e85db8.camel@suse.de> (raw)
In-Reply-To: <87lg2tmnk3.fsf@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]

Hi Felipe, thanks for the review!

On Wed, 2019-02-06 at 08:35 +0200, Felipe Balbi wrote:
> Hi,
> 
> Nicolas Saenz Julienne <nsaenzjulienne@suse.de> writes:
> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > index 40fa25c4d041..a4efbe62a1a3 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -3272,8 +3272,15 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
> > mem_flags,
> >  			field |= TRB_IOC;
> >  			more_trbs_coming = false;
> >  			td->last_trb = ring->enqueue;
> > +
> > +			if (xhci_urb_suitable_for_idt(urb)) {
> > +				memcpy(&send_addr, urb->transfer_buffer,
> > +				       trb_buff_len);
> > +				field |= TRB_IDT;
> > +			}
> >  		}
> >  
> > +
> 
> trailing change

Noted

> 
> > @@ -3411,6 +3418,12 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t
> > mem_flags,
> >  	if (urb->transfer_buffer_length > 0) {
> >  		u32 length_field, remainder;
> >  
> > +		if (xhci_urb_suitable_for_idt(urb)) {
> > +			memcpy(&urb->transfer_dma, urb->transfer_buffer,
> > +			       urb->transfer_buffer_length);
> > +			field |= TRB_IDT;
> > +		}
> > +
> >  		remainder = xhci_td_remainder(xhci, 0,
> >  				urb->transfer_buffer_length,
> >  				urb->transfer_buffer_length,
> > @@ -3420,6 +3433,7 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t
> > mem_flags,
> >  				TRB_INTR_TARGET(0);
> >  		if (setup->bRequestType & USB_DIR_IN)
> >  			field |= TRB_DIR_IN;
> > +
> 
> trailing change

Noted

> 
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index 005e65922608..dec62f7f5dc8 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -1238,6 +1238,21 @@ EXPORT_SYMBOL_GPL(xhci_resume);
> >  
> >  /*-------------------------------------------------------------------------
> > */
> >  
> > +/*
> > + * Bypass the DMA mapping if URB is suitable for Immediate Transfer (IDT),
> > + * we'll copy the actual data into the TRB address register. This is
> > limited to
> > + * transfers up to 8 bytes on output endpoints of any kind with
> > wMaxPacketSize
> > + * >= 8 bytes.
> > + */
> > +static int xhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
> > +				gfp_t mem_flags)
> > +{
> > +	if (xhci_urb_suitable_for_idt(urb))
> > +		return 0;
> > +
> > +	return usb_hcd_map_urb_for_dma(hcd, urb, mem_flags);
> > +}
> 
> don't you need a matching unmap_urb_for_dma()??

Not really as every DMA mapping sets a matching URB flag to track it. For
example when usb_hcd_map_urb_for_dma() uses dma_map_single() it will set
URB_DMA_MAP_SINGLE in urb->transfer_flags, later on unmap_urb_for_dma() will
catch it and unmap it. As I bypass the mapping altogether there are no
flags set, so unmap_urb_for_dma() won't have any effect.

I could still add it for clarity, and well, I guess it'll save some
instructions on the IDT suitable side.

> 
> > diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> > index 652dc36e3012..9d77b0901ab7 100644
> > --- a/drivers/usb/host/xhci.h
> > +++ b/drivers/usb/host/xhci.h
> > @@ -1295,6 +1295,8 @@ enum xhci_setup_dev {
> >  #define TRB_IOC			(1<<5)
> >  /* The buffer pointer contains immediate data */
> >  #define TRB_IDT			(1<<6)
> > +/* TDs smaller than this might use IDT */
> 
> Technically, "TDs at most this" since you're 8 itself is an allowed
> size.
> 

Noted

Regards,
Nicolas



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-02-06 10:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-05 19:56 Nicolas Saenz Julienne
2019-02-06  6:35 ` Felipe Balbi
2019-02-06 10:08   ` Nicolas Saenz Julienne [this message]
2019-02-06 10:54     ` Felipe Balbi

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=294f2492f8d3b7022bf659dcb473c45a34e85db8.camel@suse.de \
    --to=nsaenzjulienne@suse.de \
    --cc=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=oneukum@suse.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

all inboxes | Powered by JetHome®