[lkml]   [2016]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 9/9] clocksource: import ARC timer driver
Hi Daniel,

On 11/01/2016 01:42 PM, Daniel Lezcano wrote:
> Please stay consistent with the rest of the Kconfig.
> config ARC_TIMER_RTC
> bool "64-bit cycle counter in HS38 cores" if COMPILE_TEST
> select CLKSRC_OF
> help
> This counter provides 64-bit resolution vs. the 32-bit TIMER1.
> It is implemented inside the core thus can't be used in SMP systems.
> bool "64-bit cycle counter in ARConnect block in HS38x cores" if COMPILE_TEST
> select CLKSRC_OF
> help
> This counter can be used as clocksource in SMP HS38 SoCs.
> It sits outside the core thus can be used in SMP systems

Yes I did so already :-) Although I also added a default y if ARC to both, but as
you say that is better done in ARC Kconfig.

> Then in the ARC's Kconfig you select ARC_TIMER_RTC or ARC_TIMER_GFRC depending
> it is SMP or not.
> One question:
> Why ARC_TIMER_RTC can't be used in a SMP system ? Doesn't have each core its
> own clocksource ? It seems you are assuming a clocksource can be used on SMP
> only if the clocksource is unique and shared across the cores.

Thats what I thought so far. Thing is, the individual core's counters could get
out of sync, simply because non masters cores were halted to begin with and came
up at different points in real time. so a gtod might return different value
depending on what core it landed on. Does clocksource also does ticks broadcasts
and such to keep things in sync ?

Because of the git mv you, diff didn't include bulk of driver code which would
make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ?


 \ /
  Last update: 2016-11-01 21:57    [W:0.146 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site