On Mon, Mar 9, 2009 at 4:36 PM, Daniel Mack daniel@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:
- The hardware interface format (I2S/DSP/LEFT_J/RIGHT_J/...)
- 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