On Tue, 26 Jun 2007, Greg KH wrote: > On Tue, Jun 26, 2007 at 10:32:42AM -0400, Alan Stern wrote: > > On Mon, 25 Jun 2007, Greg KH wrote: > > > > > You mean something like the following, but also for bulk and int? I > > > like it, it reduces the number of allocations and frees we have to do as > > > the transfer buffer will get freed automatically with the urb, when it > > > is. > > > > > > What do people think? > > > > > + urb = kzalloc(sizeof(*urb) + size, mem_flags); > > > + if (!urb) > > > + return NULL; > > > + buffer = ((unsigned char *)(urb) + size); > > > > This is no good. The buffer has to be located in its own cache line; > > it can't be combined with another data structure like the URB. They > > must be allocated separately. > > Why? I thought the only requirement be that they are from DMA-able > memory.
Another important requirement of streaming DMA-IN transfers is that the CPU must not touch the buffer's cache line while it is mapped for DMA. If it does, you risk reading stale values into the CPU's cache. Then when the device puts the correct values in the buffer, the CPU ignores them (and maybe even overwrites them!) because it thinks it already knows the buffer's contents. Now if you knew for certain that the buffer would only be used for OUT transfers then you might be okay. But I'm not certain, and in any case it's best to obey the access rules for DMA. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
