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

[Daniel Mack]

On Wednesday, May 30, 2018 11:24 AM, Mark Brown wrote:
> On Wed, May 30, 2018 at 10:35:25AM +0200, Daniel Mack wrote:
> 
>> For instance, code for Zylonite does this:
> 
>>          /* Add 1 to the width for the leading clock cycle */
>>          pll_out = rate * (width + 1) * 8;
> 
>> The commit which introduced these lines dates back to 2009 and was done by
>> you, Mark. Can you remember what the reason for this was? I've never seen
>> sample frames with 17 bits :) This is a setup that we can't generically
>> describe through .hw_params() or .dai_fmt() in the cpu dai, correct?
> 
> 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?

>> 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.

>> 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 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.


Thanks,
Daniel