Re: [PATCH 1/2] ads7846: Make buffers in ads7846_read12_ser and ads7845_read12_ser DMA save

[Jonathan Cameron <jic23@cam.ac.uk>]

On 05/04/11 16:55, Alexander Stein wrote:
> Hello,
> 
> Am Mittwoch, 4. Mai 2011, 17:49:56 schrieb Jonathan Cameron:
>> On 05/04/11 16:22, Alexander Stein wrote:
>>> req.sample needs its own cacheline otherwise accessing req.msg fetches
>>> it in again.
>>> Put req onto stack as it doesn't need to be DMA save.
>>> req.sample is kzalloced itself for DMA access.
>>> req.command doesn't need own cache line because it will only be written
>>> to memory on dma_map_single. req.scratch is unsed at all.
>>>
>>> Note: This effect doesn't occur if the underlying SPI driver doesn't use
>>> DMA at all.
>>
>> How about using ____cacheline_aligned having moved 'sample' to the end of
>> the structure?
>>
>> e.g.
>>
>> ...
>> struct spi_transfer xfer[6];
>> __be16  sample ____cacheline_aligned;
>> }
>>
>> Rather smaller patch when you get down to it.
> 
> Mh, I didn't know I had to reorder the struct elements to use 
> ____cacheline_aligned. I originally had a solution in mind with a smaller 
> memory footprint in mind, but rethinking about it, this might be negligible if 
> there is one at all.
> So, if ____cacheline_aligned is the more sane approach I'll resend a patch 
> using it.
It simply enforces that element being aligned. Thus if there is anything after it
you may well have things in the same cacheline.  Obviously you could use
align the following element to ensure its on the next cache line, but thats
silly when you can just reorder to make sure nothing is there. All mallocs
are guaranteed to get a whole number of cachelines. (would be really fiddly
otherwise!)  Footprint wise, it should be pretty trivial.