All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: "Steven A. Falco" <sfalco@harris.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 20:14:38 +0300	[thread overview]
Message-ID: <20081212171438.GA9738@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <49429861.9060305@harris.com>

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?

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

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

  reply	other threads:[~2008-12-12 17:14 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 [this message]
2008-12-12 17:33       ` Steven A. Falco
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=20081212171438.GA9738@oksana.dev.rtsoft.ru \
    --to=avorontsov@ru.mvista.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=sfalco@harris.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.