Linux SPI subsystem development
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Mark Brown <broonie@kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	Chris Paterson <Chris.Paterson2@renesas.com>,
	Biju Das <biju.das@bp.renesas.com>,
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Chris Brandt <Chris.Brandt@renesas.com>
Subject: Re: [PATCH] spi: spi-rspi: Add force_dma variable to spi_ops
Date: Wed, 20 Jul 2022 10:35:26 +0530	[thread overview]
Message-ID: <YteNFrNSsEfLDHR/@matsya> (raw)
In-Reply-To: <OS0PR01MB59220A67C039CCBF7D4D4AFE868F9@OS0PR01MB5922.jpnprd01.prod.outlook.com>

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

Or anything missing from context which I am not aware of?

> > > > >
> > > > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > > >
> > > > Thanks for your patch!
> > > >
> > > > > @@ -1196,6 +1197,7 @@ static const struct spi_ops rspi_rz_ops = {
> > > > >         .flags =                SPI_CONTROLLER_MUST_RX |
> > > > SPI_CONTROLLER_MUST_TX,
> > > > >         .fifo_size =            8,      /* 8 for TX, 32 for RX */
> > > > >         .num_hw_ss =            1,
> > > > > +       .force_dma =            true,
> > > > >  };
> > > >
> > > > Do you know if this is needed on RZ/A series, too?
> > >
> > > I guess it is needed?? I may be wrong. I got a link from Chris [1]. As
> > > per this still We haven't found a solution. May be the priority is
> > > changed for this activity and no one looked after this.
> > >
> > > [1]
> > 
> > Daniel said he found the issue, i.e. the dmac driver never resetting DMARS?
> 
> Currently DMARS set during prepare and it never cleared. So I added device_synchronize
> callback in DMA driver to clear the DMARS. RSPI client driver after synchronizing
> DMA callback, calls dmaengine_synchronize which clears DMARS.
> 
> With this DMA to interrupt mode switching is working fine.
> 
> Cheers,
> Biju
> 

-- 
~Vinod

  reply	other threads:[~2022-07-20  5:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-16 15:39 [PATCH] spi: spi-rspi: Add force_dma variable to spi_ops Biju Das
2022-07-18 12:33 ` Mark Brown
2022-07-18 13:06   ` Biju Das
2022-07-19  8:11 ` Geert Uytterhoeven
2022-07-19  8:29   ` Biju Das
2022-07-19  8:41     ` Geert Uytterhoeven
2022-07-19 11:28       ` Biju Das
2022-07-20  5:05         ` Vinod Koul [this message]
2022-07-20  5:13           ` Biju Das
2022-07-20 10:37             ` Vinod Koul
2022-07-20 10:54               ` Biju Das
2022-07-20 12:25                 ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YteNFrNSsEfLDHR/@matsya \
    --to=vkoul@kernel.org \
    --cc=Chris.Brandt@renesas.com \
    --cc=Chris.Paterson2@renesas.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=biju.das@bp.renesas.com \
    --cc=broonie@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox