On Wed, 17 Dec 2014, Tero Kristo wrote: > The dual parent issue required by the DPLL code is caused by the introduction > of determine-rate / set-parent / set-rate-and-parent logic to OMAP DPPLs. I > took a short-cut here, making the assumption that every DPLL has both of these > clocks defined (which basically they do have, as every DPLL technically has > both reference and bypass clocks, but which can be the same clock => thus the > declaration itself is missing in some cases.) The clock data is modelled like > this for every other TI SoC (which use DT clock data), except for omap3 legacy > clock data, thus the patch to tweak the clock data itself. It would be much > harder to modify the clock code itself to take this into account, rather than > just add the missing parents to the clock data, thus the approach taken in the > patch. We can of course discuss whether it is okay to have DPLLs modelled as > they are right now. I think them as composite clocks containing mux, gate and > divider/multiplier logic within a single black box, we could split them up, > but I don't see much need for that. If it works, don't break it. > > Regarding the omap3 clock data patch, I have also just posted new patch set > that will move the omap3 legacy clock data under clock driver, until we figure > out what to finally do with this (use the DT clocks, or introduce loadable > clock data modules or something.) Thus, the data patch is kind of a temporary > one, or thats the intention at least, but I wouldn't call it a hack. It is > there to fix the issues introduced by the set-parent / set-rate-and-parent > logic, which was required by the changes to the core clock set-rate. OK, I understand now why the OMAP3 clock DT data takes two of the same clock - one is for the reference and one is for bypass. So I retract my earlier statement about it being a hack, and am fine with Tero's original patch. I suppose I should resuscitate the uImage booter for the OMAP3 boards here at least. I dropped those out of the testbed thinking that we'd switch over to DT-only fairly quickly; that turned out not to be the case. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
