simple-audio-card and external dynamic clock

simple-audio-card and external dynamic clock

[Emmanuel Fusté]

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 ?
- or something else ?

Than you.
Emmanuel.

simple-audio-card and external dynamic clock

[Emmanuel Fusté]

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

Emmanuel.

Re: simple-audio-card and external dynamic clock

[Peter Ujfalusi]

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.

-- 
Péter

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

Re: simple-audio-card and external dynamic clock

[Peter Ujfalusi]

On 04/05/16 22:10, Emmanuel Fusté wrote:
> 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 ;)

Yeah, and one thing came to my mind: daVinci architecture does not use CCF...

> 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 would pick this series:
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-February/104316.html
for now to get things working till we can figure out the CCF way of
configuring the clocks inside McASP.
This is what we are doing with TI internal releases used by our customers.

> I will be around to see any  future progress on the mcasp driver front and
> will try to help as I could if possible.

I will try to prioritize the CCF work as I will have at least one board
upstream where the clock selection is needed for audio.

> Thank you for your detailed and very instructive answer.

I'll CC you also when I have something to test.

-- 
Péter