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 <[email protected]>
---
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
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.
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
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.