On Sat, 12 Feb 2011 01:33:24 -0700, Grant Likely <grant.lik...@secretlab.ca> wrote: > (Sorry for the really laggy reply) > No worries, I was just starting to think about this again myself.
> 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. > Having now finally having had a chance to implement a gpio_chip driver, I agree. It's quite simple and seems to fill the need pretty well > 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. > I think you are probably right. GPIO seems to be a good fit. Patch coming shortly. I use spi_board_info.controller_data to pass the gpio number to the controller which doesn't seem like the best way forward, but I wasn't sure how else to proceed. Also, since the gpio numbers are dynamically determined spi_board_info.controller_data must be filled in at runtime, which is also a bit of a bummer (although not easily solved as far as I can tell). Let me know what you think. - Ben -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
