On 2020/03/20 07:21, Nick Hudson wrote: > > > On 19/03/2020 09:19, [email protected] wrote: >> On 2020/03/19 07:10, Nick Hudson wrote: >>> On 19/03/2020 07:05, [email protected] wrote: >>>> On 2020/02/17 21:33, Nick Hudson wrote: >>> >>> [snip] >>> >>>>> xhci could do better and support multiple DMA segments, but uvm could >>>>> also help. >>>> >>>> To access each DMA segment in usb_dma_t *dma, should it be processed >>>> like this? >>>> >>>> for (i = 0; i < dma->udma_block->nsegs; i++) { >>>> bus_dma_segment_t *ds = &dma->udma_block->map->dm_segs[i]; >>>> >>>> process_segment(ds->ds_addr, ds->ds_len); >>>> } >>> >>> I started looking into this and have some changes to fix [ou]hci. >>> xhci and dwc2 seem to be a bit harder. >> >> dwc2 is a Greek to me. > > It's quite involved as the HC is pretty dumb, but I think it's well written. > > >> >>> http://src.illumos.org/source/xref/netbsd-src/sys/dev/usb/ehci.c#3011 >>> >>> Is how ehci currently does it. >> >> I've read that part of echi, but I cannot make me understood completely. >> Does ehci always split the transfer into 4kB chunks even >> it is physically contiguous? > > That function creates a list of transfer descriptors (TDs) for the xfer > buffer/length required. Each ehci TD can handle 5 ehci pages[*] worth > of buffer. For each page in the TD we can pass the DMA address and so > it doesn't matter if the physical memory is contigous or not. > > [ou]hci are very close to being correct, but need a couple of tweaks to > make sure i) that there are enough TDs and ii) misaligned buffers (wrt > page boundaries) get handled properly. > > Nick > > [*] It just so happens that ehci page is 4KB like most arches.
Thank you for your detailed explanation. How ehci works for multiple segment DMA differs from what I tries to do for xchi. The xhci.c has to learn it.
