dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: dmaengine@vger.kernel.org, Michal Simek <michal.simek@xilinx.com>,
	Hyun Kwon <hyun.kwon@xilinx.com>,
	Tejas Upadhyay <tejasu@xilinx.com>,
	Satish Kumar Nagireddy <SATISHNA@xilinx.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>
Subject: Re: [PATCH v5 3/6] dmaengine: Add support for repeating transactions
Date: Fri, 3 Jul 2020 20:22:42 +0300	[thread overview]
Message-ID: <20200703172242.GC14282@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20200703171039.GO273932@vkoul-mobl>

Hi Vinod,

On Fri, Jul 03, 2020 at 10:40:39PM +0530, Vinod Koul wrote:
> Hi Laurent,
> 
> On 28-05-20, 05:52, Laurent Pinchart wrote:
> 
> > @@ -176,6 +178,18 @@ struct dma_interleaved_template {
> >   * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is command
> >   *  data and the descriptor should be in different format from normal
> >   *  data descriptors.
> > + * @DMA_PREP_REPEAT: tell the driver that the transaction shall be automatically
> > + *  repeated when it ends if no other transaction has been issued on the same
> > + *  channel. If other transactions have been issued, this transaction completes
> > + *  normally. This flag is only applicable to interleaved transactions and is
> > + *  ignored for all other transaction types.
> 
> 1. Let us not restrict this to only interleave (hint we can in future
> replace cyclic API)

Peter wanted to already implement support for DMA_PREP_REPEAT in other
transaction types, and you replied that you would prefer not enabling
APIs without users, waiting for the first user of DMA_PREP_REPEAT with a
non-interleaved transaction to do so. Your comment here seems to
contract that. Which way do you want to go ?

> 2. DMA_PREP_REPEAT telling the transaction shall be automatically
> repeated is okay. No issues with that
> 
> > + * @DMA_PREP_LOAD_EOT: tell the driver that the transaction shall replaced any
> 
> s/replaced/replace
> 
> > + *  active repeated (as indicated by DMA_PREP_REPEAT) transaction when the
> > + *  repeated transaction terminate. Not setting this flag when the previously
> > + *  queued transaction is marked with DMA_PREP_REPEAT will cause the new
> > + *  transaction to never be processed and stay in the issued queue forever.
> > + *  The flag is ignored if the previous transaction is not a repeated
> > + *  transaction.
> 
> I am happy with this bit, I think we dont need to specify something like
> DMA_PREP_LOAD_NEXT given the explanation here, so adding
> DMA_PREP_LOAD_EOT would mean that.

Just to clarify, does that mean I don't need to add a DMA_PREP_LOAD_NEXT
flag in the API ?

> Can we add a corresponding EOB as well to complete this

What's EOB ?

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2020-07-03 17:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28  2:52 [PATCH v5 0/6] dma: Add Xilinx ZynqMP DPDMA driver Laurent Pinchart
2020-05-28  2:52 ` [PATCH v5 1/6] dt: bindings: dma: xilinx: dpdma: DT bindings for Xilinx DPDMA Laurent Pinchart
2020-05-28  2:52 ` [PATCH v5 2/6] dmaengine: virt-dma: Use lockdep to check locking requirements Laurent Pinchart
2020-05-28  2:52 ` [PATCH v5 3/6] dmaengine: Add support for repeating transactions Laurent Pinchart
2020-07-03 17:10   ` Vinod Koul
2020-07-03 17:22     ` Laurent Pinchart [this message]
2020-07-03 17:37       ` Vinod Koul
2020-07-03 17:47         ` Laurent Pinchart
2020-07-03 17:54           ` Vinod Koul
2020-07-08 20:19             ` Laurent Pinchart
2020-05-28  2:52 ` [PATCH v5 4/6] dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver Laurent Pinchart
2020-07-03 17:32   ` Vinod Koul
2020-07-03 17:43     ` Laurent Pinchart
2020-05-28  2:52 ` [PATCH v5 5/6] dmaengine: xilinx: dpdma: Add debugfs support Laurent Pinchart
2020-05-28  2:52 ` [PATCH v5 6/6] arm64: dts: zynqmp: Add DPDMA node Laurent Pinchart
2020-06-29  9:30 ` [PATCH v5 0/6] dma: Add Xilinx ZynqMP DPDMA driver Laurent Pinchart
2020-06-29  9:56   ` Vinod Koul
2020-06-29 23:39     ` Laurent Pinchart

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=20200703172242.GC14282@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=SATISHNA@xilinx.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=hyun.kwon@xilinx.com \
    --cc=michal.simek@xilinx.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=tejasu@xilinx.com \
    --cc=vkoul@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).