On Fri, Dec 24, 2010 at 01:05:56AM -0500, Ben Gamari wrote: > 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?
(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. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
