On 05/05/17 20:09, Andy Shevchenko wrote: > On Fri, 2017-05-05 at 19:55 +0100, Jonathan Cameron wrote: >> On 05/05/17 07:31, Jan Kiszka wrote: > >>> + >>> + /* >>> + * SPI message buffers: >>> + * tx_buf: |C0|C1|C2|C3|C4|C5|C6|C7|XX| >>> + * rx_buf: |XX|R0|R1|R2|R3|R4|R5|R6|R7|tt|tt|tt|tt| >>> + * >>> + * tx_buf: 8 channel read commands, plus 1 dummy command >>> + * rx_buf: 1 dummy response, 8 channel responses, plus 64- >>> bit timestamp >>> + */ >>> + __be16 rx_buf[13] >>> ____cacheline_aligned; >>> + __be16 tx_buf[9] >>> ____cacheline_aligned; >> >> I would have thought the SPI dma wouldn't take itself out so you >> should be >> good with just the one cacheline_aligned? Maybe I'm missing >> something. > > It was my idea for sake of consistency. Just to explicitly show that > buffers a cache aligned. > > If you insist to remove one, it's your call at the end ;-) > As far as I know the only reason the 'need' to be cacheline aligned is to avoid corruption issues if any other elements sharing the cacheline (ie.earlier elements in our structure) change whilst the dma is progress. Doesn't matter if the second is also so aligned as we should only have one dma type transfer going on at a time (plenty of locking in spi to ensure this). It's not a big point though so doesn't really matter as it is safe either way! Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
