Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 02/28/2014 08:33 PM, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux