Thread (13 messages) 13 messages, 4 authors, 2014-12-11

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

From: Maxime Ripard <hidden>
Date: 2014-12-09 09:09:41
Also in: linux-gpio

On Mon, Dec 08, 2014 at 05:56:56PM +0100, Arnd Bergmann wrote:
On Monday 08 December 2014 17:31:45 Rafał Miłecki wrote:
quoted
On 8 December 2014 at 16:41, Arnd Bergmann [off-list ref] wrote:
quoted
On Monday 08 December 2014 16:23:01 Rafał Miłecki wrote:
quoted
On 8 December 2014 at 16:03, Geert Uytterhoeven [off-list ref] wrote:
quoted
quoted
gpio-74x164.c seems to be tight closely to the SPI. In my case it's
GPIO-controller '595.
Right. gpio-74x164.c uses the SPI framework, so it will work with any SPI
master controller, while your driver contains a very simple variant (without any
timing constraints) of spi-gpio.c, and is limited to connecting to GPIO pins.
quoted
Do you have any other idea how we could handle this?
Your driver does provide OE support, which gpio-74x164 doesn't support.
Perhaps that can be added to gpio-74x164 instead?
It's not the missing OE support in gpio-74x164 that worries me, but
the whole rest.

I would need to modify gpio-74x164 to:
1) Use another OF table with different entry
2) Use different probe function that doesn't take spi_device parameter
and doesn't do spi setup
3) Extend struct gen_74x164_chip to include GPIOs
4) Use totally different __gen_74x164_write_config
I think the suggestion was to use the spi-gpio driver in combination
with gpio-74x164.
Oh, OK, I've obviously missed that.

I don't know... I'm somehow not really convinced to that, because
AFAIK there isn't any SPI master device between GPIOs and 'HC595. I
don't know if pretending there is some extra hardware (just to use
another Linux driver/layer) is a good idea. This would:
1) Not match hardware design
2) Involve some extra code.

I'm not even sure if this would work out-of-the box (without some
extra changes) at all. From early look at spi-gpio.c I can't see it
implementing everything I need for GPIO-connected 'HC595.
I think that implementing support for this extra SPI layer will
actually require more code/tricks than a separated driver.
The purpose of the spi-gpio driver is to avoid having to write
two drivers for every spi slave device if someone wants to drive
it using bit-banged gpios.

The existing users of the driver are in fact all using spi-gpio,
see:
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
arch/arm/boot/dts/imx28-cfa10049.dts
I'm the one who worked on the cfa10049, and yeah, it worked pretty
well at the time using spi-gpio.

We couldn't really do it any other way though, since we had another
SPI device tied to the same bus, so it really felt like this was the
right thing to do.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help