CPU Cache and busdma usage in USB
Piotr Zięcik
kosmo at semihalf.com
Tue Jul 14 08:31:13 UTC 2009
>
> 1) My analysis: Only the data areas are being flushed/invalidated. No
> transfer descriptors are flushed/invalidated. I see no cache operations
> happening on any DMA control structures, even though there are calls from
> EHCI to xxx_pc_flush() and xxx_pc_invalidate().
>
This is 100% correct if control structures are marked as BUS_DMA_COHERENT.
> One patch you can try is to add an additional unload call to
> "usbd_transfer_setup_sub_malloc()":
>
> ==== //depot/projects/usb/src/sys/dev/usb/usb_transfer.c#159 -
> /home/hans_other/usb.p4/src/sys/dev/usb/usb_transfer.c ====
> @@ -268,6 +268,10 @@
> pg, z, align)) {
> return (1); /* failure */
> }
> +
> + bus_dmamap_unload(parm->dma_page_cache_ptr->tag,
> + parm->dma_page_cache_ptr->map);
> +
> /* Set beginning of current buffer */
> buf = parm->dma_page_cache_ptr->buffer;
> /* Make room for one DMA page cache and one page */
>
> This will avoid the same memory area being loaded twice. Not sure if there
> is still a bug in pmap about this!
I checked this patch and I did not saw any changes in USB behaviour.
The problem sill was visible.
>
> Could you provide a new trace, showing an enumeration failure. In your
> previous trace there was no error, because the printouts probably caused to
> CPU to flush out its cache.
>
I have tried many times and I was unable to generate trace showing enumeration
faliure. Even little amount of debugging code caused proper enumeration.
However access to attached device (pendrive) was not possible - SCSI layer
reported errors.
Probaby you see more on your AT91 device as you know USB stack internals. Have
you tried to bring up OHCI on you ARM board ?
--
Best Regards,
Piotr Ziecik
More information about the freebsd-usb
mailing list