Hi,
On Thu, May 1, 2014 at 7:15 AM, Mark Brown broonie@kernel.org wrote:
On Thu, May 01, 2014 at 04:59:08PM +0530, Tushar Behera wrote:
Okay, I will extend the existing clock driver to support XCLKOUT.
It may make more sense to add another clock driver for this clock depending on how things are done, I don't know.
Of the many parents of XCLKOUT, we need to set XXTI clock as the parent. Is it okay if we pass two clocks "mclk" (XCLKOUT) and "mclk_parent" (XXTI) to sound-card driver via DT and do the necessary reparenting during the sound-card driver probe call?
No, that's not OK at all, it won't allow for configuration of the system. This is what I was talking about when I was talking the clock framework extensions to allow the clock tree to be configured using DT, that would allow the settings to be put in DT.
Else, we can push that change to bootloader (to set the XCLKOUT mux register) and only enable/disable the clock in sound-card driver.
That's not going to work given that the existing bootloaders don't do this.
This is exactly the thing (expected clock parenting) we agreed could be put in the device tree I think. ...but I don't know that anyone proposed exactly how that would work.
NOTE: in existing ChromeOS this type of thing is done a tiny amount in https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.8/arch/arm/mach-exynos/mach-exynos5-dt.c. See apply_clock_muxing().
-Doug