[alsa-devel] [PATCH 0/3] dma: Indicate residue granularity in dma_slave_caps

[Mark Brown]

On Sun, Dec 08, 2013 at 05:18:06PM +0100, Lars-Peter Clausen wrote:

Please word wrap a bit earlier, you're right at 80 columns which causes
issues when quoted.

> ALSA period pointer depends on the granularity of the reported residue. E.g. if
> residue is only updated once every period this means that the position in the
> buffer from/to which the hardware is currently reading/writing could be
> anywhere between the reported PCM pointer and the reported PCM pointer plus one

Since there's quite a bit of development going on with the DMA stuff
it'd be good if this could be merged via ASoC (either itself or as a
shared branch) so we can get the ASoC changes in easily.

> 	* BYTE: Same as BURST but with a byte level granularity.

> I've only included the last one for completeness and I'm not sure if we really
> need it. Even if the hardware is able to report the amount of transferred data
> with a byte level granularity the lower bits will not carry too much
> meaning. When using burst transfers the lower bits will remain the same for
> longer periods and then rapidly increment during the burst transfer. The upper
> bits though will increment with the actual frequency with which the data is
> consumed. And that's what applications are typically interested in.

I share your concerns about the usefulness here, and once you get to
this point you're starting to worry about if it means bytes on the
device side or the memory side which is really angels dancing on the
head of a pin sort of thing.  That can apply to burst sizes as well
where it gets a bit more relevant, we might want to say which we mean
there (I'd assume right now it's just the same as our current burst
configuration) if it even matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20131209/45d9b0c1/attachment.sig>