| Message ID | 20220209100042.22941-1-yun.zhou@windriver.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | spi: disable chipselect after complete transfer | expand |
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.
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;
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(-)