[PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode

[Tero Kristo]

On 12/12/2014 09:07 PM, Kevin Hilman wrote:
> Hi Tero,
>
> Tero Kristo <t-kristo at ti.com> 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 <t-kristo at ti.com>
>> Fixes: 2e1a7b014f ("ARM: OMAP3+: DPLL: use determine_rate() and...")
>> Cc: Kevin Hilman <khilman at kernel.org>
>
> 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]
>