Hi, On Thu, May 1, 2014 at 7:15 AM, Mark Brown <broonie@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
