[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK9rFnzDZ4MNm68AJ75g7zegLD-7UMHyoVR-4ssitYTTEeQm5g@mail.gmail.com>
Date: Sun, 22 Aug 2021 18:05:52 -0700
From: Brad Larson <brad@...sando.io>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Serge Semin <fancer.lancer@...il.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Arnd Bergmann <arnd@...db.de>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Mark Brown <broonie@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Olof Johansson <olof@...om.net>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
linux-spi <linux-spi@...r.kernel.org>,
linux-mmc <linux-mmc@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/8] gpio: Add Elba SoC gpio driver for spi cs control
Hi Linus,
On Thu, Mar 4, 2021 at 5:38 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Thu, Mar 4, 2021 at 10:10 AM Serge Semin <fancer.lancer@...il.com> 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
Powered by blists - more mailing lists