On Sat, May 30, 2009 at 11:16:30PM +0200, Martin Fuzzey wrote: > Hi, > I've found out why test13 is failing for me on i.MX21. I don't think > it's related to my HCD but I'm not sure if it's an ARM or USB problem : > > When the problem occurs I noticed that both the setup phase buffer and > the data phase buffer are in the same 32 byte block. > As dma_get_cache_alignment() returns 32 on this platform I believe they > share a cache line. > > So this means that when performing the GET_STATUS request the usb core > is calling: > dma_map_single(DMA_TO_DEVICE) for the 8 byte setup buffer > dma_map_single(DMA_FROM_DEVICE) for the 2 byte data buffer > > and that when the problem occurs both buffers are in the same cache line.. > This causes the data seen in main memory for the data buffer to be > incorrect. Basically... don't do this, you're asking for problems. Documentation/DMA-API.txt says: | Warnings: Memory coherency operates at a granularity called the cache | line width. In order for memory mapped by this API to operate | correctly, the mapped region must begin exactly on a cache line | boundary and end exactly on one (to prevent two separately mapped | regions from sharing a single cache line). Since the cache line size | may not be known at compile time, the API will not enforce this | requirement. Therefore, it is recommended that driver writers who | don't take special care to determine the cache line size at run time | only map virtual regions that begin and end on page boundaries (which | are guaranteed also to be cache line boundaries). Basically, the DMA API operates at cache line granularity and only expects a _single_ buffer to be mapped per unit of granularity at any one time. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
