There was a change in the mxs-dma engine that uses a new custom flag.
The change was not applied to the mxs spi driver.
This results in chipselect being deasserted too early.
This fixes the chipselect problem by using the new flag in the mxs-spi
driver.
Fixes: ceeeb99cd821 ("dmaengine: mxs: rename custom flag")
Signed-off-by: Ralf Schlatterbeck <[email protected]>
---
For oscilloscope screenshots and a verbose explanation see my blog post
at https://blog.runtux.com/posts/2024/02/01/
History:
Omit the line break change from patch requested by Marc Kleine-Budde
<[email protected]>
drivers/spi/spi-mxs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 1bf080339b5a..88cbe4f00cc3 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -39,6 +39,7 @@
#include <linux/spi/spi.h>
#include <linux/spi/mxs-spi.h>
#include <trace/events/spi.h>
+#include <linux/dma/mxs-dma.h>
#define DRIVER_NAME "mxs-spi"
@@ -252,7 +253,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi,
desc = dmaengine_prep_slave_sg(ssp->dmach,
&dma_xfer[sg_count].sg, 1,
(flags & TXRX_WRITE) ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ DMA_PREP_INTERRUPT | MXS_DMA_CTRL_WAIT4END);
if (!desc) {
dev_err(ssp->dev,
--
2.20.1
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: http://www.runtux.com
Reichergasse 131, A-3411 Weidling email: [email protected]
On Fri, Feb 02, 2024 at 12:53:30PM +0100, Ralf Schlatterbeck wrote:
> There was a change in the mxs-dma engine that uses a new custom flag.
> The change was not applied to the mxs spi driver.
> This results in chipselect being deasserted too early.
> This fixes the chipselect problem by using the new flag in the mxs-spi
> driver.
>
> Fixes: ceeeb99cd821 ("dmaengine: mxs: rename custom flag")
> Signed-off-by: Ralf Schlatterbeck <[email protected]>
> ---
> For oscilloscope screenshots and a verbose explanation see my blog post
> at https://blog.runtux.com/posts/2024/02/01/
> History:
> Omit the line break change from patch requested by Marc Kleine-Budde
> <[email protected]>
>
> drivers/spi/spi-mxs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index 1bf080339b5a..88cbe4f00cc3 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -39,6 +39,7 @@
> #include <linux/spi/spi.h>
> #include <linux/spi/mxs-spi.h>
> #include <trace/events/spi.h>
> +#include <linux/dma/mxs-dma.h>
>
> #define DRIVER_NAME "mxs-spi"
>
> @@ -252,7 +253,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi,
> desc = dmaengine_prep_slave_sg(ssp->dmach,
> &dma_xfer[sg_count].sg, 1,
> (flags & TXRX_WRITE) ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
> - DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + DMA_PREP_INTERRUPT | MXS_DMA_CTRL_WAIT4END);
>
> if (!desc) {
> dev_err(ssp->dev,
> --
> 2.20.1
>
> --
> Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
> Open Source Consulting www: http://www.runtux.com
> Reichergasse 131, A-3411 Weidling email: [email protected]
Any news on this, will it be picked up for the next merge window?
Thanks + kind regards
Ralf Schlatterbeck
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: http://www.runtux.com
Reichergasse 131, A-3411 Weidling email: [email protected]
Hi Ralf,
On Tue, Feb 13, 2024 at 2:07 PM Ralf Schlatterbeck <[email protected]> wrote:
>
> On Fri, Feb 02, 2024 at 12:53:30PM +0100, Ralf Schlatterbeck wrote:
> > There was a change in the mxs-dma engine that uses a new custom flag.
> > The change was not applied to the mxs spi driver.
> > This results in chipselect being deasserted too early.
> > This fixes the chipselect problem by using the new flag in the mxs-spi
> > driver.
> >
> > Fixes: ceeeb99cd821 ("dmaengine: mxs: rename custom flag")
> > Signed-off-by: Ralf Schlatterbeck <[email protected]>
> > ---
> > For oscilloscope screenshots and a verbose explanation see my blog post
> > at https://blog.runtux.com/posts/2024/02/01/
I suggest putting the link to your detailed explanation into the
commit log as this is useful information.
Reviewed-by: Fabio Estevam <[email protected]>
On Tue, Feb 13, 2024 at 06:06:57PM +0100, Ralf Schlatterbeck wrote:
> On Fri, Feb 02, 2024 at 12:53:30PM +0100, Ralf Schlatterbeck wrote:
> > --
> > Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
> > Open Source Consulting www: http://www.runtux.com
> > Reichergasse 131, A-3411 Weidling email: [email protected]
> Any news on this, will it be picked up for the next merge window?
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
On Fri, 02 Feb 2024 12:53:30 +0100, Ralf Schlatterbeck wrote:
> There was a change in the mxs-dma engine that uses a new custom flag.
> The change was not applied to the mxs spi driver.
> This results in chipselect being deasserted too early.
> This fixes the chipselect problem by using the new flag in the mxs-spi
> driver.
>
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi-mxs: Fix chipselect glitch
commit: 269e31aecdd0b70f53a05def79480f15cbcc0fd6
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
On Tue, Feb 13, 2024 at 02:22:53PM -0300, Fabio Estevam wrote:
>
> On Tue, Feb 13, 2024 at 2:07 PM Ralf Schlatterbeck <[email protected]> wrote:
> > > ---
> > > For oscilloscope screenshots and a verbose explanation see my blog post
> > > at https://blog.runtux.com/posts/2024/02/01/
>
> I suggest putting the link to your detailed explanation into the
> commit log as this is useful information.
>
> Reviewed-by: Fabio Estevam <[email protected]>
Thanks for the review!
My blog post might go away at some point.
And I think when looking at the original patch (in the Fixes: line) it
is quite obvious that the file in question was overlooked during the
original change. So it was hard to find and I documented it but looking
at it in context should be pretty clear.
Thanks
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: http://www.runtux.com
Reichergasse 131, A-3411 Weidling email: [email protected]
On Tue, Feb 13, 2024 at 06:44:58PM +0000, Mark Brown wrote:
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
>
> Thanks!
Thanks!
Sorry for my impatience.
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: http://www.runtux.com
Reichergasse 131, A-3411 Weidling email: [email protected]
On Tue, Feb 13, 2024 at 5:02 PM Ralf Schlatterbeck <[email protected]> wrote:
> My blog post might go away at some point.
> And I think when looking at the original patch (in the Fixes: line) it
> is quite obvious that the file in question was overlooked during the
> original change. So it was hard to find and I documented it but looking
> at it in context should be pretty clear.
Yes, that's fine. Mark has already applied it, so we are all good.
Thanks for the fix.