* [PATCH] spi: disable chipselect after complete transfer
@ 2022-02-09 10:00 Yun Zhou
2022-02-09 13:40 ` Mark Brown
0 siblings, 1 reply; 4+ messages in thread
From: Yun Zhou @ 2022-02-09 10:00 UTC (permalink / raw)
To: broonie, yun.zhou; +Cc: linux-spi, linux-kernel, ying.xue
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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] spi: disable chipselect after complete transfer
2022-02-09 10:00 [PATCH] spi: disable chipselect after complete transfer Yun Zhou
@ 2022-02-09 13:40 ` Mark Brown
2022-02-10 2:03 ` Yun Zhou
0 siblings, 1 reply; 4+ messages in thread
From: Mark Brown @ 2022-02-09 13:40 UTC (permalink / raw)
To: Yun Zhou; +Cc: linux-spi, linux-kernel, ying.xue
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] spi: disable chipselect after complete transfer
2022-02-09 13:40 ` Mark Brown
@ 2022-02-10 2:03 ` Yun Zhou
2022-02-10 11:18 ` Mark Brown
0 siblings, 1 reply; 4+ messages in thread
From: Yun Zhou @ 2022-02-10 2:03 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, linux-kernel, ying.xue
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] spi: disable chipselect after complete transfer
2022-02-10 2:03 ` Yun Zhou
@ 2022-02-10 11:18 ` Mark Brown
0 siblings, 0 replies; 4+ messages in thread
From: Mark Brown @ 2022-02-10 11:18 UTC (permalink / raw)
To: Yun Zhou; +Cc: linux-spi, linux-kernel, ying.xue
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-02-10 11:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-09 10:00 [PATCH] spi: disable chipselect after complete transfer Yun Zhou
2022-02-09 13:40 ` Mark Brown
2022-02-10 2:03 ` Yun Zhou
2022-02-10 11:18 ` Mark Brown
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.