On Mon, 31 May 2010 11:03:21 +0300 Peter Ujfalusi <peter.ujfalusi@xxxxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
