On 12/12/2014 09:07 PM, Kevin Hilman wrote:
Hi Tero,
Tero Kristo <[email protected]> writes:
The new usage of determine_rate and set_rate_and_parent calls for
OMAP DPLLs assumes the DPLLs must have two parents defined, even
if it is the same clock. Legacy clock data did not fullfill this
requirement and caused a boot crash. Fixed by adding the missing
parent information to the DPLL clocks.
Signed-off-by: Tero Kristo <[email protected]>
Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...")
Cc: Kevin Hilman <[email protected]>
I tested this on linux-next (next-20141210, same version where I found
the bug) and this doesn't fix the boot problem.
BTW, in testing this, I noticed that the OMAP clock code is still
spitting out compile warnings[1]. These should cleaned up too.
Did you apply both of my patches from this set?
I think the DPLL fix might be required also to get this working properly
on OMAP3 legacy.
-Tero
Kevin
[1]
../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: initialization from
incompatible pointer type [enabled by default]
../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: (near initialization
for 'dpll1_ck_ops.determine_rate') [enabled by default]
../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: initialization from
incompatible pointer type [enabled by default]
../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: (near initialization
for 'dpll4_ck_ops.determine_rate') [enabled by default]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
