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

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

On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote:
> On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari <bgamari.foss@gmail.com> wrote:
> > > The reason I left this up to the board is it's easy to foresee cases
> > > where you want a non-trivial mapping between logical CS numbers and CS
> > > pin states. In my case, I using a 2-to-4 multiplexer as the source of
> > > chip select.
> > 
> > Hi Ben,
> > 
> > I understand and appreciate the motivation.  However in practice, the
> > gpio api is sufficient for pretty much any use case, even when the
> > backing gpio controller driver ends up driving some oddball device
> > with different constraints.  The big downside to using a callback is
> > that it forces all users to do the extra work of implementing the
> > callback.  With the gpio api, only the oddball cases have to do extra
> > code (to adapt the custom device to the gpio api).
> 
> 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.

g.