Re: PCI DMA to small buffers on cache-incoherent arch

[Brad Hards <bhards@bigpond.net.au>]

On Tue, 11 Jun 2002 14:04, Roland Dreier wrote:
> >>>>> "David" == David S Miller <davem@redhat.com> writes:
>
>     David> Wait a second, forget all of this cache alignment crap.  If
>     David> we can avoid drivers seeing it, we should by all means
>     David> necessary.
>
>     David> We should just tell people to use PCI pools and be done
>     David> with it.  That way all the complexity about buffer
>     David> alignment and all this other crapola lives strictly inside
>     David> of the PCI pool code.
>
> That's fine but there are drivers (USB, etc) doing
>
> 	struct something {
> 	        int field1;
> 	        char dma_buffer[SMALLER_THAN_CACHE_LINE];
> 	        int field2;
> 	};
>
> 	struct something *dev = kmalloc(sizeof *dev, GFP_KERNEL);
>
> Do they have to change to
>
> 	struct something {
> 	        int field1;
> 	        char *dma_buffer;
> 	        int field2;
> 	};
>
> 	struct something *dev = kmalloc(sizeof *dev, GFP_KERNEL);
>         dev->dma_buffer = kmalloc(SMALLER_THAN_CACHE_LINE, GFP_KERNEL);
>
> (This is always safe because as you said kmalloc can never return a
> slab that's not safe for DMA)  I don't see how PCI pools help here.
In the USB case, the "something" represents a device, and the "dma_buffer" is 
something you want to send-to / receive-from the device.

kmallocing the transfer buffers is a problem for suspend. Doing the "you get 
the transfer buffer with the device" is really useful, because you know that 
the device configuration will be returned. But we might need to re-init the 
device after a suspend, and [I've been told that] memory allocation may 
deadlock under these circumstances.

Would it be enought to move the transfer buffers to the start of the device 
struct, and then pad it up to a cacheline?

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.