[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150904153718.GO5313@sirena.org.uk>
Date: Fri, 4 Sep 2015 16:37:18 +0100
From: Mark Brown <broonie@...nel.org>
To: Martin Sperl <martin@...rl.org>
Cc: Ranjit Waghmode <ranjit.waghmode@...inx.com>, dwmw2@...radead.org,
computersforpeace@...il.com, michal.simek@...inx.com,
soren.brinkmann@...inx.com, zajec5@...il.com, ben@...adent.org.uk,
marex@...x.de, b32955@...escale.com, knut.wohlrab@...bosch.com,
juhosg@...nwrt.org, beanhuo@...ron.com,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-spi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
harinik@...inx.com, punnaia@...inx.com
Subject: Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data
stripe
On Fri, Sep 04, 2015 at 02:35:52PM +0200, Martin Sperl wrote:
> > On 03.09.2015, at 14:12, Mark Brown <broonie@...nel.org> wrote:
> > This isn't saying that the controller supports more than one chip, it's
> > saying that the controller supports asserting more than one chip select
> > at once which isn't the same thing. I'm also not entirely sure that
> > this makes sense as a separate feature to the data striping one - I'm
> > struggling to think of a way to use this sensibly separately to that.
> Well - there is one use-case that I can think of:
> fbtft has the requirement for some devices to control a GPIO to
> differentiate between command and data getting transferred
> - sort of 9 bit.
That's another thing again, isn't it? It's one device switching between
two different control interfaces at runtime rather than two devices
controlled in lockstep.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists