[alsa-devel] davici-mcasp: "tx-num-evt" confusion with number of serializers
mike.looijmans at topic.nl
Tue Feb 26 19:40:37 CET 2013
On 02/26/2013 03:06 PM, Michal Bachraty wrote:
> I'm working on multichannel version of davinci-mcasp and also davinci-pcm. I
> have first version running and now I want to refine code. I found one confusion
> in davinci-mcasp with using of DT property "tx-num-evt". In DT binding
> documentation "tx-num-evt" is defined as "FIFO levels", but in Mcasp src, there
> is code, which mixes tx-num-evt with number of serializers (i2s data lines)
> that are enabled for data playback and receive (dev->txnumevt * tx_ser)
> mcasp_mod_bits(dev->base + MCASP_VER3_WFIFOCTL,
> (((dev->txnumevt * tx_ser) << 8), NUMEVT_MASK);
> From dacinci pcm, DMA data tranfer use txnumevt as number of serializers and
> also for data prefetching.
> I undestand definition "FIFO levels" as how many prefetched data are in FIFO.
> Prefetched data are for me frame data / 2 ( all left or right channels for
> one sampling time). This results me from AM335x FIFO documantation.
> What is original purpose for "tx-num-evt" parameter?
From what I remember (I'm using the davinci to record from up to 8
codecs chips simultaneously) the value sets a threshold for the DMA
request (if the FIFO is enabled - and I can't think of a reason why
anyone would NOT want to enable the fifo...).
Postponing the DMA request until there are #channels data entries in the
fifo buffer makes sense to me. Setting the txnumevt to a higher value
might reduce the load on the memory controller (that's what TI claims),
at the cost of a higher risk of overrunning the fifo, and increased
latency. Setting it to less than the number of channels isn't useful
either - which application would be interested in "half" the channel data?
I have always considered the parameter to be a boolean (please use the
fifo) rather than an integer setting.
Mike Looijmans - Topic Automation
More information about the Alsa-devel