From: "Steven A. Falco" <sfalco@harris•com>
To: avorontsov@ru•mvista.com
Cc: "linuxppc-dev@ozlabs•org" <linuxppc-dev@ozlabs•org>
Subject: Re: [RFC] Dummy GPIO driver for use with SPI
Date: Fri, 12 Dec 2008 12:33:51 -0500 [thread overview]
Message-ID: <4942A07F.9060900@harris.com> (raw)
In-Reply-To: <20081212171438.GA9738@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Fri, Dec 12, 2008 at 11:59:13AM -0500, Steven A. Falco wrote:
>> 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?
>
> 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;
> }
> }
>
next prev parent reply other threads:[~2008-12-12 17:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 14:22 [RFC] Dummy GPIO driver for use with SPI Steven A. Falco
2008-12-12 15:01 ` Anton Vorontsov
2008-12-12 16:59 ` Steven A. Falco
2008-12-12 17:14 ` Anton Vorontsov
2008-12-12 17:33 ` Steven A. Falco [this message]
2008-12-12 21:39 ` Trent Piepho
2008-12-12 22:46 ` David Gibson
2008-12-16 16:34 ` Anton Vorontsov
2008-12-15 0:12 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4942A07F.9060900@harris.com \
--to=sfalco@harris$(echo .)com \
--cc=avorontsov@ru$(echo .)mvista.com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox