Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: USB umass hard drive "failed to create xfers" when attaching





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.




Home | Main Index | Thread Index | Old Index