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

[Sowjanya Komatineni <skomatineni@xxxxxxxxxx>]

> 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