From: Lars-Peter Clausen <lars@metafoo.de>
To: Vinod Koul <vinod.koul@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>, Takashi Iwai <tiwai@suse.de>
Cc: dmaengine@vger.kernel.org, alsa-devel@alsa-project.org,
Lars-Peter Clausen <lars@metafoo.de>
Subject: [PATCH 1/3] dma: Indicate residue granularity in dma_slave_caps
Date: Sun, 8 Dec 2013 17:18:07 +0100 [thread overview]
Message-ID: <1386519489-1935-2-git-send-email-lars@metafoo.de> (raw)
In-Reply-To: <1386519489-1935-1-git-send-email-lars@metafoo.de>
This patch adds a new field to the dma_slave_caps struct which indicates the
granularity with which the driver is able to update the residue field of the
dma_tx_state struct. Making this information available to dmaengine users allows
them to make better decisions on how to operate. E.g. for audio certain features
like wakeup less operation or timer based scheduling only make sense and work
correctly if the reported residue is fine-grained enough.
Right now four different levels of granularity are supported:
* DESCRIPTOR: The DMA channel is only able to tell whether a descriptor has
been completed or not, which means residue reporting is not supported by
this channel. The residue field of the dma_tx_state field will always be
0.
* SEGMENT: The DMA channel updates the residue field after each successfully
completed segment of the transfer (For cyclic transfers this is after each
period). This is typically implemented by having the hardware generate an
interrupt after each transferred segment and then the drivers updates the
outstanding residue by the size of the segment. Another possibility is if
the hardware supports SG and the segment descriptor has a field which gets
set after the segment has been completed. The driver then counts the
number of segments without the flag set to compute the residue.
* BURST: The DMA channel updates the residue field after each transferred
burst. This is typically only supported if the hardware has a progress
register of some sort (E.g. a register with the current read/write address
or a register with the amount of bursts/beats/bytes that have been
transferred or still need to be transferred).
* BYTE: Same as BURST but with a byte level granularity.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
include/linux/dmaengine.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 41cf0c3..b7a14d0 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -363,6 +363,21 @@ struct dma_slave_config {
unsigned int slave_id;
};
+/**
+ * enum dma_residue_granularity - Granularity of the reported transfer residue
+ * @DMA_RESIDUE_GRANULATRITY_DESCRIPTOR: Residue reporting is not supported.
+ * @DMA_RESIDUE_GRANULATRITY_SEGMENT: Residue is updated with each completed
+ * segment in the descriptor.
+ * @DMA_RESIDUE_GRANULATRITY_BURST: Residue is updated with each transfered burst
+ * @DMA_RESIDUE_GRANULATRITY_BYTE: Residue is updated with each transfered byte
+ */
+enum dma_residue_granularity {
+ DMA_RESIDUE_GRANULARITY_DESCRIPTOR = 0,
+ DMA_RESIDUE_GRANULARITY_SEGMENT = 1,
+ DMA_RESIDUE_GRANULARITY_BURST = 2,
+ DMA_RESIDUE_GRANULARITY_BYTE = 3,
+};
+
/* struct dma_slave_caps - expose capabilities of a slave channel only
*
* @src_addr_widths: bit mask of src addr widths the channel supports
@@ -373,6 +388,7 @@ struct dma_slave_config {
* should be checked by controller as well
* @cmd_pause: true, if pause and thereby resume is supported
* @cmd_terminate: true, if terminate cmd is supported
+ * @residue_granularity: granularity of the reported transfer residue
*/
struct dma_slave_caps {
u32 src_addr_widths;
@@ -380,6 +396,7 @@ struct dma_slave_caps {
u32 directions;
bool cmd_pause;
bool cmd_terminate;
+ enum dma_residue_granularity residue_granularity;
};
static inline const char *dma_chan_name(struct dma_chan *chan)
--
1.8.0
next prev parent reply other threads:[~2013-12-08 16:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-08 16:18 [PATCH 0/3] dma: Indicate residue granularity in dma_slave_caps Lars-Peter Clausen
2013-12-08 16:18 ` Lars-Peter Clausen [this message]
2013-12-08 16:18 ` [PATCH 2/3] dma: pl330: Set residue_granularity Lars-Peter Clausen
2013-12-08 16:18 ` [PATCH 3/3] ASoC: generic-dmaengine-pcm: Check DMA residue granularity Lars-Peter Clausen
2013-12-09 17:13 ` [PATCH 0/3] dma: Indicate residue granularity in dma_slave_caps Mark Brown
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=1386519489-1935-2-git-send-email-lars@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=lgirdwood@gmail.com \
--cc=tiwai@suse.de \
--cc=vinod.koul@intel.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).