[alsa-devel] snd-soc-pxa-ssp I2C/FIFO issues

[pHilipp Zabel]

On Mon, Mar 9, 2009 at 4:36 PM, Daniel Mack <daniel at caiaq.de> wrote:
> Hi Philipp,
>
> On Mon, Mar 09, 2009 at 03:47:35PM +0100, pHilipp Zabel wrote:
>> Magician needs stereo S16_LE input data from alsa, DAIFMT_DSP_A on the
>> wire with a frame size of 16 bit (one frame for each channel) and thus
>> 2-byte DMA transfers to the FIFO (currently called 'mono' DMA params).
>> Zylonite's current code uses 32 bit frame size and 4-byte DMA
>> transfers to emulate I2S (S16_LE,stereo). Network mode seems to work,
>> so it could be changed to use two 16 bit slots instead with 2-byte DMA
>> transfers (which would make Magician happy). But...
>
> That's just one mode the driver has to support, which it currently does
> already, right?

The DAI mode (DSP_A, 16 bit width) is supported just fine. But the
current code always uses 4-byte DMA for stereo and 2-byte DMA for
mono. It operates under the assumption that both 16-bit stereo
channels are transmitted in one 32-bit frame.
If I send two 16-bit frames per sample, the DMA shovels 4 bytes into
the FIFO twice, and I'm losing half the data.

>> Daniel's board needs very strange settings because network mode
>> doesn't work, so I guess he can't use 2-byte DMA transfers. Is that
>> correct?
>
> It's not that strange actually. All it needs to have is 64 bitclk cycles
> per frame with 32 bits of data per frame. See the CS4270 datasheet[1],
> Figure 10 on page 19. At least when operating in master mode, the codec
> needs to have bitclk = 64fs.

IMHO, the physical DAI format isn't strange, but SSP parameters you
can use to achieve that are.

>> If we can't find a way to have all machines use the mono DMA params,
>> there has to be some kind of interface to set the width of the data in
>> the FIFO independently from the Alsa format. How should that interface
>> look like?
>
> IMO, we need to pass three informations to the DAIs:
>
> 1) The hardware interface format (I2S/DSP/LEFT_J/RIGHT_J/...)
> 2) The pyhsical frame width (ie, how many data is actually used per
>   frame, which then also tells us how to use the FIFOs)
> 3) The data alignment (ie, how data is sent within the frames)
>
> As I see these informations beloning together, I would have said (3)
> should be defined in a similar way than (1) and (2) and hence find a
> nice place to live in the dai_fmt integer bits, as we can call the CPU's
> set_dai_fmt() function from the board file.

Would work for me.

> Mark says he'd rather like me to use/abuse the set_clk_div() interface
> for that but IMO that's an evil hack. The next CPU would need a similar
> thing to be used with this codec, so there should be a clean way to
> achive that.

And it can't be used to set the DMA/FIFO width.

> So - no worries. Whatever way we choose, we'll avoid regressions for the
> Magician board, but I need your help in testing this as I don't have
> anything else than our own hardware :)

I'm not worried about regressions. Magician board support isn't even
submitted yet.
I need a clean way to do 2) first. I just kind of hoped it could make
it into 2.6.30 :)

regards
Philipp