Bcc: Subject: GPIO chip select support in omap2_mcspi driver Hey, Recently I have been looking to use a BeagleBoard to drive several serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the BeagleBoard is severely limited by the number of SPI controllers it exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4 with one). This is insufficient for our application and thus I have been investigating adding support to the mcspi driver for using GPIO lines as chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers. To this end, I have a few questions about how this support was implemented. First, it seems that the s3c24xx driver is built on the spi_bitbang driver, despite interfacing with a dedicated hardware SPI controller. What is the reason for this? Was this done specifically for the purpose of incorporating support for GPIO CS pins? It seems like the rough idea is to add a cs_gpio field to the device struct (omap2_mcspi) and add the appropriate code to the omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The potential problem I can see with this is that omap2_mcspi_set_enable() is called to enable the channel before the force_cs() is called (in omap2_mcspi_work()). If I'm interpreting the documentation correctly, the enable bit starts the clocks, meaning that the chip will begin clocking out data before CS is brought high. I must be missing something here, no? For reference, I included a short list of relevant commits below, largely for my own benefit. I would greatly appreciate any feedback you might have. Thanks, - Ben pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686 bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0 -- 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
