As stated in
https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md,
one of rx or tx buffer's must be null. However, if DMA is enabled, the
driver sets the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX on the
controller flags. Hence, the spi core will provide dummy buffers even if
one of the buffers was set to null by the device driver. Thus, the
communication with the 3-wire device fails.
This patch uses the prepare_message callback to look for the device mode
and sets/clears the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX on a
per spi message basis. It also assumes that DMA is not supported on
half-duplex devices.
Signed-off-by: Nuno Sá <[email protected]>
---
drivers/spi/spi-bcm2835.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index 6f243a90c844..8993a15a4684 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -674,6 +674,10 @@ static bool bcm2835_spi_can_dma(struct spi_controller *ctlr,
if (tfr->len < BCM2835_SPI_DMA_MIN_LENGTH)
return false;
+ /* Do not DMA on half-duplex devices */
+ if (spi->mode & SPI_3WIRE)
+ return false;
+
/* return OK */
return true;
}
@@ -902,6 +906,15 @@ static int bcm2835_spi_prepare_message(struct spi_controller *ctlr,
cs |= BCM2835_SPI_CS_CPOL;
if (spi->mode & SPI_CPHA)
cs |= BCM2835_SPI_CS_CPHA;
+ /*
+ * For half-duplex devices, one of tx or rx buffers must be null
+ * for one spi transfer. Hence, we need to clear the spi controller
+ * flags so that we don't get dummy buffers...
+ */
+ if (spi->mode & SPI_3WIRE)
+ master->flags &= ~(SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX);
+ else if (master->can_dma)
+ master->flags |= (SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX);
bcm2835_wr(bs, BCM2835_SPI_CS, cs);
--
2.22.0
Hi Nuno,
Am 28.06.19 um 14:30 schrieb Nuno Sá:
> As stated in
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md,
> one of rx or tx buffer's must be null. However, if DMA is enabled, the
> driver sets the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX on the
> controller flags. Hence, the spi core will provide dummy buffers even if
> one of the buffers was set to null by the device driver. Thus, the
> communication with the 3-wire device fails.
>
> This patch uses the prepare_message callback to look for the device mode
> and sets/clears the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX on a
> per spi message basis. It also assumes that DMA is not supported on
> half-duplex devices.
>
> Signed-off-by: Nuno Sá <[email protected]>
i never tested the 3-wire mode. Could you please describe your test setup?
@Martin, @Lukas Are you fine with this patch?
On Fri, Jun 28, 2019 at 05:23:54PM +0200, Stefan Wahren wrote:
> Am 28.06.19 um 14:30 schrieb Nuno S?:
> > As stated in
> > https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md,
> > one of rx or tx buffer's must be null. However, if DMA is enabled, the
> > driver sets the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX on the
> > controller flags. Hence, the spi core will provide dummy buffers even if
> > one of the buffers was set to null by the device driver. Thus, the
> > communication with the 3-wire device fails.
> >
> > This patch uses the prepare_message callback to look for the device mode
> > and sets/clears the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX on a
> > per spi message basis. It also assumes that DMA is not supported on
> > half-duplex devices.
> >
> > Signed-off-by: Nuno S? <[email protected]>
>
> i never tested the 3-wire mode. Could you please describe your test setup?
__spi_validate() returns -EINVAL if 3-wire mode is used and both buffers
are non-NULL, I guess that's the problem.
> @Martin, @Lukas Are you fine with this patch?
I have a patch set in the pipeline to drop SPI_CONTROLLER_MUST_RX
and SPI_CONTROLLER_MUST_TX from spi-bcm2835.c.
Latest snapshot is available here (top-most 10 commits):
https://github.com/l1k/linux/commits/revpi_staging
@Nuno, could you give this branch a spin and see if it fixes the
issue for you? If so, this might be a better solution. Your patch
is fine in principle since it works around the problem, but the
patch set on the above-linked branch fixes it at the root.
It also provides a nice welcome speedup and reduces resource
consumption.
I've been working on this on-and-off for about half a year,
I think the patch set is in pretty good shape now so I was
planning to submit it probably in 2 weeks or so.
Thanks,
Lukas
Hi Lukas and Stefan,
On Fri, 2019-06-28 at 21:00 +0200, Lukas Wunner wrote:
>
> On Fri, Jun 28, 2019 at 05:23:54PM +0200, Stefan Wahren wrote:
> > Am 28.06.19 um 14:30 schrieb Nuno Sá:
> > > As stated in
> > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md,
> > > one of rx or tx buffer's must be null. However, if DMA is
> > > enabled, the
> > > driver sets the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX
> > > on the
> > > controller flags. Hence, the spi core will provide dummy buffers
> > > even if
> > > one of the buffers was set to null by the device driver. Thus,
> > > the
> > > communication with the 3-wire device fails.
> > >
> > > This patch uses the prepare_message callback to look for the
> > > device mode
> > > and sets/clears the SPI_CONTROLLER_MUST_RX |
> > > SPI_CONTROLLER_MUST_TX on a
> > > per spi message basis. It also assumes that DMA is not supported
> > > on
> > > half-duplex devices.
> > >
> > > Signed-off-by: Nuno Sá <[email protected]>
> >
> > i never tested the 3-wire mode. Could you please describe your test
> > setup?
I'm working on a rpi cape which uses this device
https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/frequency/adf4371.c
which is connected in 3-WIRE mode. I could confirm that spi was not
working.
>
> __spi_validate() returns -EINVAL if 3-wire mode is used and both
> buffers
> are non-NULL, I guess that's the problem.
In my case, __spi_validate() was ok because my device driver is passing
one of rx or tx as NULL. The problem is in spi_map_msg() which
allocates dummy buffers (because of the ctrl flags). As a result, in
bcm2835_spi_transfer_one() we set "cs |= BCM2835_SPI_CS_REN;" when we
want to do tx only. I believe this was the actual problem...
>
>
> > @Martin, @Lukas Are you fine with this patch?
>
> I have a patch set in the pipeline to drop SPI_CONTROLLER_MUST_RX
> and SPI_CONTROLLER_MUST_TX from spi-bcm2835.c.
>
> Latest snapshot is available here (top-most 10 commits):
> https://github.com/l1k/linux/commits/revpi_staging
>
> @Nuno, could you give this branch a spin and see if it fixes the
> issue for you? If so, this might be a better solution. Your patch
> is fine in principle since it works around the problem, but the
> patch set on the above-linked branch fixes it at the root.
> It also provides a nice welcome speedup and reduces resource
> consumption.
>
> I've been working on this on-and-off for about half a year,
> I think the patch set is in pretty good shape now so I was
> planning to submit it probably in 2 weeks or so.
>
This looks great. I will try to give this a try still today.
> Thanks,
>
> Lukas
Regards,
Nuno Sá
On Mon, Jul 01, 2019 at 07:24:23AM +0000, Sa, Nuno wrote:
> The problem is in spi_map_msg() which
> allocates dummy buffers (because of the ctrl flags). As a result, in
> bcm2835_spi_transfer_one() we set "cs |= BCM2835_SPI_CS_REN;" when we
> want to do tx only. I believe this was the actual problem...
I see. In that case, try:
/* handle all the 3-wire mode */
- if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf))
+ if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf != ctlr->dummy_rx))
cs |= BCM2835_SPI_CS_REN;
else
cs &= ~BCM2835_SPI_CS_REN;
Use master->dummy_rx instead of ctlr->dummy_rx prior to commit
5f336ea53b6b ("spi: bcm2835: Replace spi_master by spi_controller").
This could be something that users of your cape might use on older
kernels in lieu of my upcoming patch set to drop MUST_RX / MUST_TX.
Thanks,
Lukas
On Mon, 2019-07-01 at 13:55 +0200, Lukas Wunner wrote:
> I see. In that case, try:
>
> /* handle all the 3-wire mode */
> - if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf))
> + if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf != ctlr->dummy_rx))
> cs |= BCM2835_SPI_CS_REN;
> else
> cs &= ~BCM2835_SPI_CS_REN;
>
This worked fine. Also, I did a quick backport of the state of your
driver's (both spi-bcm2835 and bcm2835-dma) in revpi_staging and it
also worked fine with my device.
So, as far as I understand, the above suggestion (or my patch) is not
intended to be upstreamed, right? It is just a temporary fix that I can
use while your patchset gets upstream.
Thanks for your help!
Nuno Sá
On Mon, Jul 01, 2019 at 02:21:21PM +0000, Sa, Nuno wrote:
> On Mon, 2019-07-01 at 13:55 +0200, Lukas Wunner wrote:
> > I see. In that case, try:
> >
> > /* handle all the 3-wire mode */
> > - if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf))
> > + if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf != ctlr->dummy_rx))
> > cs |= BCM2835_SPI_CS_REN;
> > else
> > cs &= ~BCM2835_SPI_CS_REN;
>
> This worked fine. Also, I did a quick backport of the state of your
> driver's (both spi-bcm2835 and bcm2835-dma) in revpi_staging and it
> also worked fine with my device.
> So, as far as I understand, the above suggestion (or my patch) is not
> intended to be upstreamed, right? It is just a temporary fix that I can
> use while your patchset gets upstream.
Thanks for testing. I've just submitted the above as a fix for 5.3.
(Actually with a small change, the check for (tfr->rx_buf) needs to
be preserved in case DMA is disabled.)
The patch can be backported to 5.2 and older stable kernels if "ctlr"
is replaced by "master", we can inform Greg about that once the patch
lands in Linus' tree. And I've amended my patch set to revert this
patch when dropping MUST_RX.
Thanks,
Lukas