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.
Attachment:
signature.asc
Description: PGP signature
