Re: [PATCH] gpio: sn54hc595: new driver for GPIO shift registers chipsets

[Rafał Miłecki <zajec5@xxxxxxxxx>]

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 linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html