All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Carlo Caione <ccaione@baylibre.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Kevin Hilman <khilman@baylibre.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-spi@vger.kernel.org, linux-amlogic@lists.infradead.org,
	Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	Jerome Brunet <jbrunet@baylibre.com>
Subject: Re: [PATCH 3/3] spi: meson-spicc: Lower CS between bursts
Date: Thu, 17 Nov 2022 10:59:50 +0000	[thread overview]
Message-ID: <Y3YUJjSTI9U9qz59@sirena.org.uk> (raw)
In-Reply-To: <20221116-s905x_spi_ili9486-v1-3-630401cb62d5@baylibre.com>

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Carlo Caione <ccaione@baylibre.com>
Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jerome Brunet <jbrunet@baylibre.com>,
	David Airlie <airlied@gmail.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] spi: meson-spicc: Lower CS between bursts
Date: Thu, 17 Nov 2022 10:59:50 +0000	[thread overview]
Message-ID: <Y3YUJjSTI9U9qz59@sirena.org.uk> (raw)
In-Reply-To: <20221116-s905x_spi_ili9486-v1-3-630401cb62d5@baylibre.com>

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Carlo Caione <ccaione@baylibre.com>
Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jerome Brunet <jbrunet@baylibre.com>,
	David Airlie <airlied@gmail.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] spi: meson-spicc: Lower CS between bursts
Date: Thu, 17 Nov 2022 10:59:50 +0000	[thread overview]
Message-ID: <Y3YUJjSTI9U9qz59@sirena.org.uk> (raw)
In-Reply-To: <20221116-s905x_spi_ili9486-v1-3-630401cb62d5@baylibre.com>


[-- Attachment #1.1: Type: text/plain, Size: 860 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Carlo Caione <ccaione@baylibre.com>
Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jerome Brunet <jbrunet@baylibre.com>,
	David Airlie <airlied@gmail.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] spi: meson-spicc: Lower CS between bursts
Date: Thu, 17 Nov 2022 10:59:50 +0000	[thread overview]
Message-ID: <Y3YUJjSTI9U9qz59@sirena.org.uk> (raw)
In-Reply-To: <20221116-s905x_spi_ili9486-v1-3-630401cb62d5@baylibre.com>


[-- Attachment #1.1: Type: text/plain, Size: 860 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-11-17 10:59 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-17  8:47 [PATCH 0/3] Fix SPICC and ILI9486 drivers Carlo Caione
2022-11-17  8:47 ` Carlo Caione
2022-11-17  8:47 ` Carlo Caione
2022-11-17  8:47 ` Carlo Caione
2022-11-17  8:47 ` [PATCH 1/3] drm/tiny: rpi-lcd-35: Enable driver module autoloading Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17  8:47 ` [PATCH 2/3] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17 11:09   ` Mark Brown
2022-11-17 11:09     ` Mark Brown
2022-11-17 11:09     ` Mark Brown
2022-11-17 11:09     ` Mark Brown
2022-11-17 13:40     ` Carlo Caione
2022-11-17 13:40       ` Carlo Caione
2022-11-17 13:40       ` Carlo Caione
2022-11-17 13:40       ` Carlo Caione
2022-11-17 14:59       ` Mark Brown
2022-11-17 14:59         ` Mark Brown
2022-11-17 14:59         ` Mark Brown
2022-11-17 14:59         ` Mark Brown
2022-11-18 10:36         ` Carlo Caione
2022-11-18 10:36           ` Carlo Caione
2022-11-18 10:36           ` Carlo Caione
2022-11-18 10:36           ` Carlo Caione
2022-11-18 15:44           ` Mark Brown
2022-11-18 15:44             ` Mark Brown
2022-11-18 15:44             ` Mark Brown
2022-11-18 15:44             ` Mark Brown
2022-11-18 19:02             ` Carlo Caione
2022-11-18 19:02               ` Carlo Caione
2022-11-18 19:02               ` Carlo Caione
2022-11-18 19:02               ` Carlo Caione
2022-11-17  8:47 ` [PATCH 3/3] spi: meson-spicc: Lower CS between bursts Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17  8:47   ` Carlo Caione
2022-11-17  8:54   ` Neil Armstrong
2022-11-17  8:54     ` Neil Armstrong
2022-11-17  8:54     ` Neil Armstrong
2022-11-17  8:54     ` Neil Armstrong
2022-11-17 14:05     ` Carlo Caione
2022-11-17 14:05       ` Carlo Caione
2022-11-17 14:05       ` Carlo Caione
2022-11-17 14:05       ` Carlo Caione
2022-11-17 10:59   ` Mark Brown [this message]
2022-11-17 10:59     ` Mark Brown
2022-11-17 10:59     ` Mark Brown
2022-11-17 10:59     ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3YUJjSTI9U9qz59@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=ccaione@baylibre.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jbrunet@baylibre.com \
    --cc=kamlesh.gurudasani@gmail.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=neil.armstrong@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.