Re: [PATCH] spi: spi-rspi: Add force_dma variable to spi_ops

[Vinod Koul <vkoul@kernel.org>]

On 20-07-22, 10:54, Biju Das wrote:
> Hi Vinod,
> 
> > Subject: Re: [PATCH] spi: spi-rspi: Add force_dma variable to spi_ops
> > 
> > On 20-07-22, 05:13, Biju Das wrote:
> > > Hi Vinod,
> > >
> > > > Subject: Re: [PATCH] spi: spi-rspi: Add force_dma variable to
> > > > spi_ops
> > > >
> > > > On 19-07-22, 11:28, Biju Das wrote:
> > > > > Hi Geert,
> > > > >
> > > > > +Vinod
> > > > >
> > > > > > Subject: Re: [PATCH] spi: spi-rspi: Add force_dma variable to
> > > > > > spi_ops
> > > > > >
> > > > > > Hi Biju,
> > > > > >
> > > > > > On Tue, Jul 19, 2022 at 10:29 AM Biju Das
> > > > > > <biju.das.jz@bp.renesas.com>
> > > > > > wrote:
> > > > > > > > Subject: Re: [PATCH] spi: spi-rspi: Add force_dma variable
> > > > > > > > to spi_ops On Sat, Jul 16, 2022 at 5:39 PM Biju Das
> > > > > > <biju.das.jz@bp.renesas.com> wrote:
> > > > > > > > > On RZ/G2L SoCs switching from DMA to interrupt mode,
> > > > > > > > > causes timeout issue as we are not getting Rx interrupt
> > > > > > > > > even though SPRF bit is set in the status register.
> > > > > > > > >
> > > > > > > > > But there is no issue if we don't switch between interrupt
> > > > > > > > > to DMA mode or vice versa.
> > > > > > > > >
> > > > > > > > > Performance comparison between interrupt and DMA mode on
> > > > > > > > > RZ/Five SMARC platform connected to a display module shows
> > > > > > > > > that performance and CPU utilization is much better with
> > > > > > > > > DMA mode compared to interrupt mode
> > > > > > > > > (1->65 fps) and (98->8%).
> > > > > > > > >
> > > > > > > > > This patch introduces a variable force_dma to avoid
> > > > > > > > > switching between DMA to interrupt mode for RZ platforms.
> > > >
> > > > Why do you need a variable for that, if DMA is availble (you were
> > > > able to allocate channels) then use DMA, otherwise fall back to PIO..
> > >
> > > I was using DMA. We are not getting rspi interrupts after the DMA to
> > > PIO switch because of [1]. ie, we are not clearing DMAR in DMA driver
> > > and interrupt requests to the interrupt controller are masked.
> > >
> > > [1]
> > >
> > > >
> > > > Or anything missing from context which I am not aware of?
> > >
> > > After this discussion, I have posted [1] and [2] to fix this issue.
> > >
> > > [2]
> > 
> > Thanks for the explanation Biju. But why do we need .force_dma flag?
> 
> It is not required. This patch is not valid anymore.

okay, that sounds about right!

> Initially I met with an issue(PIO fallback does not work). So posted this patch to make all transfer DMA by using .force_dma flag.
> 
> Then Mark suggested that we should find the root cause. After that, Geert mentioned 
> we are not clearing DMARS, that is the reason for interrupt miss.
> 
> During DMA prepare, we set RSPI DMARS and signal is set for DMA transfer request signal
> and it masks rspi interrupts. When we do PIO mode, still DMARS is set, and we won't get rspi
> interrupt.
> 
> The new patches which I posted[1] and [2] clears DMARS in dmaengine_synchronize() in dma callback
> after synchronizing with wait_event and PIO fallback works as expected.
> 
> [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220719150000.383722-1-biju.das.jz@bp.renesas.com/
> [2] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220719150000.383722-2-biju.das.jz@bp.renesas.com/
> 
> Cheers,
> Biju

-- 
~Vinod