Re: [PATCH v5 3/6] dmaengine: Add support for repeating transactions

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

 



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



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux