All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	oneukum@suse.com, Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC] usb: xhci: add Immediate Data Transfers support
Date: Fri, 01 Feb 2019 15:31:29 +0200	[thread overview]
Message-ID: <877eejocsu.fsf@linux.intel.com> (raw)

Hi,

Nicolas Saenz Julienne <nsaenzjulienne@suse.de> writes:
> Immediate data transfers (IDT) allow the HCD to copy small chunks of
> data (up to 8bits) directly into its output transfer TRBs. This avoids
              ^^^^^
              8 bytes

> the somewhat expensive DMA mappings that are performed by default on
> most URBs submissions.
>
> In the case an URB was suitable for IDT. The data is directly copied
> into the "Data Buffer Pointer" region of the TRB and the IDT flag is
> set. Instead of triggering memory accesses the HC will use the data
> directly.
>
> An additional URB flag was created to mark whenever the URB doesn't need
> any DMA mapping. Ideally it would have been nice to use a private flag
> as this is specific to XHCI. Yet it's not possible as the URB private
> area is allocated only after the DMA mapping is done.
>
> Isochronous transfers are not implemented so far as it's hard to find a
> device that will send such small packets.
>
> This was tested using USB/serial adapter and by controlling the leds on
> an XBOX controller. There where no disruptions on the rest of USB
> devices attached on the system.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>  drivers/usb/host/xhci-ring.c |  6 ++++++
>  drivers/usb/host/xhci.c      | 37 ++++++++++++++++++++++++++++++++++++
>  drivers/usb/host/xhci.h      |  2 ++
>  include/linux/usb.h          |  2 ++
>  4 files changed, 47 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 40fa25c4d041..dd9805fb0566 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3272,6 +3272,12 @@ 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 (urb->transfer_flags & URB_NO_DMA_MAP) {

do you really need the flag? Why don't you do this unconditionally as
long as urb->transfer_length is <= 8?

> +				memcpy(&send_addr, urb->transfer_buffer,
> +				       full_len);
> +				field |= TRB_IDT;
> +			}
>  		}
>  
>  		/* Only set interrupt on short packet for IN endpoints */
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 005e65922608..ce3b6663f940 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1238,6 +1238,41 @@ EXPORT_SYMBOL_GPL(xhci_resume);
>  
>  /*-------------------------------------------------------------------------*/
>  
> +static void xhci_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
> +{
> +	if (urb->transfer_flags & URB_NO_DMA_MAP)
> +		urb->transfer_flags &= ~URB_NO_DMA_MAP;
> +	else
> +		usb_hcd_unmap_urb_for_dma(hcd, urb);
> +}
> +
> +static int xhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
> +				gfp_t mem_flags)
> +{
> +	int maxp = usb_endpoint_maxp(&urb->ep->desc);
> +	int len = urb->transfer_buffer_length;
> +	int ret = 0;
> +
> +	/*
> +	 * Checks if URB is suitable for Immediate Transfer (IDT): instead of
> +	 * mapping the buffer for DMA and passing the address to the host
> +	 * controller, we copy the actual data into the TRB address register.
> +	 * This is limited to transfers up to 8 bytes.
> +	 *
> +	 * IDT is only supported for Bulk and Interrupt endpoints. Apart from
> +	 * the size constraints special care is taken to avoid cases where
> +	 * wMaxPacketSize is smaller than 8 bytes as it's not supported.
> +	 */
> +	if ((usb_endpoint_is_int_out(&urb->ep->desc) ||
> +	    usb_endpoint_is_bulk_out(&urb->ep->desc)) &&

I don't understand the check for endpoint type. IDT is, actually,
already used for control endpoints because setup packets are composed of
8 bytes. You're also showing that this works for INT and BULK types. It
would be a surprise if it doesn't work for ISOC.

> +	    maxp >= TRB_IDT_MAX_SIZE && len <= TRB_IDT_MAX_SIZE)

why the maxp check? What if I'm an interrupt endpoint with maxp of 2?
Is there really a limitation that you couldn't use IDT for those?

> +		urb->transfer_flags |= URB_NO_DMA_MAP;

do we really need this? I wonder if returning zero here would be enough,
then you could:

...map_urb_for_dma(...)
{
	ret = 0;

	if (urb->transfer_length > 8)
        	ret = usb_hcd_map_urb_for_dma(hcd, urb, flags);

	return ret;
}

...unmap_urb_for_dma(...)
{
	if urb->transfer_length > 8)
        	usb_hcd_unmap_urb_for_dma(hcd, urb);
}

...xhci_queue_bulk_tx(...)
{
	[...]

	if (urb->transfer_length <= 8) {
		memcpy(&addr, urb->transfer_buffer, 8)l
		field |= TRB_IDT;
        }

	[...]
}

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	oneukum@suse.com, Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] usb: xhci: add Immediate Data Transfers support
Date: Fri, 01 Feb 2019 15:31:29 +0200	[thread overview]
Message-ID: <877eejocsu.fsf@linux.intel.com> (raw)
In-Reply-To: <20190201130602.9171-1-nsaenzjulienne@suse.de>

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


Hi,

Nicolas Saenz Julienne <nsaenzjulienne@suse.de> writes:
> Immediate data transfers (IDT) allow the HCD to copy small chunks of
> data (up to 8bits) directly into its output transfer TRBs. This avoids
              ^^^^^
              8 bytes

> the somewhat expensive DMA mappings that are performed by default on
> most URBs submissions.
>
> In the case an URB was suitable for IDT. The data is directly copied
> into the "Data Buffer Pointer" region of the TRB and the IDT flag is
> set. Instead of triggering memory accesses the HC will use the data
> directly.
>
> An additional URB flag was created to mark whenever the URB doesn't need
> any DMA mapping. Ideally it would have been nice to use a private flag
> as this is specific to XHCI. Yet it's not possible as the URB private
> area is allocated only after the DMA mapping is done.
>
> Isochronous transfers are not implemented so far as it's hard to find a
> device that will send such small packets.
>
> This was tested using USB/serial adapter and by controlling the leds on
> an XBOX controller. There where no disruptions on the rest of USB
> devices attached on the system.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>  drivers/usb/host/xhci-ring.c |  6 ++++++
>  drivers/usb/host/xhci.c      | 37 ++++++++++++++++++++++++++++++++++++
>  drivers/usb/host/xhci.h      |  2 ++
>  include/linux/usb.h          |  2 ++
>  4 files changed, 47 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 40fa25c4d041..dd9805fb0566 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3272,6 +3272,12 @@ 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 (urb->transfer_flags & URB_NO_DMA_MAP) {

do you really need the flag? Why don't you do this unconditionally as
long as urb->transfer_length is <= 8?

> +				memcpy(&send_addr, urb->transfer_buffer,
> +				       full_len);
> +				field |= TRB_IDT;
> +			}
>  		}
>  
>  		/* Only set interrupt on short packet for IN endpoints */
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 005e65922608..ce3b6663f940 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1238,6 +1238,41 @@ EXPORT_SYMBOL_GPL(xhci_resume);
>  
>  /*-------------------------------------------------------------------------*/
>  
> +static void xhci_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
> +{
> +	if (urb->transfer_flags & URB_NO_DMA_MAP)
> +		urb->transfer_flags &= ~URB_NO_DMA_MAP;
> +	else
> +		usb_hcd_unmap_urb_for_dma(hcd, urb);
> +}
> +
> +static int xhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
> +				gfp_t mem_flags)
> +{
> +	int maxp = usb_endpoint_maxp(&urb->ep->desc);
> +	int len = urb->transfer_buffer_length;
> +	int ret = 0;
> +
> +	/*
> +	 * Checks if URB is suitable for Immediate Transfer (IDT): instead of
> +	 * mapping the buffer for DMA and passing the address to the host
> +	 * controller, we copy the actual data into the TRB address register.
> +	 * This is limited to transfers up to 8 bytes.
> +	 *
> +	 * IDT is only supported for Bulk and Interrupt endpoints. Apart from
> +	 * the size constraints special care is taken to avoid cases where
> +	 * wMaxPacketSize is smaller than 8 bytes as it's not supported.
> +	 */
> +	if ((usb_endpoint_is_int_out(&urb->ep->desc) ||
> +	    usb_endpoint_is_bulk_out(&urb->ep->desc)) &&

I don't understand the check for endpoint type. IDT is, actually,
already used for control endpoints because setup packets are composed of
8 bytes. You're also showing that this works for INT and BULK types. It
would be a surprise if it doesn't work for ISOC.

> +	    maxp >= TRB_IDT_MAX_SIZE && len <= TRB_IDT_MAX_SIZE)

why the maxp check? What if I'm an interrupt endpoint with maxp of 2?
Is there really a limitation that you couldn't use IDT for those?

> +		urb->transfer_flags |= URB_NO_DMA_MAP;

do we really need this? I wonder if returning zero here would be enough,
then you could:

...map_urb_for_dma(...)
{
	ret = 0;

	if (urb->transfer_length > 8)
        	ret = usb_hcd_map_urb_for_dma(hcd, urb, flags);

	return ret;
}

...unmap_urb_for_dma(...)
{
	if urb->transfer_length > 8)
        	usb_hcd_unmap_urb_for_dma(hcd, urb);
}

...xhci_queue_bulk_tx(...)
{
	[...]

	if (urb->transfer_length <= 8) {
		memcpy(&addr, urb->transfer_buffer, 8)l
		field |= TRB_IDT;
        }

	[...]
}

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

             reply	other threads:[~2019-02-01 13:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-01 13:31 Felipe Balbi [this message]
2019-02-01 13:31 ` [RFC] usb: xhci: add Immediate Data Transfers support Felipe Balbi
  -- strict thread matches above, loose matches on Subject: below --
2019-02-01 14:22 Nicolas Saenz Julienne
2019-02-01 14:22 ` Nicolas Saenz Julienne
2019-02-01 13:06 Nicolas Saenz Julienne
2019-02-01 13:06 ` Nicolas Saenz Julienne

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=877eejocsu.fsf@linux.intel.com \
    --to=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=nsaenzjulienne@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.