All of lore.kernel.org
 help / color / mirror / Atom feed
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 6/6] Documentation: dmaengine: document DMA_CTRL_ACK
Date: Mon, 25 May 2015 22:22:57 +0530	[thread overview]
Message-ID: <20150525165257.GI3140@localhost> (raw)
In-Reply-To: <87twvekij8.fsf@belgarion.home>

On Thu, May 14, 2015 at 10:31:39PM +0200, Robert Jarzmik wrote:
> Maxime Ripard <maxime.ripard@free-electrons.com> writes:
> 
> > Hi Robert,
> >
> >>    * DMA_CTRL_ACK
> >> -    - Undocumented feature
> >> -    - No one really has an idea of what it's about, besides being
> >> -      related to reusing the DMA transaction descriptors or having
> >> -      additional transactions added to it in the async-tx API
> >> -    - Useless in the case of the slave API
> >> +    - if set, the TX transfer can be reused after being completed.
> >
> > Your sentences should start with an upper-case letter.
> Ack.
> 
> >> +    - there is a guarantee the TX won't be freed until it is acked
> >> +      by async_tx_ack()
> >
> > We never talked about what a "TX transfer" is in the
> > documentation. That should be documented.
> I'll remove the "TX", the transfer is widely used in this documentation.
> 
> >
> >> +    - as a consequence, if a device driver wants to skip the dma_map_sg() and
> >> +      dma_unmap_sg() because the DMA'd data wasn't used, it can resubmit the
> >> +      transfer right after its completion.
> >
> > From a provider PoV, the data should always be mapped and / or
> > allocated in coherent way, so I'm not sure how does that's relevant in
> > the provider doc.
> It's relevant because it says the mapping/unmapping is not necessary _between_ 2
> submission of a transfer. This implies it is mapped, as it is a requirement for
> the very first submission.
> 
> > Also, we should still mention that it's !slave API only.
> Certainly not, it's fully slave API, that's the purpose of this patch.
Its is not dependent on slave, it cna be used by slave as well as other
users

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>,
	Jonathan Corbet <corbet@lwn.net>, Daniel Mack <daniel@zonque.org>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	dmaengine@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 6/6] Documentation: dmaengine: document DMA_CTRL_ACK
Date: Mon, 25 May 2015 22:22:57 +0530	[thread overview]
Message-ID: <20150525165257.GI3140@localhost> (raw)
In-Reply-To: <87twvekij8.fsf@belgarion.home>

On Thu, May 14, 2015 at 10:31:39PM +0200, Robert Jarzmik wrote:
> Maxime Ripard <maxime.ripard@free-electrons.com> writes:
> 
> > Hi Robert,
> >
> >>    * DMA_CTRL_ACK
> >> -    - Undocumented feature
> >> -    - No one really has an idea of what it's about, besides being
> >> -      related to reusing the DMA transaction descriptors or having
> >> -      additional transactions added to it in the async-tx API
> >> -    - Useless in the case of the slave API
> >> +    - if set, the TX transfer can be reused after being completed.
> >
> > Your sentences should start with an upper-case letter.
> Ack.
> 
> >> +    - there is a guarantee the TX won't be freed until it is acked
> >> +      by async_tx_ack()
> >
> > We never talked about what a "TX transfer" is in the
> > documentation. That should be documented.
> I'll remove the "TX", the transfer is widely used in this documentation.
> 
> >
> >> +    - as a consequence, if a device driver wants to skip the dma_map_sg() and
> >> +      dma_unmap_sg() because the DMA'd data wasn't used, it can resubmit the
> >> +      transfer right after its completion.
> >
> > From a provider PoV, the data should always be mapped and / or
> > allocated in coherent way, so I'm not sure how does that's relevant in
> > the provider doc.
> It's relevant because it says the mapping/unmapping is not necessary _between_ 2
> submission of a transfer. This implies it is mapped, as it is a requirement for
> the very first submission.
> 
> > Also, we should still mention that it's !slave API only.
> Certainly not, it's fully slave API, that's the purpose of this patch.
Its is not dependent on slave, it cna be used by slave as well as other
users

-- 
~Vinod


  reply	other threads:[~2015-05-25 16:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14 17:53 [PATCH v3 1/6] Documentation: dmaengine: pxa-dma design Robert Jarzmik
2015-05-14 17:53 ` Robert Jarzmik
2015-05-14 17:53 ` [PATCH v3 2/6] MAINTAINERS: add pxa dma driver to pxa architecture Robert Jarzmik
2015-05-14 17:53   ` Robert Jarzmik
2015-05-14 17:53 ` [PATCH v3 3/6] dmaengine: pxa: add pxa dmaengine driver Robert Jarzmik
2015-05-14 17:53   ` Robert Jarzmik
2015-05-25 16:50   ` Vinod Koul
2015-05-25 16:50     ` Vinod Koul
2015-05-25 20:55     ` Robert Jarzmik
2015-05-25 20:55       ` Robert Jarzmik
2015-05-14 17:53 ` [PATCH v3 4/6] dmaengine: pxa_dma: add debug information Robert Jarzmik
2015-05-14 17:53   ` Robert Jarzmik
2015-05-14 17:53 ` [PATCH v3 5/6] dmaengine: pxa_dma: add support for legacy transition Robert Jarzmik
2015-05-14 17:53   ` Robert Jarzmik
2015-05-14 17:53 ` [PATCH v3 6/6] Documentation: dmaengine: document DMA_CTRL_ACK Robert Jarzmik
2015-05-14 17:53   ` Robert Jarzmik
2015-05-14 18:38   ` Maxime Ripard
2015-05-14 18:38     ` Maxime Ripard
2015-05-14 20:31     ` Robert Jarzmik
2015-05-14 20:31       ` Robert Jarzmik
2015-05-25 16:52       ` Vinod Koul [this message]
2015-05-25 16:52         ` Vinod Koul
2015-05-25 20:57         ` Robert Jarzmik
2015-05-25 20:57           ` Robert Jarzmik
2015-05-15 19:11 ` [PATCH v3 1/6] Documentation: dmaengine: pxa-dma design Robert Jarzmik
2015-05-15 19:11   ` Robert Jarzmik
2015-05-19 18:51   ` Robert Jarzmik
2015-05-19 18:51     ` Robert Jarzmik
2015-05-25 11:03     ` Robert Jarzmik
2015-05-25 11:03       ` Robert Jarzmik

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=20150525165257.GI3140@localhost \
    --to=vinod.koul@intel.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.