On 16/03/16 14:42, Tony Lindgren wrote:
* 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.
Hi,
I can't see a need to disable the workaround - if you are messing about with
the PLL settings on DPLL5, you will have your own patch in this area anyway.
However, there are several possible options for a workaround if you are
using a 13MHz or 26MHz xtal - see
<http://www.ti.com/lit/er/sprz319f/sprz319f.pdf> PDF p111. It might perhaps
be civilised to give the user the option, since which is appropriate to your
board is a matter of board characterisation. I see no shame in simply
exposing something like:
ti,omap3-dpll5-clock = < 443 5 8 >
I have a Beagle xM or two here I can send out to anyone in need - throw me an
address.
OMAP3530 should also suffer from this problem, but it is not listed in the
errata sheet.
Other than that, the only devices I know of that have this combination of
DPLL and HSUSB are OMAP3630 and DM3730 - if it's important, I can try and
find the appropriate people in TI?
Richard.
--
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
