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@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
