Re: [PATCH] ARM: omap2: am437x: rollback to use omap3_gptimer_timer_init()

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

 




On Wednesday 13 April 2016 12:12 AM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@xxxxxx> [160412 11:31]:
>> On 04/12/2016 07:04 PM, Tony Lindgren wrote:
>>> * Grygorii Strashko <grygorii.strashko@xxxxxx> [160412 03:44]:
>>>> The commit 55ee7017ee31 ("arm: omap2: board-generic: use
>>>> omap4_local_timer_init for AM437x") unintentionally changes the
>>>> clocksource devices for AM437x from OMAP GP Timer to SyncTimer32K.
>>>>
>>>> Unfortunately, the SyncTimer32K is starving from frequency deviation
>>>> as mentioned in commit 5b5c01359152 ("ARM: OMAP2+: AM43x: Use gptimer
>>>> as clocksource") and, as reported by Franklin [1], even its monotonic
>>>> nature is under question (most probably there is a HW issue, but it's
>>>> still under investigation).
>>>>
>>>> Taking into account above facts It's reasonable to rollback to the use
>>>> of omap3_gptimer_timer_init().
>>>
>>> I thought only the ePOS EVM does not have the 32k clock available?
>>> Maybe this is the the old sync timer autocorrection drift issue?
>>>
>>
>> May be, as i mentioned in [1] it could be errata same as for Watchdog
>> Advisory 22 (or OMAP_TIMER_ERRATA_I103_I767).
>>
>> But as per commit 5b5c01359152 ("ARM: OMAP2+: AM43x: Use gptimer
>> as clocksource") there is no reason to use SyncTimer32K as
>> clocksource any way (not only on epos):
>>
>> commit 5b5c01359152f3ddaa1aa0e5d1141bc2b29ba2c5
>> Author: Rajendra Nayak <rnayak@xxxxxx>
>> Date:   Fri Feb 7 15:51:26 2014 +0530
>>
>>     ARM: OMAP2+: AM43x: Use gptimer as clocksource
>>     
>>     The SyncTimer in AM43x is clocked using the following two sources:
>>     1) An inaccuarte 32k clock (CLK_32KHZ) derived from PER DPLL, causing system
>>        time to go slowly (~10% deviation).
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't think this statement is right. If clock from PER DPLL is
inaccurate then all the IPs which uses PER DPLL are in danger. It is the
On-Chip 32K RC Osc clock that is not an accurate clock-source as per the
design/spec.

>>     2) external 32KHz RTC clock, which may not always be available on board like
>>        in the case of ePOS EVM

Also this 32KHz RTC clock is not enabled by default and is handled by RTC.

IMO, it is better to change the clock source of sync timer to
CLK_32KHz(like it is done in case of am43x-epos). Or do you have any
other reason to shift to gptimer?

Thanks and regards,
Lokesh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux