Re: [RFC PATCH 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes

[Jarkko Nikula <jhnikula@gmail.com>]

On Mon, 31 May 2010 11:03:21 +0300
Peter Ujfalusi <peter.ujfalusi@nokia.com> wrote:

Looks good move forward with the notes by you and others. Few questions
below.

> This means, that the size of the FIFO
> depends on the McBSP word size configuration.
> For example on McBSP3:
> 16bit samples: size is 128 * 2 = 256 bytes
> 32bit samples: size is 128 * 4 = 512 bytes
> It is simpler to place constraint for buffer and period based on channels.
> McBSP3 as example again (16 or 32 bit samples):
> 1 channel (mono): size is 128 frames (128 words)
> 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
> 4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
> 
So McBSP FIFO holds always samples independently of number of channels
or sample size? That makes sense why I see DMA pointer advancing at 512
frame steps when max_tx_thres is 1024 (aplay -f dat /dev/zero).

> The series changes how the users of McBSP are configuring the FIFO:
> It used to be 0 based (0 meant 1 word threshold). After this series users can
> configure the threshold in 1 base mode (1 means 1 word threshold).
> The platform code now provides the _full_ size of the FIFO in words, instead of
> the already limited value used in the past.
> 
Definitely good. It's much more easier to remember and define real
threshold size than some -1 what's ends up to threshold register
value :-)

Btw, I don't remember what was the reason why maximum threshold value
must be -0x10 from FIFO size?


-- 
Jarkko