On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari <bgamari.foss@xxxxxxxxx> wrote: > On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: >> On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari <bgamari.foss@xxxxxxxxx> wrote: >> > This mechanism is in large part stolen from the s3c64xx-spi module. To >> > use this functionality, one simply must define a set_level function to >> > set the CS state and a omap2_mcspi_csinfo struct for each chip select in >> > the board file. >> > >> > Each spi_board_info.controller_data should then be set >> > to point to the appropriate csinfo struct. This will cause the driver to >> > call the csinfo->set_level function instead of toggling the McSPI chip >> > select lines. >> > >> > Signed-off-by: Ben Gamari <bgamari.foss@xxxxxxxxx> >> >> I'd rather see the spi driver modified to use the gpio api directly. >> The drivers are already tending in that direction and it doesn't >> require machine specific set_level functions to be defined. >> > 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). 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
