Thread (9 messages) read the whole thread 9 messages, 4 authors, 2008-12-16

Re: [RFC] Dummy GPIO driver for use with SPI

From: Steven A. Falco <hidden>
Date: 2008-12-12 17:33:56

Anton Vorontsov wrote:
On Fri, Dec 12, 2008 at 11:59:13AM -0500, Steven A. Falco wrote:
quoted
Anton Vorontsov wrote:
quoted
On Fri, Dec 12, 2008 at 09:22:02AM -0500, Steven A. Falco wrote:
quoted
This patch adds a dummy GPIO driver, which is useful for SPI devices
that do not have a physical chip select.
Hm. Then you don't need a chip-select, and SPI driver must understand
this case. When SPI controller has no "gpios" property, it should just
ignore any chip-select toggling operations.

As an implementation example you can use this patch:

http://patchwork.ozlabs.org/patch/12499/

grep for "SPI w/o chip-select line."
My actual situation is a bit more complicated - serves me right for
trying to simplify it in my RFC.

We have three devices on the SPI bus.  Two have well-behaved chip
selects - they are ST flash memory devices.  The third device, the
Atmel chip does not have a chip select.  It does have a RESET pin,
which is similar to a chip select, but the Atmel protocol requires
that that pin be low during the entire programming operation, and
I cannot chain all the tx/rx operations together into one atomic 
SPI transaction, so I cannot use that pin as the SPI chip select.

Instead, I manage the RESET pin outside of the SPI driver, and hence
there is no chip select for that one device, so I use my dummy CS
driver to provide a fake chip select to satisfy the SPI driver.

This does have the limitation that I must be careful not to access
the flash parts at the same time as I access the Atmel, but that is
ok for my application.  I guess I could use something like your
patch, but I'd maybe have to extend the flags to include a "do not
use" bit, which would bypass the gpio_is_valid and gpio_request
calls.

What do you think about having a mechanism to specify that some
SPI slaves have a chip select, while others don't have to have a
chip select managed by the SPI subsystem?
Um.. do you know that you can pass '0' as a GPIO?
I did not know that. :-)  Ok, so I'll look at modifying spi_ppc4xx.c
based on your suggestions.

	Thanks!
	Steve
For example,

spi-controller {
	gpios = <&pio1 1 0	/* cs0 */
		 0		/* cs1, no GPIO */
		 &pio2 2 0>;	/* cs2 */

	device@0 {
		reg = <0>; /* spi device, cs 0: "&pio1 1 0" */
	}

	device@1 {
		reg = <1>; /* spi device, cs 1: no actual GPIO */
	}

	device@2 {
		reg = <2>; /* spi device, cs 2: "&pio2 2 0" */
	}
};

With this patch
http://patchwork.ozlabs.org/patch/12450/

of_get_gpio() will differentiate "end of gpios" and "no gpio" cases.
So, in the SPI driver you can do something like this:

count = of_gpio_count(np);
for (i = 0; i < count; i++) {
	int gpio;

	gpio = of_get_gpio(np, i);
	if (gpio_is_valid(gpio)) {
		normal case;
	} else if (gpio == -EEXIST) {
		the special case;
	} else {
		error;
	}
}
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help