All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.