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

From: Sowjanya Komatineni
Date: Fri May 10 2019 - 14:54:57 EST


> 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