linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



  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).