Hi Linus,

On Thu, Mar 4, 2021 at 5:38 AM Linus Walleij [off-list ref] wrote:

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

quoted

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

quoted

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.

The gpio pins being used for the Elba SoC SPI CS are dedicated to this
function.  Are you recommending that the code in
drivers/gpio/gpio-elba-spics.c be integrated into
drivers/spi/spi-dw-mmio.c?

Regards,
Brad

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