On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely <[email protected]> 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? Is there precedent for using the GPIO subsystem in this way?
Cheers, - Ben ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
