From: Martin Sperl <martin@sperl.org>
To: Mark Brown <broonie@kernel.org>
Cc: Ranjit Waghmode <ranjit.waghmode@xilinx.com>,
dwmw2@infradead.org, computersforpeace@gmail.com,
michal.simek@xilinx.com, soren.brinkmann@xilinx.com,
zajec5@gmail.com, ben@decadent.org.uk, marex@denx.de,
b32955@freescale.com, knut.wohlrab@de.bosch.com,
juhosg@openwrt.org, beanhuo@micron.com,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
harinik@xilinx.com, punnaia@xilinx.com
Subject: Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe
Date: Fri, 4 Sep 2015 14:35:52 +0200 [thread overview]
Message-ID: <E4C1DE94-773C-498F-9CD5-639FBEEE3139@sperl.org> (raw)
In-Reply-To: <20150903121232.GW12027@sirena.org.uk>
> On 03.09.2015, at 14:12, Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Aug 26, 2015 at 11:56:04AM +0530, Ranjit Waghmode wrote:
>
>> To support dual parallel mode operation of ZynqMP GQSPI controller
>> following API's are added inside the core:
>
> As covered in SubmittingPatches please try to make each patch a single
> change rather than having multiple separate changes in one commit.
>
>> + /* Controller may support more than one chip.
>> + * This flag will enable that feature.
>> + */
>> +#define SPI_MASTER_BOTH_CS BIT(8) /* enable both chips */
>
> 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.
Right now it is done outside of spi in the fbtft driver itself wrapping
spi_sync().
Similarly a “hold” line on an eeprom or similar could get (de)asserted
without requiring holding a spi-bus-lock.
But then the current patch would not allow this kind of “generic”
use-case.
Martin
next prev parent reply other threads:[~2015-09-04 12:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 6:26 [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller Ranjit Waghmode
2015-08-26 6:26 ` [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe Ranjit Waghmode
2015-09-03 12:12 ` Mark Brown
2015-09-04 12:02 ` Ranjit Abhimanyu Waghmode
2015-09-11 12:36 ` Mark Brown
2015-09-11 16:24 ` Harini Katakam
2015-09-04 12:35 ` Martin Sperl [this message]
2015-09-04 15:37 ` Mark Brown
2015-09-04 15:48 ` Martin Sperl
2015-08-26 6:26 ` [LINUX RFC v2 2/4] mtd: add spi_device instance to spi_nor struct Ranjit Waghmode
2015-08-26 6:26 ` [LINUX RFC v2 3/4] spi-nor: add dual parallel mode support Ranjit Waghmode
2015-08-26 6:26 ` [LINUX RFC v2 4/4] spi: zynqmp: gqspi: add support for dual parallel mode configuration Ranjit Waghmode
2015-08-26 6:56 ` [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller Marek Vasut
2015-09-02 17:12 ` Ranjit Abhimanyu Waghmode
2015-09-02 18:56 ` Marek Vasut
2015-09-03 13:25 ` Ranjit Abhimanyu Waghmode
2015-09-03 13:38 ` Marek Vasut
2015-08-26 12:19 ` Jagan Teki
2015-08-26 15:32 ` punnaiah choudary kalluri
2015-08-27 6:23 ` Jagan Teki
2015-08-27 8:48 ` punnaiah choudary kalluri
2015-08-27 10:15 ` Jagan Teki
2015-08-27 11:49 ` punnaiah choudary kalluri
2015-08-28 4:13 ` Jagan Teki
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=E4C1DE94-773C-498F-9CD5-639FBEEE3139@sperl.org \
--to=martin@sperl.org \
--cc=b32955@freescale.com \
--cc=beanhuo@micron.com \
--cc=ben@decadent.org.uk \
--cc=broonie@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=harinik@xilinx.com \
--cc=juhosg@openwrt.org \
--cc=knut.wohlrab@de.bosch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=marex@denx.de \
--cc=michal.simek@xilinx.com \
--cc=punnaia@xilinx.com \
--cc=ranjit.waghmode@xilinx.com \
--cc=soren.brinkmann@xilinx.com \
--cc=zajec5@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).