[lkml]   [2013]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI
On Thu, Nov 7, 2013 at 8:27 PM, Daniel Lezcano
<> wrote:
> On 11/06/2013 12:05 PM, Magnus Damm wrote:
>> From: Magnus Damm <>
>> Add Kconfig entries for CMT, MTU2, TMU and STI to
>> drivers/clocksource/Kconfig. This will allow us to
>> get rid of duplicated entires in architecture code
>> such as arch/sh and arch/arm/mach-shmobile.
>> Signed-off-by: Magnus Damm <>
> Hi Magnus,
> we are preventing to have selectable timer from this Kconfig.
> You should select the timers from the arch Kconfig option.

Thanks for your reply. In the case of ARM multiplatform this sounds
like a good match, but I wonder what to do in the case of single
platform ARM and the SH architecture. It would be nice to share the
same Kconfig entries for both SH and all ARM variants.

As you can see, in this series the Kconfig is shared between SH and
ARM mach-shmobile. Actually, on those platforms we don't treat the
timers any differently than any other device driver and traditionally
we have been allowing the user to select which timer to use as system
timer via the kernel configuration. What is the reason behind your
suggestion with the arch Kconfig selection? It seems to me that timers
are being treated differently than any other device driver, but I'm
not sure why that is the case.

Changing SH and ARM single/multi to select via the architecture
Kconfig seems like a functional regression for single platforms to me.
It is also not really in line with TWD and architected timers that are
today selectable via the ARM Kconfig. Say that I would like to develop
code for a certain timer on a SoC with multiple timers, how can I make
sure the right timer is used? Perhaps you propose relying on the
clocksource and clockevent ratings?


/ magnus

 \ /
  Last update: 2013-11-08 09:41    [W:0.121 / U:1.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site