* Tero Kristo <t-kristo@xxxxxx> [160316 07:38]: > On 03/16/2016 04:33 PM, Tony Lindgren wrote: > >* Tero Kristo <t-kristo@xxxxxx> [160315 23:27]: > >>On 03/16/2016 04:44 AM, Robert Nelson wrote: > >>>On Tue, Mar 15, 2016 at 7:40 PM, Ladislav Michl <ladis@xxxxxxxxxxxxxx> wrote: > >>>>On Tue, Mar 15, 2016 at 08:25:06AM +0000, Richard Watts wrote: > >>>>>[snip] > >>>>>>Yes, I think we should add a top-level ops for dpll5, that would > >>>>>>determine if table dividers shall be used first, if not, then just call > >>>>>>the generic implementation. > >>>> > >>>>Just tried that and it looks reasonable. Will send patch after cleanup. > >>>> > >>>>>>I would also add a new compatible string for the purpose, this means the > >>>>>>users must update both kernel + DTB but I believe any OMAPx customers > >>>>>>are doing this anyway. > >>>>>> > >>>> > >>>>Should DTB also carry fixup table? > >>> > >>>It really should be an optional flag that we can enable on a board by > >>>board basis.. > >> > >>I am fine with just changing the compatible string for DPLL5 to a new one. > >> > >>Tony, any comment on this? > > > >I guess I don't quite follow, do you just mean adding a new compatible > >for 36xx? > > > >Can we keep this workaround always enabled for 36xx or does it have > >some side effects? > > DPLL5 entry of omap36xx should have a workaround, but for detection purposes > we either need: > > - A new compatible string in DT for the DPLL5 itself (currently it uses > ti,omap3-dpll-clock, so change this to something like ti,omap3-dpll5-clock) > - Or make a strcmp against the clock name in the kernel during boot, and > register different clkops for it. I guess up to you. If there's a need to disable the workaround on some boards then the compatible string addition makes sense. Regards, Tony -- 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
