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

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

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