[alsa-devel] ASoC: sun4i-i2s: Restricting the MCLK

[Thomas Niederprüm]

Am Donnerstag, den 04.08.2016, 10:45 +0800 schrieb Chen-Yu Tsai:
> Hi,
> 
> On Tue, Aug 2, 2016 at 11:05 PM, Thomas Niederprüm
> <niederp at physik.uni-kl.de> wrote:
> > I am using the new sun4i-i2s driver in linux-next to run a sta326 codec
> > via the pin header on a cubietruck (this involves some soldering as
> > described in [1]). The codec can only be configured as slave and needs
> > a master clock for its internal PLL. It is therefore great that, unlike
> > many other SOCs, the a20 provides a MCLK that can be used to sync the
> > codec. However, in my case there is a restriction imposed on the MCLK
> > by the codec. As stated in the datasheet [2], the master clock should
> > be at maximum 12.288 MHz/11.2896 MHz or otherwise the codec will not
> > work (confirmed by experiment!).
> > 
> > Since the mod clock of the a20's dai block is running at twice this
> > frequency, I need to assure that the MLCK divider is at least 2.
> > Actually it is rather straight forward to achieve this by changing the
> > breaking condition in the divider calculation, as shown by the
> > following one-line patch:
> > 
> > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> > index 687a8f8..8920844 100644
> > --- a/sound/soc/sunxi/sun4i-i2s.c
> > +++ b/sound/soc/sunxi/sun4i-i2s.c
> > @@ -206,7 +206,7 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s
> > *i2s,
> >                                                   clk_rate,
> >                                                   rate);
> > 
> > -               if ((bclk_div >= 0) && (mclk_div >= 0))
> > +               if ((bclk_div >= 0) && (mclk_div >= 1))
> >                         break;
> >         }
> > 
> > Of course, this is just a hack to fix my use case and I am wondering
> > what would be the best way to handle my corner case more generally? I
> > see one option in introducing a DT property mlck_mindiv, or similar,
> > that defaults to 1 and can be overwritten at the board level. I'm
> > willing to prepare a proper patch to tackle this problem but right now
> > I'm wondering if there a major objections to this approach or whether
> > there is any better solution to the problem.
> 
> I think the proper way would be to have sun4i-i2s support the .set_sysclk
> callback in .dai_ops. simple-card calls snd_soc_dai_set_sysclk if you
> have the "mclk-fs" property set in the DT.

Thanks for pointing this out. While this indeed seems to be the standard way to
obtain control over the mclk and it would probably solve my use case, I see a
problem in retaining the current behaviour of the driver if .set_sysclk is
implemented.
Right now the driver automatically chooses the correct frequency of the mod
clock (44.1kHz family or 48kHz family) and the dividers for the mclk and the
bclk depending on the requested samplerate. The upside of this that if you are
not interested in the mclk, the dai will probably just work for you. The
downside is that outside the driver you can not control the mclk.

If .set_sysclk is implemented, the driver has to respect the value set by the
function. Thus, the driver can only set the bclk divider according to the
predetermined mclk and the requested samplerate. This means that a part of the
logic that is currently in the sun4i-i2s driver has to be provided by the layer
above. In particular, this means to ensure that the mclk matches the frequency
family (44.1kHz or 48kHz) of the requested samplerate and that mclk = 2^n *
bclk. As you pointed out the "mclk-fs" property could (partially) do this in the
case of simple-card. This would ensure the correct frequency family for the mclk
but is not as sophisticated as the current solution in the driver when it comes
to choosing the optimal dividers. While the current solution always chooses the
highest possible oversampling, the "mclk-fs" solution fixes the oversampling.

The question now boils to whether we want to have external control on the mclk
or sophisticated automatic setting of it.

Best regards,
Thomas

> 
> Regards
> ChenYu
> 
> > 
> > Best regards,
> > 
> > Thomas
> > 
> > [1] https://hifiduino.wordpress.com/2014/03/07/cubieboard-for-audio/
> > [2] www.st.com/resource/en/datasheet/sta326.pdf
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel at alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel