On Wed, May 04, 2011 at 05:55:23PM +0200, 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. > Yes, please, as ____cacheline_aligned introduces the least amount of the churn (and I like it better than separately doing kmalloc anyway) and I should be able to get it in .39. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
