All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Baruch Siach <baruch@tkos.co.il>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jamie Iles <jamie@jamieiles.com>,
	Dinh Nguyen <dinguyen@altera.com>
Subject: Re: [RFC PATCH 2/2] clocksource: dw_apb: allow build for architectures other than arm
Date: Thu, 30 May 2013 09:11:17 -0700	[thread overview]
Message-ID: <51A77A25.8080306@linaro.org> (raw)
In-Reply-To: <20130530053233.GL25186@sapphire.tkos.co.il>

On 05/29/2013 10:32 PM, Baruch Siach wrote:
> Hi John,
>
> On Tue, May 28, 2013 at 01:24:17PM -0700, John Stultz wrote:
>> On 05/26/2013 05:12 AM, Baruch Siach wrote:
>>>   static const struct of_device_id osctimer_ids[] __initconst = {
>>> @@ -124,3 +135,10 @@ void __init dw_apb_timer_init(void)
>>>   	init_sched_clock();
>>>   }
>>> +
>>> +#ifndef CONFIG_HAVE_SETUP_SCHED_CLOCK
>>> +unsigned long long notrace sched_clock()
>>> +{
>>> +	return read_sched_clock() * sched_clock_mult;
>>> +}
>>> +#endif
>> Also, can you try to condense the number of #ifndef
>> CONFIG_HAVE_SETUP_SCHED_CLOCK checks to one, and consolidate the
>> needed functions all in that one conditional?
> Thanks for your comments. I'll rework the patch and resubmit.
>
> I've just noticed that I have a bigger problem. read_sched_clock() returns
> u32, not u64. This means that in a rate of, say, 100MHz it will wrap around
> after a little more than 40 seconds. Would it make sense to put ARM's 32 bin
> sched_clock extension code (arch/arm/kernel/sched_clock.c) is a common place
> (maybe drivers/clocksource), and use that? There seems to be nothing ARM
> specific in this code, after all.

Yea, working out an actual generic sched_clock implementation is 
something I'd like to see done.

Though I'd really rather we not toss yet another chunk of infrastructure 
in the drivers/clocksource directory. Instead we should probably have a 
kernel/time/sched_clock.c.

Then its just the issue of tying that and the clocksource code together 
so you just register existing capable clocksources with a SCHED_CLOCK 
flag or via a different registration hook.

I don't think it will be an easy job, but if you want to give it a shot, 
I'd be quite interested in reviewing the patches!

thanks
-john







WARNING: multiple messages have this Message-ID (diff)
From: john.stultz@linaro.org (John Stultz)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/2] clocksource: dw_apb: allow build for architectures other than arm
Date: Thu, 30 May 2013 09:11:17 -0700	[thread overview]
Message-ID: <51A77A25.8080306@linaro.org> (raw)
In-Reply-To: <20130530053233.GL25186@sapphire.tkos.co.il>

On 05/29/2013 10:32 PM, Baruch Siach wrote:
> Hi John,
>
> On Tue, May 28, 2013 at 01:24:17PM -0700, John Stultz wrote:
>> On 05/26/2013 05:12 AM, Baruch Siach wrote:
>>>   static const struct of_device_id osctimer_ids[] __initconst = {
>>> @@ -124,3 +135,10 @@ void __init dw_apb_timer_init(void)
>>>   	init_sched_clock();
>>>   }
>>> +
>>> +#ifndef CONFIG_HAVE_SETUP_SCHED_CLOCK
>>> +unsigned long long notrace sched_clock()
>>> +{
>>> +	return read_sched_clock() * sched_clock_mult;
>>> +}
>>> +#endif
>> Also, can you try to condense the number of #ifndef
>> CONFIG_HAVE_SETUP_SCHED_CLOCK checks to one, and consolidate the
>> needed functions all in that one conditional?
> Thanks for your comments. I'll rework the patch and resubmit.
>
> I've just noticed that I have a bigger problem. read_sched_clock() returns
> u32, not u64. This means that in a rate of, say, 100MHz it will wrap around
> after a little more than 40 seconds. Would it make sense to put ARM's 32 bin
> sched_clock extension code (arch/arm/kernel/sched_clock.c) is a common place
> (maybe drivers/clocksource), and use that? There seems to be nothing ARM
> specific in this code, after all.

Yea, working out an actual generic sched_clock implementation is 
something I'd like to see done.

Though I'd really rather we not toss yet another chunk of infrastructure 
in the drivers/clocksource directory. Instead we should probably have a 
kernel/time/sched_clock.c.

Then its just the issue of tying that and the clocksource code together 
so you just register existing capable clocksources with a SCHED_CLOCK 
flag or via a different registration hook.

I don't think it will be an easy job, but if you want to give it a shot, 
I'd be quite interested in reviewing the patches!

thanks
-john

  reply	other threads:[~2013-05-30 16:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-26 12:12 [RFC PATCH 2/2] clocksource: dw_apb: allow build for architectures other than arm Baruch Siach
2013-05-26 12:12 ` Baruch Siach
2013-05-28 20:24 ` John Stultz
2013-05-28 20:24   ` John Stultz
2013-05-30  5:32   ` Baruch Siach
2013-05-30  5:32     ` Baruch Siach
2013-05-30 16:11     ` John Stultz [this message]
2013-05-30 16:11       ` John Stultz
2013-05-31  5:32       ` Baruch Siach
2013-05-31  5:32         ` Baruch Siach
2013-06-20 14:44     ` Pavel Machek
2013-06-20 14:44       ` Pavel Machek
2013-06-20 15:03       ` Baruch Siach
2013-06-20 15:03         ` Baruch Siach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51A77A25.8080306@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=baruch@tkos.co.il \
    --cc=dinguyen@altera.com \
    --cc=jamie@jamieiles.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.