All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Carlo Caione <carlo@caione.org>
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 2/3] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
Date: Fri, 18 Nov 2022 15:44:33 +0000	[thread overview]
Message-ID: <Y3eoYTZRyRJnze1z@sirena.org.uk> (raw)
In-Reply-To: <e36142ec-6b7f-e667-7d6b-48234318c8cd@baylibre.com>

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

On Fri, Nov 18, 2022 at 11:36:27AM +0100, Carlo Caione wrote:
> On 17/11/2022 15:59, Mark Brown wrote:

> > So this is an issue in the MIPI DBI code where the interpretation of the
> > buffer passed in depends on both the a caller parameter and the
> > capabilities of the underlying SPI controller, meaning that a driver can
> > suddenly become buggy when used with a new controller?

> The MIPI DBI code is fine, in fact it is doing the correct thing in the
> mipi_dbi_typec3_command() function. The problem is that the ILI9486
> driver is hijacking that function installing its own hook that is wrong.

Ah, I see - it's causing confusion because it peers into the
internals of the underlying code.

> The problem arrives when your controller does support 16-bits, so your
> data is not swapped, but you still put the data on the bus with 8-bit
> transfers.

Why would you need to use 8 bit transfers if the controller
supports 16 bits?

[-- 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 <carlo@caione.org>
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 2/3] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
Date: Fri, 18 Nov 2022 15:44:33 +0000	[thread overview]
Message-ID: <Y3eoYTZRyRJnze1z@sirena.org.uk> (raw)
In-Reply-To: <e36142ec-6b7f-e667-7d6b-48234318c8cd@baylibre.com>

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

On Fri, Nov 18, 2022 at 11:36:27AM +0100, Carlo Caione wrote:
> On 17/11/2022 15:59, Mark Brown wrote:

> > So this is an issue in the MIPI DBI code where the interpretation of the
> > buffer passed in depends on both the a caller parameter and the
> > capabilities of the underlying SPI controller, meaning that a driver can
> > suddenly become buggy when used with a new controller?

> The MIPI DBI code is fine, in fact it is doing the correct thing in the
> mipi_dbi_typec3_command() function. The problem is that the ILI9486
> driver is hijacking that function installing its own hook that is wrong.

Ah, I see - it's causing confusion because it peers into the
internals of the underlying code.

> The problem arrives when your controller does support 16-bits, so your
> data is not swapped, but you still put the data on the bus with 8-bit
> transfers.

Why would you need to use 8 bit transfers if the controller
supports 16 bits?

[-- 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 <carlo@caione.org>
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 2/3] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
Date: Fri, 18 Nov 2022 15:44:33 +0000	[thread overview]
Message-ID: <Y3eoYTZRyRJnze1z@sirena.org.uk> (raw)
In-Reply-To: <e36142ec-6b7f-e667-7d6b-48234318c8cd@baylibre.com>


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

On Fri, Nov 18, 2022 at 11:36:27AM +0100, Carlo Caione wrote:
> On 17/11/2022 15:59, Mark Brown wrote:

> > So this is an issue in the MIPI DBI code where the interpretation of the
> > buffer passed in depends on both the a caller parameter and the
> > capabilities of the underlying SPI controller, meaning that a driver can
> > suddenly become buggy when used with a new controller?

> The MIPI DBI code is fine, in fact it is doing the correct thing in the
> mipi_dbi_typec3_command() function. The problem is that the ILI9486
> driver is hijacking that function installing its own hook that is wrong.

Ah, I see - it's causing confusion because it peers into the
internals of the underlying code.

> The problem arrives when your controller does support 16-bits, so your
> data is not swapped, but you still put the data on the bus with 8-bit
> transfers.

Why would you need to use 8 bit transfers if the controller
supports 16 bits?

[-- 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 <carlo@caione.org>
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 2/3] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
Date: Fri, 18 Nov 2022 15:44:33 +0000	[thread overview]
Message-ID: <Y3eoYTZRyRJnze1z@sirena.org.uk> (raw)
In-Reply-To: <e36142ec-6b7f-e667-7d6b-48234318c8cd@baylibre.com>


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

On Fri, Nov 18, 2022 at 11:36:27AM +0100, Carlo Caione wrote:
> On 17/11/2022 15:59, Mark Brown wrote:

> > So this is an issue in the MIPI DBI code where the interpretation of the
> > buffer passed in depends on both the a caller parameter and the
> > capabilities of the underlying SPI controller, meaning that a driver can
> > suddenly become buggy when used with a new controller?

> The MIPI DBI code is fine, in fact it is doing the correct thing in the
> mipi_dbi_typec3_command() function. The problem is that the ILI9486
> driver is hijacking that function installing its own hook that is wrong.

Ah, I see - it's causing confusion because it peers into the
internals of the underlying code.

> The problem arrives when your controller does support 16-bits, so your
> data is not swapped, but you still put the data on the bus with 8-bit
> transfers.

Why would you need to use 8 bit transfers if the controller
supports 16 bits?

[-- 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

  reply	other threads:[~2022-11-18 15:44 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 [this message]
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
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=Y3eoYTZRyRJnze1z@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=airlied@gmail.com \
    --cc=carlo@caione.org \
    --cc=daniel@ffwll.ch \
    --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.