Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1335222 > unrolled thread

Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system  clocks by ID Peter Ujfalusi <peter.ujfalusi@ti.com> - 2016-02-16 10:50 +0100
    Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID Michael Turquette <mturquette@baylibre.com> - 2016-02-16 20:30 +0100
      Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system  clocks by ID Peter Ujfalusi <peter.ujfalusi@ti.com> - 2016-02-17 09:20 +0100
        Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system  clocks by ID Mark Brown <broonie@kernel.org> - 2016-02-17 13:10 +0100
          Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system  clocks by ID Peter Ujfalusi <peter.ujfalusi@ti.com> - 2016-02-17 21:00 +0100
      Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system  clocks by ID Mark Brown <broonie@kernel.org> - 2016-02-17 12:40 +0100
      Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting  system clocks by ID Ricard Wanderlof <ricard.wanderlof@axis.com> - 2016-02-17 15:20 +0100
        Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for  selecting system clocks by ID Mark Brown <broonie@kernel.org> - 2016-02-22 04:30 +0100
    Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system  clocks by ID Mark Brown <broonie@kernel.org> - 2016-02-19 01:30 +0100

#1335222 — Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

On 02/15/2016 05:26 PM, Mark Brown wrote:
> On Mon, Feb 15, 2016 at 04:11:35PM +0200, Peter Ujfalusi wrote:
> 
>> Most CPU and codec drivers can select their system clock from different
>> sources. They rely on snd_soc_dai_set_sysclk(x, sysclk_id, x, x) to do so.
>> Add support for selecting which clock need to be selected along with the
>> rate.
> 
> Rather than adding new bindings for the ASoC specific clocking APIs it
> seems better to use the standard clock API bindings and transition
> drivers to use that.  In the past the clock API didn't have DT bindings
> so wehad to do our own thing but I think now that's no longer the case?

McASP is relatively simple regarding to clocking and it is only problematic in
case when it is master. When it is slave it is going to use the BCLK and FS
coming from outside for clocking the data.

The driver currently only supports symmetric clocking, meaning we only use the
TX clock path (RX is using the TX clocks).
To generate the bit clock we have something like this:

[mcaspA_auxclkx_div]->
		    [mcaspA_hclkx_mux] -> [mcaspA_hclkx_div] -> [mcaspA_bclkx]
[mcaspA_ahclkx_in]  ->

If [mcaspA_auxclkx_div] is selected in [mcaspA_hclkx_mux], then:
[mcaspA_hclkx_mux] -> [mcaspA_ahclkx_out]
the HCLKX clock can be sent to mcaspA_ahclkx_out, as output from the SoC.

mcaspA is mcasp0...number of MCASP in the SoC.

We would need three (or two if we decide to not represent the mcaspA_bclkx)
simple clock node, two dividers and one mux.

We could have binding for this regarding to clocks:

/* McASP clk IDs */
#define MCASP_AUXCLKX_DIV	0
#define MCASP_AHCLKX_IN		1
#define MCASP_HCLKX_MUX		2
#define MCASP_HCLKX_DIV		3
#define MCASP_AHCLKX_OUT	4
#define MCASP_BCLK		5

/* dtsi file */
mcasp3: mcasp@48468000 {
	compatible = "ti,dra7-mcasp-audio";
	#clock-cells = <1>;
	clocks = <&mcasp3_aux_gfclk_mux>, <&mcasp3_ahclkx_mux>;
	clock-names = "fck", "ahclkx";
	assigned-clocks = <&mcasp3 MCASP_AHCLKX_IN>,
			  <&mcasp3 MCASP_AUXCLKX_DIV>;
	assigned-clock-parents = <&mcasp3_ahclkx_mux>,
				 <&mcasp3_aux_gfclk_mux>;
};

/* board dts */
&mcasp3 {
	assigned-clocks = <&mcasp3 MCASP_AHCLKX_IN>,
			  <&mcasp3 MCASP_AUXCLKX_DIV>,
			  <&mcasp3_ahclkx_mux>,
			  <&mcasp3 MCASP_HCLKX_MUX>;
	assigned-clock-parents = <&mcasp3_ahclkx_mux>,
				 <&mcasp3_aux_gfclk_mux>,
				 <&atl_clkin2_ck>,
				 <&mcasp3 MCASP_AHCLKX_IN>;
};

With this one we can set up the clock tree via clk bindings. Not sure how this
will work if audio including McASP is built as module?

There are couple of important questions regarding to this: if the
MCASP_HCLKX_DIV is not explicitly set the McASP driver will configure it based
on the need for the starting stream (rate, bits, etc), but in some case we
need to have different calculation since we want to have more bclk then it is
needed for the audio data (bclk-fck ratio).

The clock tree within the McASP need to be built up inside of the code, can
not be done via DT.

As for codecs, tlv320aic3106 is also pretty simple device from the outside, it
can receive it's reference clock via:
MCLK pin, GPIO2 pin or it can use the BCLK from the bus. Based on the incoming
frequency it can use it directly or it needs to use the internal PLL to
generate the cocks.
It can output generated clock via GPIO1

I don't think it will bring any clarity or features we miss right now if we
try to move CPU and codec drivers to clk API. IMHO.

-- 
Péter

[toc] | [next] | [standalone]

#1335747 — Re: [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

Quoting Mark Brown (2016-02-16 05:42:33)
> On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote:
> 
> > As for codecs, tlv320aic3106 is also pretty simple device from the outside, it
> > can receive it's reference clock via:
> > MCLK pin, GPIO2 pin or it can use the BCLK from the bus. Based on the incoming
> > frequency it can use it directly or it needs to use the internal PLL to
> > generate the cocks.
> > It can output generated clock via GPIO1
> 
> That already sounds like there is room for configuration and hooking
> into a wider clock tree - we've got three different source options and
> an output plus a PLL that can presumably take in non-audio rates.

+1

It is quite easy for existing drivers to become clock providers. Please
see struct isp_xclk in:

drivers/media/platform/omap3isp/isp.h
drivers/media/platform/omap3isp/isp.c

CCF is intentionally designed as a library, meaning that you don't need
to create a new struct device to register clocks. Feel free to BYOD
(bring your own device).

Then your IP block clocks (McASP in this case) can hook into the
system-wide clock tree (e.g. where some of the parent clocks come from).

> 
> > I don't think it will bring any clarity or features we miss right now if we
> > try to move CPU and codec drivers to clk API. IMHO.

CPU drivers? Peter, you wrote the CCF clock provider driver for DRA7
ATL, so I'm not sure what you mean here.

> 
> You happen to be looking at a particularly simple system but things do
> scale up and there's not a clear cutoff point which would allow us to
> make a clear distinction between things that might get used in a simple
> system and things that might need something more complex.  This seems
> particularly important when we're adding things to simple-card, we want
> it to be usable with as many different devices as possible.

The original patches didn't hit my inbox, only the last two replies. Can
someone fill me in on the DT side of this discussion? Why are DT
bindings needed here? Are other devices besides McASP consuming the
clocks provided by McASP?

DT can also be a good candidate for doing per-board (or per-use case)
clock configuration via the assigned-clocks, assigned-clock-rates, and
assigned-clock-parents properties.

Regards,
Mike

[toc] | [prev] | [next] | [standalone]

#1336125

Mike,

On 02/16/2016 09:13 PM, Michael Turquette wrote:
> Quoting Mark Brown (2016-02-16 05:42:33)
>> On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote:
>>
>>> As for codecs, tlv320aic3106 is also pretty simple device from the outside, it
>>> can receive it's reference clock via:
>>> MCLK pin, GPIO2 pin or it can use the BCLK from the bus. Based on the incoming
>>> frequency it can use it directly or it needs to use the internal PLL to
>>> generate the cocks.
>>> It can output generated clock via GPIO1
>>
>> That already sounds like there is room for configuration and hooking
>> into a wider clock tree - we've got three different source options and
>> an output plus a PLL that can presumably take in non-audio rates.
> 
> +1
> 
> It is quite easy for existing drivers to become clock providers. Please
> see struct isp_xclk in:
> 
> drivers/media/platform/omap3isp/isp.h
> drivers/media/platform/omap3isp/isp.c
> 
> CCF is intentionally designed as a library, meaning that you don't need
> to create a new struct device to register clocks. Feel free to BYOD
> (bring your own device).

I have already started to look around what I would need for at least McASP and
tlv320aic3x drivers (the most common combination).
I did not know that omap3isp has CCF provider implementation.

> Then your IP block clocks (McASP in this case) can hook into the
> system-wide clock tree (e.g. where some of the parent clocks come from).
>>
>>> I don't think it will bring any clarity or features we miss right now if we
>>> try to move CPU and codec drivers to clk API. IMHO.
> 
> CPU drivers? Peter, you wrote the CCF clock provider driver for DRA7
> ATL, so I'm not sure what you mean here.

also the clk-twl6040, which is not in use upstream yet.
The ATL is providing the clocks to be used as master clock in McASP and
external components (audio codec).
In ASoC the CPU driver means the CPU DAI (Digital Audio Interface) driver,
like the McASP, McBSP, DMIC, McPDM in TI parts.
In order them to generate the needed clocks on the bus they have internal
clock selection, divider(s). From the SoC point of view these are not really
important, but McASP can also output high speed reference clock to outside so
the codec for example can use the same reference, reducing jitter.

>> You happen to be looking at a particularly simple system but things do
>> scale up and there's not a clear cutoff point which would allow us to
>> make a clear distinction between things that might get used in a simple
>> system and things that might need something more complex.  This seems
>> particularly important when we're adding things to simple-card, we want
>> it to be usable with as many different devices as possible.
> 
> The original patches didn't hit my inbox, only the last two replies. Can
> someone fill me in on the DT side of this discussion?

the original patch:
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-February/104320.html

> Why are DT bindings needed here?

ASoC have an API to configure the DAI system clock:
snd_soc_dai_set_sysclk(dai, sysclk_id, sysclk, sysclk_dir);

The sysclk_id is to select among the possible clock sources, sysclk is the
rate of the clock and sysclk_dir is to tell the DAI driver if the given clock
should be input or output.
McASP (and McBSP also) can select between two master clock source. aic3106 can
select between 3 reference clocks.
Unfortunately the simple-card was hardwired to only handle DAIs which have no
master clock selection. We have added additional properties to simple-card so
it will be possible to select clocks and directions.
With this change we don't need to write custom machine drivers for setup not
using sysclk_id == 0.
I do think this is reasonable change by itself.

> Are other devices besides McASP consuming the clocks provided by McASP?

Yes, it can output the same reference clock it is using to external pin, but
it can do that only if it is set to generate the audio clocks on the bus.

> DT can also be a good candidate for doing per-board (or per-use case)
> clock configuration via the assigned-clocks, assigned-clock-rates, and
> assigned-clock-parents properties.

Yes, if the DAI driver implements it's clock tree with CCF internally and with
the assigned-clock* properties we will not need snd_soc_dai_set_sysclk() and
we don't need simple-card to know anything about the clocking of the
components. All of this can be done in the board's DTS file with standard CCF
bindings.

Mark: after thinking over how this should work I can see that it can bring
benefits for the DAI/codec drivers. They need to do things differently, but it
is just implementation question.
However I do think that the current simple-card is flawed regarding to clock
selection and the change Jyri and me are proposing is reasonable.
But if we have the CCF providers popping up in DAI/codec drivers the use of
clock configuration via simple-card not going to be needed. But right know it
is needed.

-- 
Péter

[toc] | [prev] | [next] | [standalone]

#1336305

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 17, 2016 at 10:13:35AM +0200, Peter Ujfalusi wrote:

> With this change we don't need to write custom machine drivers for setup not
> using sysclk_id == 0.
> I do think this is reasonable change by itself.

> However I do think that the current simple-card is flawed regarding to clock
> selection and the change Jyri and me are proposing is reasonable.

But you define a new ABI to specify it in the process, I'd rather fix
the flaws by using the common clock ABI than extend any device stuff.
If it didn't define a new ABI I'd probably not worry about it but one of
the issues we have with DT is that we do end up making ABIs every time
we put something in DT.

[toc] | [prev] | [next] | [standalone]

#1336713

On 02/17/2016 02:07 PM, Mark Brown wrote:
> On Wed, Feb 17, 2016 at 10:13:35AM +0200, Peter Ujfalusi wrote:
> 
>> With this change we don't need to write custom machine drivers for setup not
>> using sysclk_id == 0.
>> I do think this is reasonable change by itself.
> 
>> However I do think that the current simple-card is flawed regarding to clock
>> selection and the change Jyri and me are proposing is reasonable.
> 
> But you define a new ABI to specify it in the process, I'd rather fix
> the flaws by using the common clock ABI than extend any device stuff.
> If it didn't define a new ABI I'd probably not worry about it but one of
> the issues we have with DT is that we do end up making ABIs every time
> we put something in DT.

I understand. This should have been supported by simple-card since the
beginning. When we tried to move all boards to use simple-card, we hit the
wall by not being able to select and configure other sysclk_id than 0.
I don't want to create yet another simple card which handles only sysclk_id 1 ;)
On the other hand this ABI is backwards compatible since if it is missing it
will default to the configuration we right now have regarding to sysclk_dir
and sysclk_id.

I will look at the CCF implementation for McASP first then for aic3x.

-- 
Péter

[toc] | [prev] | [next] | [standalone]

#1336273

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 16, 2016 at 11:13:46AM -0800, Michael Turquette wrote:
> Quoting Mark Brown (2016-02-16 05:42:33)
> > On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote:

> > > I don't think it will bring any clarity or features we miss right now if we
> > > try to move CPU and codec drivers to clk API. IMHO.

> CPU drivers? Peter, you wrote the CCF clock provider driver for DRA7
> ATL, so I'm not sure what you mean here.

In this case he's referring to the drivers for the audio IP blocks
inside the SoC.

[toc] | [prev] | [next] | [standalone]

#1336471 — Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

Quoting Mark Brown (2016-02-16 05:42:33)
> On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote:
> 
> > As for codecs, tlv320aic3106 is also pretty simple device from the outside, it
> > can receive it's reference clock via:
> > MCLK pin, GPIO2 pin or it can use the BCLK from the bus. Based on the incoming
> > frequency it can use it directly or it needs to use the internal PLL to
> > generate the cocks.
> > It can output generated clock via GPIO1
> 
> That already sounds like there is room for configuration and hooking
> into a wider clock tree - we've got three different source options and
> an output plus a PLL that can presumably take in non-audio rates.

It makes sense to use an already existing clock framework, but I'm 
wondering, how do we model the clock select function? Using a clock mux? 
Somewhere, somehow, something needs to look at the setup and decide which 
pin on the codec should be the clock source (e.g. MCLK, GPIO2, or BCLK in 
the case of the tlv320aic3106).

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

[toc] | [prev] | [next] | [standalone]

#1339113 — Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 17, 2016 at 03:18:57PM +0100, Ricard Wanderlof wrote:

> It makes sense to use an already existing clock framework, but I'm 
> wondering, how do we model the clock select function? Using a clock mux? 

Yes, that looks like a mux to me.

[toc] | [prev] | [next] | [standalone]

#1337806

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote:

> As for codecs, tlv320aic3106 is also pretty simple device from the outside, it
> can receive it's reference clock via:
> MCLK pin, GPIO2 pin or it can use the BCLK from the bus. Based on the incoming
> frequency it can use it directly or it needs to use the internal PLL to
> generate the cocks.
> It can output generated clock via GPIO1

That already sounds like there is room for configuration and hooking
into a wider clock tree - we've got three different source options and
an output plus a PLL that can presumably take in non-audio rates.

> I don't think it will bring any clarity or features we miss right now if we
> try to move CPU and codec drivers to clk API. IMHO.

You happen to be looking at a particularly simple system but things do
scale up and there's not a clear cutoff point which would allow us to
make a clear distinction between things that might get used in a simple
system and things that might need something more complex.  This seems
particularly important when we're adding things to simple-card, we want
it to be usable with as many different devices as possible.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web