| Message ID | fabbc87627e5ddc2c913b368ae99386668d8dcfb.1660830866.git.christophe.leroy@csgroup.eu |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v3] spi: Add capability to perform some transfer with chipselect off | expand |
On Thu, Aug 18, 2022 at 03:57:49PM +0200, Christophe Leroy wrote: > Some components require a few clock cycles with chipselect off before > or/and after the data transfer done with CS on. > > Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK > should have one cycle before CS goes low, and two cycles after > CS goes high". This doesn't apply against current code, please check and resend.
Le 07/09/2022 à 13:44, Mark Brown a écrit : > On Thu, Aug 18, 2022 at 03:57:49PM +0200, Christophe Leroy wrote: >> Some components require a few clock cycles with chipselect off before >> or/and after the data transfer done with CS on. >> >> Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK >> should have one cycle before CS goes low, and two cycles after >> CS goes high". > > This doesn't apply against current code, please check and resend. Looks like my patch was from before the percpu statistics. I just sent a rebased patch. Christophe
On Thu, 18 Aug 2022 15:57:49 +0200, Christophe Leroy wrote: > Some components require a few clock cycles with chipselect off before > or/and after the data transfer done with CS on. > > Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK > should have one cycle before CS goes low, and two cycles after > CS goes high". > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/1] spi: Add capability to perform some transfer with chipselect off commit: 5e0531f6b90ac096fedaf5bd0eae0bb4e5a39da5 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 2a472dcf081e..ca71723d44a7 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1418,7 +1418,8 @@ static int spi_transfer_one_message(struct spi_controller *ctlr, struct spi_statistics *statm = &ctlr->statistics; struct spi_statistics *stats = &msg->spi->statistics; - spi_set_cs(msg->spi, true, false); + xfer = list_first_entry(&msg->transfers, struct spi_transfer, transfer_list); + spi_set_cs(msg->spi, !xfer->cs_off, false); SPI_STATISTICS_INCREMENT_FIELD(statm, messages); SPI_STATISTICS_INCREMENT_FIELD(stats, messages); @@ -1486,10 +1487,15 @@ static int spi_transfer_one_message(struct spi_controller *ctlr, &msg->transfers)) { keep_cs = true; } else { - spi_set_cs(msg->spi, false, false); + if (!xfer->cs_off) + spi_set_cs(msg->spi, false, false); _spi_transfer_cs_change_delay(msg, xfer); - spi_set_cs(msg->spi, true, false); + if (!list_next_entry(xfer, transfer_list)->cs_off) + spi_set_cs(msg->spi, true, false); } + } else if (!list_is_last(&xfer->transfer_list, &msg->transfers) && + xfer->cs_off != list_next_entry(xfer, transfer_list)->cs_off) { + spi_set_cs(msg->spi, xfer->cs_off, false); } msg->actual_length += xfer->len; diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 7ab3fed7b804..cbb787f6b9ff 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -818,6 +818,7 @@ struct spi_res { * for this transfer. If 0 the default (from @spi_device) is used. * @dummy_data: indicates transfer is dummy bytes transfer. * @cs_change: affects chipselect after this transfer completes + * @cs_off: performs the transfer with chipselect off. * @cs_change_delay: delay between cs deassert and assert when * @cs_change is set and @spi_transfer is not the last in @spi_message * @delay: delay to be introduced after this transfer before @@ -930,6 +931,7 @@ struct spi_transfer { unsigned cs_change:1; unsigned tx_nbits:3; unsigned rx_nbits:3; + unsigned cs_off:1; #define SPI_NBITS_SINGLE 0x01 /* 1bit transfer */ #define SPI_NBITS_DUAL 0x02 /* 2bits transfer */ #define SPI_NBITS_QUAD 0x04 /* 4bits transfer */
Some components require a few clock cycles with chipselect off before or/and after the data transfer done with CS on. Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK should have one cycle before CS goes low, and two cycles after CS goes high". The cycles "before" are implicitely provided by all previous activity on the SPI bus. But the cycles "after" must be provided in order to terminate the SPI transfer. In order to use that kind of component, add a cs_off flag to spi_transfer struct. When this flag is set, the transfer is performed with chipselect off. This allows consummer to add a dummy transfer at the end of the transfer list which is performed with chipselect OFF, providing the required additional clock cycles. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> --- This is a change in the approach. Now we offer the driver/consumer a way to perform an additional transfer with chipselect off. v2 is at https://patchwork.kernel.org/project/spi-devel-general/list/?series=618784&state=*&archive=both drivers/spi/spi.c | 12 +++++++++--- include/linux/spi/spi.h | 2 ++ 2 files changed, 11 insertions(+), 3 deletions(-)