On Thu, Dec 11, 2014 at 11:36 AM, Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
> 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:
[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@xxxxxxxxxxxxxx
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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
