With dma based spi transmission, data corruption
is observed occasionally. With dma buffers located
right next to msg and xfer fields, cache lines
correctly flushed in preparation for dma usage
may be polluted again when writing to fields
in the same cache line.
Make sure cache fields used with dma do not
share cache lines with fields changed during
dma handling. As both fields are part of a
struct that is allocated via kzalloc, thus
cache aligned, moving the fields to the 1st
position and insert padding for alignment
does the job.
Signed-off-by: Oskar Schirmer <os@xxxxxxxxx>
Signed-off-by: Daniel Glöckner <dg@xxxxxxxxx>
Signed-off-by: Oliver Schneidewind <osw@xxxxxxxxx>
Signed-off-by: Johannes Weiner <jw@xxxxxxxxx>
---
drivers/input/touchscreen/ad7877.c | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)
v2: add a comment to explain why alignment is needed
diff --git a/drivers/input/touchscreen/ad7877.c b/drivers/input/touchscreen/ad7877.c
index 9cfc8b5..69ebacf 100644
--- a/drivers/input/touchscreen/ad7877.c
+++ b/drivers/input/touchscreen/ad7877.c
@@ -153,15 +153,29 @@ enum {
*/
struct ser_req {
+ u16 sample;
+ /*
+ * DMA (thus cache coherency maintainance) requires the
+ * transfer buffers to live in their own cache lines.
+ */
+ char __padalign[L1_CACHE_BYTES - sizeof(u16)];
+
u16 reset;
u16 ref_on;
u16 command;
- u16 sample;
struct spi_message msg;
struct spi_transfer xfer[6];
};
struct ad7877 {
+ u16 conversion_data[AD7877_NR_SENSE];
+ /*
+ * DMA (thus cache coherency maintainance) requires the
+ * transfer buffers to live in their own cache lines.
+ */
+ char __padalign[L1_CACHE_BYTES
+ - AD7877_NR_SENSE * sizeof(u16)];
+
struct input_dev *input;
char phys[32];
@@ -182,8 +196,6 @@ struct ad7877 {
u8 averaging;
u8 pen_down_acc_interval;
- u16 conversion_data[AD7877_NR_SENSE];
-
struct spi_transfer xfer[AD7877_NR_SENSE + 2];
struct spi_message msg;
--
1.5.3.7
--
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
