Re: [PATCH v1] spi: fix client driver can't register success when use GPIO as CS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Andy,

On Mon, May 10, 2021 at 7:36 AM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
> >
> >       device node     | cs-gpio       | CS pin state active | Note
> >       ================+===============+=====================+=====
> >       spi-cs-high     | -             | H                   |
> >       -               | -             | L                   |
> >       spi-cs-high     | ACTIVE_HIGH   | H                   |
> >       -               | ACTIVE_HIGH   | L                   | 1
> >       spi-cs-high     | ACTIVE_LOW    | H                   | 2
> >       -               | ACTIVE_LOW    | L                   |
> >
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/spi/spi-controller.yaml?h=v5.12#n54
>
> This table is incompatible with ACPI. So we can't unify them until each of them
> will play by the same rules. Can't say it won't happen, but it's far from that.

Linus Wallej has added some gpiod OF quirks that checks if the gpio is
used as a chip-select, and if so forces the gpiod polarity to
implement the inversion:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpiolib-of.c?h=v5.13-rc1#n175

If as suggested above, we disable that OF quirk and use the polarity
flag from the SPI mode flags instead, and ignore the built-in gpiod
polarity, the OF table boils down to:

device node    |  CS pin active state
=====================================
-              |  L
spi-cs-high    |  H

which is exactly the same as the ACPI case:
SPI mode flag  |  CS pin active state
=====================================
-              | L
SPI_CS_HIGH    | H

Your github commit says:
> in ACPI case the default polarity
> is active high and can't be altered

So if ACPI gpiods are always active-high then unification can happen
here, correct?

But if I have misunderstood the ACPI case, and ACPI gpiod chip-selects
can have any polarity, then I agree that unification cannot happen.
Like I said earlier, I live mostly in OF-land, so my apologies if I
have not fully grasped the ACPI case.

Sven



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux