From: Vinod Koul <vkoul@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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 23:24:41 +0530 [thread overview]
Message-ID: <20200703175441.GR273932@vkoul-mobl> (raw)
In-Reply-To: <20200703174713.GE14282@pendragon.ideasonboard.com>
HI Laurent,
On 03-07-20, 20:47, Laurent Pinchart wrote:
> On Fri, Jul 03, 2020 at 11:07:10PM +0530, Vinod Koul wrote:
> > On 03-07-20, 20:22, Laurent Pinchart wrote:
> > > On Fri, Jul 03, 2020 at 10:40:39PM +0530, Vinod Koul wrote:
> > > > 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 ?
> >
> > I would like to change the language of the explanation to not forbid
> > other uses, but they would be enabled in txn when we have users..
>
> The documentation isn't set in stone, it can be updated when support for
> DMA_PREP_REPEAT will be enabled in other transaction types. I think it's
> better to have the documentation and code match, the documentation
> should describe the current implementation. I can add an additional
> sentence at the end of the paragraph to state "Support for this flag in
> other transaction types may be added in the future if the need arises."
> if that makes you feel better about it.
Okay I will be okay with that caveat
> > > > 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 ?
> >
> > End of Burst, DMA would complete current burst and then terminate. I do
> > understand it is not applicable for your case as your hw doesn't support
> > it and would be unused but this is another case which would be useful so
> > for completeness we should add this
>
> Why not add it when we'll have a user for it ? How can you otherwise
> guarantee that it's a correct API if there's not even a single user that
> we can test the design with ?
Okay lets not add but add a note that additional flags can be added when
required like EOB
Also can we add a note in Documentation about these flags and how they
should be used for repeating transactions.
Thanks
--
~Vinod
next prev parent reply other threads:[~2020-07-03 17:54 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
2020-07-03 17:37 ` Vinod Koul
2020-07-03 17:47 ` Laurent Pinchart
2020-07-03 17:54 ` Vinod Koul [this message]
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=20200703175441.GR273932@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=SATISHNA@xilinx.com \
--cc=dmaengine@vger.kernel.org \
--cc=hyun.kwon@xilinx.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=michal.simek@xilinx.com \
--cc=peter.ujfalusi@ti.com \
--cc=tejasu@xilinx.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;
as well as URLs for NNTP newsgroup(s).