Dummy GPIO driver for use with SPI

This patch adds a dummy GPIO driver, which is useful for SPI devices that do not have a physical chip select.

Quoted 2 lines · Steven A. Falco

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."

Quoted 8 lines · Anton Vorontsov

Quoted 2 lines · Steven A. Falco

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.

Quoted 6 lines

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?

Quoted 36 lines · Steven A. Falco

Quoted 7 lines · Anton Vorontsov

Quoted 2 lines · Steven A. Falco

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.

Quoted 6 lines

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.

Quoted 3 lines

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?

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;
	}
}

Quoted 3 lines · Steven A. Falco

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?

For example,

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

		normal case;
	} else if (gpio == -EEXIST) {

Quoted 9 lines · Anton Vorontsov

Quoted 3 lines · Steven A. Falco

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?

For example,

Quoted 4 lines

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

It's ok the that middle specifier is only one word instead of three? Seems like "0 0 0" would be better, so all the specifiers are the same size.

Quoted 5 lines · Anton Vorontsov

Quoted 3 lines · Steven A. Falco

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?

Quoted 8 lines

Um.. do you know that you can pass '0' as a GPIO?

For example,

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

It's ok the that middle specifier is only one word instead of three? Seems like "0 0 0" would be better, so all the specifiers are the same size.

Quoted 2 lines

		normal case;
	} else if (gpio == -EEXIST) {

Isn't EEXIST (pathname already exists) backward?

Seems like ENOENT would
be the right error code. Except that's used for reading past the end... Maybe a reading past the end should be EINVAL or EBADF?

Or return ENODEV for the 'hole' cell? Or ENOLINK?

This patch adds a dummy GPIO driver, which is useful for SPI devices that do not have a physical chip select.

Signed-off-by Steven A. Falco <[email protected]>

---
The SPI subsystem requires a chip-select for each connected slave device. I have a custom board with an Atmel "co-processor". This part is reprogrammed via SPI, so it needs a chip select to satisfy the SPI subsystem, but my hardware does not have a physical CS connected.

I could waste a "no-connect" GPIO pin, but I'd rather not. So, I've written a dummy GPIO driver, which behaves exactly like a real GPIO device, but with no underlying hardware. This could also be useful as a template for real GPIO drivers.

I use the following dts entry:

	GPIO3: dummy@ef500000 {
		compatible = "linux,dummy-gpio";
		reg = <ef500000 1>;
		gpio-controller;
		#gpio-cells = <2>;
	};