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

On Thu, Dec 11, 2014 at 11:36 AM, Rafał Miłecki [off-list ref] wrote:

On 9 December 2014 at 10:12, Maxime Ripard
[off-list ref] wrote:

quoted

On Mon, Dec 08, 2014 at 05:59:11PM +0100, Geert Uytterhoeven wrote:

quoted

quoted

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:

[deleted standard SPI protocol]

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.

I think you can just add two properties (one array for OE, one for SRCLR)
to the bindings for the gpio-74x164 driver, so it can set those GPIO pins,
if present. Note that they should be arrays, as gpio-74x164 supports\
daisy-chaining chips.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html