Re: [PATCH] mcspi: Add support for GPIO chip select lines

[Grant Likely <grant.likely@secretlab.ca>]

On Fri, Dec 24, 2010 at 01:05:56AM -0500, Ben Gamari wrote:
> On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote:
> > > I understand your concerns, but I'm not sure how to satisfy them without
> > > crippling the design's ability to accomodate my use-case. I can't pass a
> > > GPIO line per spi_board_info since in my case of a multiplexed CS
> > > configuration a single pin's state does not uniquely determine the
> > > desired CS. The only other option I can think of is that we somehow
> > > provide a list of GPIOs for each bus and map the CS numbers to
> > > permutations of GPIO states. Unfortunately, I don't know of any suitable
> > > structure to put this GPIO list in. Perhaps I'm missing something obvious?
> > 
> > Close, but not quite.  Assign one gpio number to each cs state, and
> > write a gpio controller driver that maps the linux-gpio number to the
> > physical gpio state permutation.  The mapping from gpio# to ss# is
> > 1:1, but the driver behind the gpio# can do whatever you need it to
> > do.
> > 
> I see. I'm still not convinced that this is the route to take,
> however. It seems like this virtual gpio interface is not only pretty
> clunky (simple board file glue turns into an entire gpio chip driver),
> it seems like this is a very inaccurate and not very useful way to
> expose a multiplexed CS configuration; e.g. what is this chip driver to
> do if the user tries to set two CS pins at once?

(Sorry for the really laggy reply)

I don't see it being that big a deal.  gpio drivers are pretty
lightweight and it is fine to have domain-specific limitations on how
gpios for a particular "gpio controller" behave.  In your example, if
the hardware doesn't support enabling 2 CS pins at once, then you make
a choice, either setting one when the other is already set simply does
not work; or it could reset the other state.  Either choice would be
fine.  The SPI driver must do the right thing regardless and deselect
the previous CS line before enabling a new one.

The other alternative would be to implement a new SPI chipselect
common infrastructure, but IMO, that would just end up looking like a
duplication of the gpio infrastructure.

Regardless, my point still stands, platform callbacks for what amounts
to gpio manipulations doesn't make a whole lot of sense.

> Is there precedent for
> using the GPIO subsystem in this way?

Yes, in drivers/spi look at mpc52xx_spi.c, davinci_spi.c, ath79_spi.c,
atmel_spi.c, and many more.  Grep for gpio in drivers/spi.

g.