[alsa-devel] Remove clkdiv and pll setters from pxa dais

[Mark Brown]

On Wed, May 30, 2018 at 11:47:15AM +0200, Daniel Mack wrote:
> On Wednesday, May 30, 2018 11:24 AM, Mark Brown wrote:

> > I think it's copied from somewhere else probably, it looks like there's
> > a bit of code motion going on.  I bet it was just for I2S, keeping the
> > extra clock cycle for the initial rising edge in the frame but not
> > actually required.

> Hmm, okay. You happen to still have access to that board for regression
> tests?

No, I doubt anyone does - it was the PXA32x reference platform.  The
ones I'm aware of unfortunately got thrown out.

> > > So for both 22050 and 44100, the base frequency and all dividers are the
> > > same, which can't be right. I assume these rates have never been used. I'll
> > > ignore this and implement the table in the datasheet which should do the
> > > right thing. Philipp?

> > That looks buggy, yeah.  I doubt anyone ever used 22.05kHz.

> AFAIU, it's rather the 44.1 rate that looks wrong. But okay, we'll see.

That's definitely been tested...  perhaps the parent rate is set
incorrectly?

> > > What we need, however, is a way to describe whether the dai is mclk master
> > > or slave. Would we add a DT propery for that?

> > That might be sensible, though the MCLK isn't really part of the DAI.

> Well, the DAI may well be the producer of the MCLK. If there's only a
> master/slave mode to decide, we could set that property on the machine side

It might be the same physical block, but the MCLK could also come from
somewhere completely different and not even need to be in sync with the
rest of the clocks.

> as well, in the subnode of simple-card for instance (similar to
> 'bitclock-master' and 'frame-master'), but then the question is which
> callback to use for propagating that master/slave setting to the cpu dai. We
> will, however, need such a callback anyway for non-DT boards, as those won't
> go away anytime soon. Could we squeeze that into the SND_SOC_DAIFMT_ mask?
> Not sure which options would be acceptable.

DAIFMT feels like a push, like I say we'll need to handle clocks that
aren't aligned with the DAI as well.  Possibly either the existing
set_sysclk() operation or some new operation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20180530/1f9fe351/attachment.sig>