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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
