Message ID | 20190628123023.4696-1-nuno.sa@analog.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | spi: spi-bcm2835.c: Fix 3-wire mode | expand |
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á <nuno.sa@analog.com> 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á <nuno.sa@analog.com> > > 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á <nuno.sa@analog.com> > > > > 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
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);
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á <nuno.sa@analog.com> --- drivers/spi/spi-bcm2835.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)