On 20/09/13 05:57, Yuvaraj Kumar wrote:
Resending it as it bounced from kernel mailing group
On Wed, Sep 18, 2013 at 3:53 PM, Mark Rutland [off-list ref] wrote:
quoted
[adding lakml]
On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote:
quoted
Without the "clock-frequency" property in arch timer node, could able
to see the below crash dump.
Why does this cause the below crash specifically? What is CNTFRQ reading
as?
Return value of arch_timer_get_cntfrq() is 0
quoted
Your firmware or bootloader should set CNTFRQ -- setting the
clock-frequency is a work-around for buggy firmware/bootloaders that
should be avoided as far as possible.
Why kernel should depend on bootloader/firmware to set CNTFRQ? Any
specific reasons?
Because the kernel can't set it if running non-secure. Only secure mode
can do this (see the ARM ARM for details).
Should'nt be indepenedent each other(kernel and bootloader/firmware)?
In my book, the firmware is responsible for setting up the platform in a
sane state. Leaving CNTFRQ in its UNKNOWN reset state is a bug, and your
firmware should program it on each CPU. Same goes for CNTVOFF, which
should be set to a common value (preferably zero).
M.
--
Jazz is not dead. It just smells funny...