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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
> > > > > 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@xxxxxxxxxxxxxx> 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.

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@xxxxxxxxxxxxxx/
[2] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220719150000.383722-2-biju.das.jz@xxxxxxxxxxxxxx/

Cheers,
Biju





[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux