On Mon, Jun 08, 2009 at 10:13:25PM +0800, Eric Miao wrote:
On Mon, Jun 8, 2009 at 8:12 PM, pHilipp Zabelphilipp.zabel@gmail.com wrote:
Agreed. Also, if I had to use this to configure magician with DSP_A (right now it says I2S and LEFT_J only, but why limit it to that?), I'd need an additional PXA_SSP_FRM_16FS.
That shouldn't be a problem - it can just be added.
That won't scale in a bitmask - as you get more and more slots in use on a TDM system more and more slots are going to need to extend the range of values you can set in a bitmask. Consider what happens when people start hanging 5.1 CODECs off TDM buses with single data lines, for example.
sample width parameter to set_tdm_slot() - given the very small number of in tree users it'd cause little disruption. A set_sample_width() operation could also be added.
Well, the real problem is that it's quite difficult to abstract all the different formats into a single structure. I'd prefer to have something specific at the begining.
I don't see much difference between any of the proposals here (or any problem with format-specificness) - my main thing here is to pull the frame width configuration out of the DAI format.
set_sample_width or set_frame_width? I'd prefer a separate operation over a parameter to set_tdm_slot because in my setup I just need to force the (SSP) frame width to 16 bits. Enabling network mode and calling set_tdm_slot(..,1,1) wouldn't be necessary at all, then.
As said, if we can invent something like a single structure making all formats happy, it will be good. However, before that's possible, I'd really prefer less API for the formats being further introduced, so we go no further from that goal.
Well, if we want to avoid introducing a new API at all then the PXA SSP driver is going to need to figure out the bit clock rate automatically from the TDM and sample size configuration - if it needs to be explicitly specified then it's a new API and once we introduce one way of doing this it'll probably stick.
TDM really needs some sort of frame/sample width configuration to work well so I think we're better off adding a standard API now.