[alsa-devel] simple-audio-card and external dynamic clock

[Emmanuel Fusté]

Le 05/04/2016 12:49, Peter Ujfalusi a écrit :
> On 04/05/16 00:56, Emmanuel Fusté wrote:
>> Le 24/03/2016 22:51, Emmanuel Fusté a écrit :
>>> Hello,
>>>
>>> I m very new to ASoC (and not native english speaker) so be indulgent ;-)
>>> The context  : am335x-boneblack.
>>> I want to drive simple I2S targets. With the ongoing developments, and
>>> recent patches posted here, this is a very simple job for the
>>> simple-audio-card machine driver even with fixed external master clock.
>>> I want to go further using a programmable external clock (si570) which is
>>> not very complicated thanks to the CCF.
>>> But now I want to use the dynamic nature of this external master clock
>>> (through CCF) to be able to generate 44.1khz AND 48 multiples of fs which is
>>> not natively possible on the BBB because of integer fs scaling only and/or
>>> no dedicated audio PLL.
>>> I know that the same could be achieved on the BBB with switching between
>>> internal clock (24mhz) and external one (24.576mhz) gated by GPIO1_27, but
>>> this is another story.
>>>
>>> Which direction is the right one ?
>>> - dedicated machine driver ?
>>> - or something more generic / reusable implemented in the simple-audio-card
>>> drivers through helpers routines ?
> simple card does not support dynamic switching between clocks and it does not
> have support for clock changing runtime - the rate is checked when the driver
> probes.
>
>>> - or something else ?
>>>
>> Ok,
>>
>> I did a little bit of homework and mailing list digging.
>> If I understand the "problem"  correctly, here we are:
>> - ASoc is now completely CCF aware
> whatever this means ;)
>
>> - McASP driver is not, but it is not a real problem in most use cases when we
>> omit the possibilities offered by AHCLKX or if we use a static AHCLKX
>> configuration.
> True that the McASP driver is not using the CCF API to configure it's internal
> clocking setup but I think none of the DAI drivers are doing it right now. The
> external clocks are configured with CCF bindings.
> It is a bit more complicated thing to implement as it sounds as:
> - we need to make sure that the current way of clock configuration remains
> operational.
> - how the clock tree design will look like, what names are we going to use,
> how to craft out the DT bindings.
> - not small amount of code to add the clock provider functionality for inputs,
> outputs, gates, muxes and dividers in McASP driver.
> - how legacy (non DT boot will be affected)? Most of daVinci is not going to
> be converted to DT :(
> - How this is going to be integrated in a system level clock tree?
> A simple thing like when McASP is outputing a reference clock via AHCLKX pin
> and McASP is built as module. In DT we need to describe the McASP clock tree
> and it's integration into the system clock tree, right? So let's say AUXCLK is
> used as reference clock for McASP and it is sending a clock out via it's
> AHCLKX pin to an external codec. When the kernel boots the clock tree needs to
> be built up and based on the DT description a clock path is going through a
> module which does not exist in the kernel yet (it is a module, loaded later)
> so the CCF can not check these clocks as the clocks are not yet registered.
> Probably building McASP in the kernel can solve this.
>
> and there are other 'small' issues we are not aware of right now.
>
>> My use case needs two different level of ccf work on the McASP driver:
>> First, a "basic" conversion to CCF to be able to use simple-audio-card,
>> choosing the used clock (AHCLKX or AUXCLK) with the
>> assigned-clocks/assigned-clock-parents standard DT properties as it seems to
>> be the way to go (February discussion about selecting system clocks by ID ).
> Yes, since the ID based fix is not accepted, we should get CCF to do the same
> thing. That way we can stop using any clock related support from the simple card.
>
>> Next, a more advanced support for the external AHCLKX case, which could be
>> driven by a programmable clock (clk_set_rate available). Most use cases would
>> be covered by a 24mhz and 24.576mhz AHCLKX and the correct divisors sets as
>> need by the McASP driver.
>> With more complexity, arbitrary I2S rate (with arbitrary AHCLKX) or better
>> accuracy ( dynamic switching between internal AUXCLK @24mhz and external fixed
>> AHCLKX @24.576mhz) could be achieved.
>> And no need for a machine driver, simple-audio-card would be sufficient.
>>
>> Right ?
> I have not checked it, but it might be possible that with CCF we can do the
> divider change up in the clock tree but switching between reference clocks is
> a bit more problematic.
>
Ok, things are not simple ;)
So for an "advanced" use of the McASP IP on Linux, specific machine 
driver and perhaps a little bit of davinci-mcasp modifications are still 
required.
I will be around to see any  future progress on the mcasp driver front 
and will try to help as I could if possible.
Thank you for your detailed and very instructive answer.

Emmanuel.