On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote: > On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely <[email protected]> > wrote: > > On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari <[email protected]> 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. ------------------------------------------------------------------------------ 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
