RE: [PATCH V3 5/9] spi: export spi core function spi_set_cs

From: Sowjanya Komatineni <skomatineni@nvidia.com>
To: Mark Brown <broonie@kernel.org>
Cc: "thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Timo Alho <talho@nvidia.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	Krishna Yarlagadda <kyarlagadda@nvidia.com>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: RE: [PATCH V3 5/9] spi: export spi core function spi_set_cs
Date: Fri, 10 May 2019 18:53:25 +0000	[thread overview]
Message-ID: <BYAPR12MB3398D946FDD0E5406B23EB50C20C0@BYAPR12MB3398.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20190506044425.GN14916@sirena.org.uk>

> On Mon, Apr 29, 2019 at 10:02:46PM +0000, Sowjanya Komatineni wrote:
> 
> Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns.  Doing this makes your messages much easier to read and reply to.
> 
> > > On Mon, Apr 15, 2019 at 02:30:30PM -0700, Sowjanya Komatineni wrote:
> > > > This patch exports spi_set_cs of the spi core to allow SPI masters 
> > > > to use when gpio based chip select is needed.
>
> > > This isn't really what I meant when I said it'd be good to use the 
> > > core GPIO code - this function doesn't do a huge amount really and 
> > > the usage of it in your subsequent patch for the > driver isn't 
> > > exactly joined up with the little it does (which is mainly swapping 
> > > in the GPIO chip select instead of the hardware chip select) isn't 
> > > used in your driver usage of this as far as I can see.  The bulk of 
> > > the chip select handling code in the core is actually in
> > > transfer_one_message() which your driver doesn't use as it's got 
> > > it's own implementation of that; I've not looked in enough detail to 
> > > figure out if it could use it.
>
> > In SPI Tegra driver, we wanted to have GPIO based CS control when 
> > cs-gpios is specified in parallel to HW/SW CS. Having parallel GPIO 
> > based CS is to mimic some of the timing stuff that's needed for some 
> > spi devices by not actually using HW CS on platform but only for SPI 
> > HW design logic inside the chip.
>
> > Tegra spi driver don't use set_cs callback so looking into spi_set_cs 
> > from spi core implementation when cs-gpios property is used it exactly 
> > the same that is needed for GPIO control CS. So used this in V3.
>
> > Can you please provide more details on what you are suggesting?
> > Do you prefer not to use SPI core spi_set_cs and gpio_set_values APIs 
> > and instead implement in tegra SPI driver using GPIO descriptors ?
>
> You're probably best open coding in the driver if there's value in using the hardware chip select.

Sorry, Just to be clear on my understanding of your suggestion,

3 ways of CS control implementation is needed for Tegra SPI
- SW CS thru SPI Controller
- HW CS thru SPI Controller
- Direct GPIO based CS control 

Patch Series includes both HW CS and also direct GPIO based CS.

Regarding direct GPIO based CS, I understood you prefer to use GPIO descriptors.
I see SPI core set_cs API also uses GPIO descriptor for direct GPIO control of CS. 

Tegra SPI driver need parallel implementation of direct gpio based cs to hw/sw based
CS control thru SPI controller.
Since SPI core set_cs already has implementation using gpio descriptors, in V3 I am using
the same API.

Any concerns for using set_cs API from SPI core as it already does direct gpio based cs using
Descriptors?

Thanks
Sowjanya