regression: Clock changes in next-20141205 break at least omap4

[Paul Walmsley]

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