Hi Linus, On Thu, Mar 4, 2021 at 5:38 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Thu, Mar 4, 2021 at 10:10 AM Serge Semin <fancer.lancer@xxxxxxxxx> wrote: > > On Thu, Mar 04, 2021 at 09:29:33AM +0100, Linus Walleij wrote: > > > > > + * 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)) > > > > > > > > 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
