Re: [PATCH] spi: Avoid setting the chip select if we don't need to
From: Mark Brown
Date: Wed Jul 01 2020 - 05:33:22 EST
On Wed, Jul 01, 2020 at 06:26:24AM +0000, Ardelean, Alexandru wrote:
> On Mon, 2020-06-29 at 16:41 -0700, Douglas Anderson wrote:
> > + spi->controller->last_cs_enable = enable;
> > + spi->controller->last_cs_mode_high = spi->mode & SPI_CS_HIGH;
> I don't feel like this is the best approach for the SPI CS handling,
> because it's pretty difficult to guess the last CS state, and whether this
> return would cause other weirder issues [like not toggling CS when it
> should].
There's no guesswork involved here - the only thing that should be
setting the chip select is the SPI core so other than at startup we
always know the state of the chip select.
> Maybe a question is: when should this CS be toggled [or not]?
> Is it between 2 calls of spi_transfer_one_message() or between 2
> spi_transfers?
> Or, is "xfer->cs_change == 1" where it shouldn't be?
This is well documented, it's asserted while a message is being
transferred unless changed by cs_change in which case we do whatever the
opposite of the default action is.
Attachment:
signature.asc
Description: PGP signature