Re: DMA Cache problem for control transfers

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

 



On Sat, May 30, 2009 at 11:53:59PM +0200, Martin Fuzzey wrote:
> Russell King - ARM Linux wrote:
> > 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.
> >   
> Thank you, that's very clear.
> 
> Unfortunately I'm not the one doing this - anything that goes through
> usb_control_msg() could cause this since that function takes a pointer
> for the data buffer and internally kmalloc's the setup buffer.

Well, USB is plainly buggy then.
--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux