On 19/03/2020 09:19, sc.dying%gmail.com@localhost wrote:
On 2020/03/19 07:10, Nick Hudson wrote:On 19/03/2020 07:05, sc.dying%gmail.com@localhost 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.