Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

docs: driver-api: usb: update dma info

We should not hide the recommend APIs in a obscure place.

Signed-off-by: Randy Li <ayaka@soulik.info>
Link: https://lore.kernel.org/r/20230914172336.18761-3-ayaka@soulik.info
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

authored by

Randy Li and committed by
Greg Kroah-Hartman
44ceac8c 1cf56299

+11 -37
+11 -37
Documentation/driver-api/usb/dma.rst
··· 93 93 driver can safely be used with such DMA mapping. (See the first section 94 94 of Documentation/core-api/dma-api-howto.rst, titled "What memory is DMA-able?") 95 95 96 - - When you're using scatterlists, you can map everything at once. On some 97 - systems, this kicks in an IOMMU and turns the scatterlists into single 98 - DMA transactions:: 96 + - When you have the scatterlists which have been mapped for the USB controller, 97 + you could use the new ``usb_sg_*()`` calls, which would turn scatterlist 98 + into URBs:: 99 99 100 - int usb_buffer_map_sg (struct usb_device *dev, unsigned pipe, 101 - struct scatterlist *sg, int nents); 100 + int usb_sg_init(struct usb_sg_request *io, struct usb_device *dev, 101 + unsigned pipe, unsigned period, struct scatterlist *sg, 102 + int nents, size_t length, gfp_t mem_flags); 102 103 103 - void usb_buffer_dmasync_sg (struct usb_device *dev, unsigned pipe, 104 - struct scatterlist *sg, int n_hw_ents); 104 + void usb_sg_wait(struct usb_sg_request *io); 105 105 106 - void usb_buffer_unmap_sg (struct usb_device *dev, unsigned pipe, 107 - struct scatterlist *sg, int n_hw_ents); 106 + void usb_sg_cancel(struct usb_sg_request *io); 108 107 109 - It's probably easier to use the new ``usb_sg_*()`` calls, which do the DMA 110 - mapping and apply other tweaks to make scatterlist i/o be fast. 111 - 112 - - Some drivers may prefer to work with the model that they're mapping large 113 - buffers, synchronizing their safe re-use. (If there's no re-use, then let 114 - usbcore do the map/unmap.) Large periodic transfers make good examples 115 - here, since it's cheaper to just synchronize the buffer than to unmap it 116 - each time an urb completes and then re-map it on during resubmission. 117 - 118 - These calls all work with initialized urbs: ``urb->dev``, ``urb->pipe``, 119 - ``urb->transfer_buffer``, and ``urb->transfer_buffer_length`` must all be 120 - valid when these calls are used (``urb->setup_packet`` must be valid too 121 - if urb is a control request):: 122 - 123 - struct urb *usb_buffer_map (struct urb *urb); 124 - 125 - void usb_buffer_dmasync (struct urb *urb); 126 - 127 - void usb_buffer_unmap (struct urb *urb); 128 - 129 - The calls manage ``urb->transfer_dma`` for you, and set 130 - ``URB_NO_TRANSFER_DMA_MAP`` so that usbcore won't map or unmap the buffer. 131 - They cannot be used for setup_packet buffers in control requests. 132 - 133 - Note that several of those interfaces are currently commented out, since 134 - they don't have current users. See the source code. Other than the dmasync 135 - calls (where the underlying DMA primitives have changed), most of them can 136 - easily be commented back in if you want to use them. 108 + When the USB controller doesn't support DMA, the ``usb_sg_init()`` would try 109 + to submit URBs in PIO way as long as the page in scatterlists is not in the 110 + Highmem, which could be very rare in modern architectures.