Anton Vorontsov wrote:
> On Fri, Dec 12, 2008 at 09:22:02AM -0500, Steven A. Falco wrote:
>> 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?
Steve
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
