This patchset is trying to fix problems seen on S905X boards when interfacing
with an ILI9486 equipped SPI panel.
The color corruption and the performance issues are actually due to two
different problems in the SPICC driver and in the ILI9486 tiny DRM driver.
We try to fix both in the same patcheset to be able to correctly use the SPI
panel again.
To: Kamlesh Gurudasani <[email protected]>
To: David Airlie <[email protected]>
To: Daniel Vetter <[email protected]>
To: Mark Brown <[email protected]>
To: Neil Armstrong <[email protected]>
To: Kevin Hilman <[email protected]>
To: Jerome Brunet <[email protected]>
To: Martin Blumenstingl <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Carlo Caione <[email protected]>
---
Carlo Caione (3):
drm/tiny: rpi-lcd-35: Enable driver module autoloading
drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
spi: meson-spicc: Lower CS between bursts
drivers/gpu/drm/tiny/ili9486.c | 14 ++++++++++----
drivers/spi/spi-meson-spicc.c | 6 ++++++
2 files changed, 16 insertions(+), 4 deletions(-)
---
base-commit: 15f3bff12cf6a888ec2ad39652828c60e6836b3d
change-id: 20221116-s905x_spi_ili9486-aed54ff3cb21
Best regards,
--
Carlo Caione
On some hardware (reproduced on S905X) when a large payload is
transmitted over SPI in bursts at the end of each burst, the clock line
briefly fluctuates creating spurious clock transitions that are being
recognised by the connected device as a genuine pulses, creating an
offset in the data being transmitted.
Lower the GPIO CS between bursts to avoid the clock being interpreted as
valid.
Signed-off-by: Carlo Caione <[email protected]>
---
drivers/spi/spi-meson-spicc.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
index d47f2623a60f..af8d74b53519 100644
--- a/drivers/spi/spi-meson-spicc.c
+++ b/drivers/spi/spi-meson-spicc.c
@@ -291,6 +291,10 @@ static inline void meson_spicc_setup_burst(struct meson_spicc_device *spicc)
static irqreturn_t meson_spicc_irq(int irq, void *data)
{
struct meson_spicc_device *spicc = (void *) data;
+ struct spi_device *spi_dev;
+
+ spi_dev = spicc->message->spi;
+ gpiod_set_value(spi_dev->cs_gpiod, 0);
writel_bits_relaxed(SPICC_TC, SPICC_TC, spicc->base + SPICC_STATREG);
@@ -309,6 +313,8 @@ static irqreturn_t meson_spicc_irq(int irq, void *data)
/* Setup burst */
meson_spicc_setup_burst(spicc);
+ gpiod_set_value(spi_dev->cs_gpiod, 1);
+
/* Start burst */
writel_bits_relaxed(SPICC_XCH, SPICC_XCH, spicc->base + SPICC_CONREG);
--
b4 0.10.1
On Thu, Nov 17, 2022 at 09:47:41AM +0100, Carlo Caione wrote:
> On some hardware (reproduced on S905X) when a large payload is
> transmitted over SPI in bursts at the end of each burst, the clock line
> briefly fluctuates creating spurious clock transitions that are being
> recognised by the connected device as a genuine pulses, creating an
> offset in the data being transmitted.
> Lower the GPIO CS between bursts to avoid the clock being interpreted as
> valid.
This is just plain broken, *many* SPI devices attach meaning to
chip select edges - for example register writes will typically
have the register address followed by one or more register values
for sequential registers. Bouncing chip select in the middle of
transfer will corrupt data. If the device can't handle larger
transfers it needs to advertise this limit and refuse to handle
them.