On Thu, Mar 4, 2021 at 10:10 AM Serge Semin [off-list ref] wrote:

On Thu, Mar 04, 2021 at 09:29:33AM +0100, Linus Walleij wrote:

quoted

quoted

+ * pin:             3            2        |       1            0
+ * bit:         7------6------5------4----|---3------2------1------0
+ *             cs1  cs1_ovr  cs0  cs0_ovr |  cs1  cs1_ovr  cs0  cs0_ovr
+ *                        ssi1            |             ssi0
+ */
+#define SPICS_PIN_SHIFT(pin)   (2 * (pin))
+#define SPICS_MASK(pin)                (0x3 << SPICS_PIN_SHIFT(pin))
+#define SPICS_SET(pin, val)    ((((val) << 1) | 0x1) << SPICS_PIN_SHIFT(pin))

quoted

So 2 bits per GPIO line in one register? (Nice doc!)

I suppose the first bit is the CS-pin-override flag. So when it's set
the output is directly driven by the second bit, otherwise the
corresponding DW APB SPI controller drives it. That's how the
multiplexing is implemented here.

If these output lines are so tightly coupled to the SPI block
and will not be used for any other GPO (general purpose output)
I think it makes more sense to bundle the handling into the
DW SPI driver, and activate it based on the Elba compatible
string (if of_is_compatible(...)).

I am a bit cautious because it has happened in the past that
people repurpose CS lines who were originally for SPI CS
to all kind of other purposes, such as a power-on LED and
in that case it needs to be a separate GPIO driver. So the
author needs to have a good idea about what is a realistic
use case here.

Yours,
Linus Walleij