[alsa-devel] [PATCH 1/4] ASoC: pxa-ssp: enhance I2S and add Left_J support

[pHilipp Zabel]

On Mon, Jun 8, 2009 at 2:40 PM, Mark
Brown<broonie at opensource.wolfsonmicro.com> wrote:
> On Mon, Jun 08, 2009 at 02:12:03PM +0200, pHilipp Zabel wrote:
>> On Sat, Jun 6, 2009 at 10:12 PM, Mark
>> Brown<broonie at opensource.wolfsonmicro.com> wrote:
>
> OOI which MUA are you using?  I've noticed several people with this very
> odd word wrapping the past day.

This mail was sent with the Google Mail web interface.

>> > of in tree users it'd cause little disruption. ?A set_sample_width()
>> > operation could also be added.
>
>> set_sample_width or set_frame_width?
>
> I'm inclined to go with sample here since it seems harder for the
> machine drivers to get wrong but I've not really thought it through yet?

I thought sample width is determined by the snd_pcm_hw_params. But
maybe I'm mixing up alsa sample width vs sample width on the wire?
I'm leaning towards set_frame_width because that's directly what I
want to do: override pxa_ssp_hw_params' standard decision to use
32-bit frames for S16_LE stereo and set 16-bit frames instead.

>> 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.
>
> OTOH I don't really see much difference between the two cases - it's
> just an extra couple of parameters on the end of the call.

Technically there isn't. It just seems much more obvious to me to
write something like:
    /* nonstandard: 16-bit frames, even for 2x 16-bit stereo */
    if (params_format(params) == ..._S16_LE)
        set_frame_size(16);
in the machine driver instead of:
    /* nonstandard: 16-bit frames, even for 2x 16-bit stereo
     * pxa_ssp_hw_params will check for TTSA==1
     * and then set the frame size accordingly
     */
    set_tdm_slot(1,1);
especially as I don't really need network mode at all.

> That said,
> it'd be much nicer if the driver were able to just do the right thing
> for DSP mode unless explicitly configured, there's not the issue you
> have with I2S where extra clocks would change the offset of the second
> channel within a stereo frame so it's much easier.

Yes. Only for strange nonstandard setups like a flip-flop in the LRCLK
line even DSP mode has to be told that we need two frame clock pulses
per stereo sample.

regards
Philipp