Re: [PATCH] ARM: dts: Update arch timer node with clock frequency

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

 




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 <mark.rutland@xxxxxxx> wrote:
>> [adding lakml]
>>
>> On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote:
>>> 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
>>
>> 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...

--
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