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
next prev parent reply other threads:[~2015-05-25 16:52 UTC|newest]
Thread overview: 15+ 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 ` [PATCH v3 2/6] MAINTAINERS: add pxa dma driver to pxa architecture Robert Jarzmik
2015-05-14 17:53 ` [PATCH v3 3/6] dmaengine: pxa: add pxa dmaengine driver Robert Jarzmik
2015-05-25 16:50 ` Vinod Koul
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 ` [PATCH v3 5/6] dmaengine: pxa_dma: add support for legacy transition Robert Jarzmik
2015-05-14 17:53 ` [PATCH v3 6/6] Documentation: dmaengine: document DMA_CTRL_ACK Robert Jarzmik
2015-05-14 18:38 ` Maxime Ripard
2015-05-14 20:31 ` Robert Jarzmik
2015-05-25 16:52 ` Vinod Koul [this message]
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-19 18:51 ` 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 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).