On 02/28/2014 08:33 PM, Tony Lindgren wrote:
* Tero Kristo <[email protected]> [140228 10:21]:
Hmm, some clock node is broken, might be missing a name or parent
name for some reason. Can you try to boot with DEBUG enabled so you
get pr_debug:s out and see which clock is being initialized during
the crash?
...
[ 0.000000] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing:
core_d18_ck
[ 0.000000] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing:
vlynq_mux_fck
[ 0.000000] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing:
vlynq_fck
[ 0.000000] Unable to handle kernel NULL pointer dereference at virtual
address 00000000
...
We really should be registering the clocks lazily as needed BTW. That
leaves out the dependency to DEBUG_LL for seeing any kind of decent
error messages during the booting.
Regards,
Tony
Hey Tony,
Can you retry with the branch? I just pushed one patch there, seems the
parents for the vlynq_mux_fck were somewhat broken (there are holes in
the valid mux values list, which hasn't happened with any other
mux-clock so far.)
If this works, I will rework the series a bit and send v2 out.
Alternatively I need to add extra debug info.
-Tero
--
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
