On Monday 22 September 2008, Eric Miao wrote:
> >> + ? ? data->rx_buf = kmalloc(MAX1111_RX_BUF_SIZE, GFP_KERNEL);
> >> + ? ? if (!data->rx_buf) {
> >> + ? ? ? ? ? ? kfree(data->tx_buf);
> >> + ? ? ? ? ? ? return -ENOMEM;
> >> + ? ? }
> >
> > Allocating such small buffers using kmalloc seems pretty inefficient.
> > At the very least, I would allocate both buffers at once. But quite
> > frankly I don't get why you don't just make these buffers part of
> > struct max1111_data. This would even make the structure smaller!
> >
>
> I originally place the buffer within "struct max1111_data" but received
> a mail from David Brownell suggesting using a kmalloc() buffer, so that
> DMA mode will work better with the cache alignment and trailing bytes,
> though PIO can just work happily. I don't know the specific reason for
> this, honestly.
The phrase is "cache line sharing". If you make sure the buffer doesn't
share its cache line with something the CPU may modify while the DMA is
happening, you're OK ... and using a dedicated kmalloc buffer guarantees
that. (So will sticking buffers at the end of a struct, like max1111_data,
annotated as "____cacheline_aligned", in many cases.)
On most ARMs, L1 and L2 caches are not DMA-coherent. So when both DMA
and CPU write to some memory, one can overwrite the other if you're
sloppy about buffer allocation.
