Re: [BUG] SPI broken for SPI based panel drivers

From: Linus Walleij <linus.walleij@linaro.org>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Sven Van Asbroeck <thesven73@gmail.com>,
	Lukas Wunner <lukas@wunner.de>, Mark Brown <broonie@kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Discussions about the Letux Kernel 
	<letux-kernel@openphoenux.org>,
	Andreas Kemnade <andreas@kemnade.info>
Subject: Re: [BUG] SPI broken for SPI based panel drivers
Date: Wed, 9 Dec 2020 09:38:26 +0100	[thread overview]
Message-ID: <CACRpkdYbGBT1gYZ06W7G-tjx9J4YG1bi1g2GOAUAH0tzH8YbNw@mail.gmail.com> (raw)
In-Reply-To: <ED67B0A3-1098-4B4C-A4F4-EE52B0E5F1E3@goldelico.com>

On Sat, Dec 5, 2020 at 8:07 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:

> I find it interesting that so far nobody wants to take responsibility
> for a decision
(...)

What causes some consternation in this discussion is the appeal
to higher authority. The kernel community in general does not like
authority/responsibility by way of formal hierarchy.

Have you read this document? Especially point 1) Decisions:
https://www.kernel.org/doc/html/latest/process/management-style.html

(We can have a meta-discussion about this but it is not really your
point I believe.)

> > What I can do is to provide just a skeleton for the table that you or Linus
> > can fix/fill in and make a patch out of it. Is attached and the ??? is
> > something you should discuss and define.
>
> Please take the attached diff, comment it here and define the question marks
> according to your intention and then make a patch for the YAML bindings out
> of it. (I can't do because I don't know your intentions and what to write into
> the commit message).

I'll comment what I know, then you can send a proper patch to
Mark. But you really need more people than me to look at this.

> +      device node     | cs-gpio       | CS pin state active | Note
> +      ================+===============+=====================+=====
> +      spi-cs-high     | -             | H                   |
> +      -               | -             | L                   |
> +      spi-cs-high     | ACTIVE_HIGH   | H                   |
> +      -               | ACTIVE_HIGH   | L (or H ???)        | 1

When using GPIO descriptors it will be enforced to ACTIVE_LOW (L) with an
explicit warning in dmesg, see drivers/gpio/gpiolib-of.c

When using legacy GPIOs, will be enforced ACTIVE_LOW by the SPI
core.

> +      spi-cs-high     | ACTIVE_LOW    | H (or L ???)        | 2

When using GPIO descriptors it will be enforced to ACTIVE_HIGH (H) with an
explicit warning in dmesg, see drivers/gpio/gpiolib-of.c

> +      3) Effectively this rule defines that the ACTIVE level of the
> +         gpio has to be ignored

Nr 3 isn't tagged in the table.

Yours,
Linus Walleij