On 9 December 2014 at 10:12, Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: > On Mon, Dec 08, 2014 at 05:59:11PM +0100, Geert Uytterhoeven wrote: >> > I think that implementing support for this extra SPI layer will >> > actually require more code/tricks than a separated driver. >> >> Yes, it will require more code, as spi-gpio is more generic than your simple >> implementation. But the end result is more flexible and reusable. >> >> The only thing missing is the programmable OE and reset pins, >> which are assumed hardwired by the gpio-74x164 driver. >> These could be implemented using new gpio-oe and gpio-reset >> properties. > > From my (very) vague memories of it, OE was actually supported by > using it as spi-gpio's chip select. > > So I'd say that only the gpio-reset should be implemented. I've tracked how spi_bitbang_transfer_one does work. Long story short it does: bitbang->chipselect(spi, BITBANG_CS_ACTIVE); bitbang->txrx_bufs(spi, t); bitbang->chipselect(spi, BITBANG_CS_INACTIVE); txrx_bufs is a pointer to one of: bitbang_txrx_be_cpha0 bitbang_txrx_be_cpha1 Now, in cpha[01] for every register bit we call: 1) setmosi - to set data, so it's serial (SER) 2) setsck - to shift bits, so it's shift register clock (SRCLK) Then in spi_gpio_chipselect we call: 1) cs_gpios[chip], so it's register clock (RCLK) As you can see, we don't call OE in spi_gpio_chipselect. So currently both input signals and unhandled: OE and SRCLR. Luckily for me, it appears my bootloader puts them in a wanted state, but this still should be handled somehow. -- Rafał -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
