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