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.
