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.
-Tero
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
