[PATCH] spi: disable chipselect after complete transfer

[PATCH] spi: disable chipselect after complete transfer

[Yun Zhou]

If there are 2 slaves or more on a spi bus, e.g. A and B, we processed a
transfer to A, the CS will be selected for A whose 'last_cs_enable' will
be recorded to true at the same time. Then we processed a transfer to B,
the CS will be switched to B. And then if we transmit data to A again, it
will not enable CS back to A because 'last_cs_enable' is true.
In addition, if CS is not disabled, Some controllers in automatic
transmission state will receive unpredictable data, such as Cadence SPI
controller.

Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
---
 drivers/spi/spi.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index fdd530b150a7..ebbba0b08186 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1417,7 +1417,6 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,
 				    struct spi_message *msg)
 {
 	struct spi_transfer *xfer;
-	bool keep_cs = false;
 	int ret = 0;
 	struct spi_statistics *statm = &ctlr->statistics;
 	struct spi_statistics *stats = &msg->spi->statistics;
@@ -1486,10 +1485,8 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,
 		spi_transfer_delay_exec(xfer);
 
 		if (xfer->cs_change) {
-			if (list_is_last(&xfer->transfer_list,
+			if (!list_is_last(&xfer->transfer_list,
 					 &msg->transfers)) {
-				keep_cs = true;
-			} else {
 				spi_set_cs(msg->spi, false, false);
 				_spi_transfer_cs_change_delay(msg, xfer);
 				spi_set_cs(msg->spi, true, false);
@@ -1500,8 +1497,7 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,
 	}
 
 out:
-	if (ret != 0 || !keep_cs)
-		spi_set_cs(msg->spi, false, false);
+	spi_set_cs(msg->spi, false, false);
 
 	if (msg->status == -EINPROGRESS)
 		msg->status = ret;
-- 
2.26.1

Re: [PATCH] spi: disable chipselect after complete transfer

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Wed, Feb 09, 2022 at 06:00:42PM +0800, Yun Zhou wrote:
> If there are 2 slaves or more on a spi bus, e.g. A and B, we processed a
> transfer to A, the CS will be selected for A whose 'last_cs_enable' will
> be recorded to true at the same time. Then we processed a transfer to B,
> the CS will be switched to B. And then if we transmit data to A again, it
> will not enable CS back to A because 'last_cs_enable' is true.
> In addition, if CS is not disabled, Some controllers in automatic
> transmission state will receive unpredictable data, such as Cadence SPI
> controller.

This sounds like you've got an issue with mixing devices with and
without CS_HIGH - that is probably broken but...

>  out:
> -	if (ret != 0 || !keep_cs)
> -		spi_set_cs(msg->spi, false, false);
> +	spi_set_cs(msg->spi, false, false);

...this will obviously break cs_change support, clearly that's not OK.
The last_cs_high should be moved to the device.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] spi: disable chipselect after complete transfer

[Yun Zhou]

Hi Brown,

Nice to get feedback from you!

In current source code of spi_transfer_one_message(),

1420     bool keep_cs = false;

1488         if (xfer->cs_change) {
1489             if (list_is_last(&xfer->transfer_list,
1490                      &msg->transfers)) {
1491                 keep_cs = true;
1492             } else {
1493                 spi_set_cs(msg->spi, false, false);
1494                 _spi_transfer_cs_change_delay(msg, xfer);
1495                 spi_set_cs(msg->spi, true, false);
1496             }
1497         }

1502 out:
1503     if (ret != 0 || !keep_cs)
1504         spi_set_cs(msg->spi, false, false);

if the last xfer->cs_change is true, keep_cs will be true, and it will 
not call spi_set_cs() to set CS to false. Do you mean to keep CS enabled 
in this case?

On 2/9/22 9:40 PM, Mark Brown wrote:
> On Wed, Feb 09, 2022 at 06:00:42PM +0800, Yun Zhou wrote:
>> If there are 2 slaves or more on a spi bus, e.g. A and B, we processed a
>> transfer to A, the CS will be selected for A whose 'last_cs_enable' will
>> be recorded to true at the same time. Then we processed a transfer to B,
>> the CS will be switched to B. And then if we transmit data to A again, it
>> will not enable CS back to A because 'last_cs_enable' is true.
>> In addition, if CS is not disabled, Some controllers in automatic
>> transmission state will receive unpredictable data, such as Cadence SPI
>> controller.
> This sounds like you've got an issue with mixing devices with and
> without CS_HIGH - that is probably broken but...
>
>>   out:
>> -	if (ret != 0 || !keep_cs)
>> -		spi_set_cs(msg->spi, false, false);
>> +	spi_set_cs(msg->spi, false, false);
> ...this will obviously break cs_change support, clearly that's not OK.
> The last_cs_high should be moved to the device.

I do not think it will break cs_change support. In my understanding, 
cs_change indicates whether or not change CS after an xfer completed. 
But at present if the last xfer->cs_change is true, we will not change 
CS to disabled state. Is this the result we want? I'm confused.

I look forward to your help and explanation.

Regards,

Yun

Re: [PATCH] spi: disable chipselect after complete transfer

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Thu, Feb 10, 2022 at 10:03:16AM +0800, Yun Zhou wrote:

> if the last xfer->cs_change is true, keep_cs will be true, and it will not
> call spi_set_cs() to set CS to false. Do you mean to keep CS enabled in this
> case?

Yes, that's exactly what is supposed to happen in that case.

> I do not think it will break cs_change support. In my understanding,
> cs_change indicates whether or not change CS after an xfer completed. But at
> present if the last xfer->cs_change is true, we will not change CS to
> disabled state. Is this the result we want? I'm confused.

Yes, it behaves differently on the last transfer.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]