Hi Sascha,
Thank you for the detailed comments.
On Fri, Aug 16, 2013 at 09:08:18AM +0200, Sascha Hauer wrote:
> Which of them the driver should use is configuration and thus normally
> should *not* be described in the devicetree. However, there may be no
> good way for the driver to know which clock to use in which case. There
> may be additional board requirements which are unknown to the driver. So
> in this case it might be valid to put the information which clock to use
> into the devicetree. But be aware that from the moment you put this
> information into the devicetree the driver is no longer free to chose
> the best clock, even if in future we find a good way to automatically
> guess the best clock. Do you have some insights in which case I would
> use which input clock? Is this only about which clock has the best
> suitable input frequency or is this also about synchronization of the
> audio signal with some other unit?
I understand. What I'm thinking now is to let the driver find the best
clock source for tx clock and a correspond divisor like this:
"tx<0-8>" Optional Tx clock source for spdif playback.
If absent, will use core clock.
The index from 0 to 8 is identical
to the clock source list described
in TxClk_Source bit of register STC.
Multiple clock source are allowed
for this tx clock source. The driver
will select one source from them for
each supported sample rate according
to the clock rates of these provided
clock sources.
Please review this idea.
And likewise for rx:
"rx<0-16>" Optional Rx clock source for spdif record.
If absent, will use core clock.
The index from 0 to 16 is identical
to the clock source list described
in ClkSrc_Sel bit of register SRPC.
If the index provided contains an
"if (DPLL Locked)" condition in its
source, the correspond clock phandle
should be the one in "else" path.
Only one rx clock source should be
defined here.
> Likewise with the rx-clksrc-lock property. what are the reasons to
> enable/disable this property? Is this an option you want to change
> during runtime? Is it an option you always want to use when it's
> available?
>
> If you don't know the answer then it might be a good option to just let
> the driver pick a sane default. If someone feels the need to change the
> default he probably comes up with a good reason why this is necessary.
> And then we can discuss again whether we want to have the option in the
> devicetree or some sysfs entry or whatever else.
The answer is, SPDIF controller actually doesn't care about which rx
clock source being chosen or even whether it has the "if (DPLL Locked)"
condition or not. It can measure its input clock sample rate by measuring
the signal source, from a spdif transmitter via coaxial cable or optical
line. However, the rxclk will be sent to other IP, ASRC on i.MX6Q for
example. Quoting from the i.MX6Q reference manual that "Both the Rx clock
and Tx clock are sent to the ASRC".
Therefore, if 'rx-clksrc-lock' is present, that means ASRC will get a
clock source indirectly from coaxial cable that contains the sample rate
information. So it can know what input sample rate is and do his own
procedure accordingly.
Thank you,
Nicolin Chen
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
