From: Stephen Boyd <sboyd@codeaurora.org>
To: Rob Herring <robherring2@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Russell King <linux@arm.linux.org.uk>,
arm@kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 0/4] ARM 64 bit sched_clock take #2
Date: Tue, 23 Apr 2013 09:34:50 -0700 [thread overview]
Message-ID: <5176B82A.9070003@codeaurora.org> (raw)
In-Reply-To: <5175A1B8.1090202@gmail.com>
On 04/22/13 13:46, Rob Herring wrote:
> On 04/22/2013 12:00 PM, John Stultz wrote:
>> On 04/19/2013 05:29 PM, Stephen Boyd wrote:
>>> This is what I was thinking. I don't see why we can't move this to
>>> generic code and have arm64 use it too. Those patches will follow once
>>> I find an arm64
>>> compiler.
>> I think moving this to generic code sounds like a good idea. You could
>> probably also prototype and test the 64bit code with x86_64, using the
>> TSC counter.
> I agree this should all be common, but I'd like to see the common
> version first. That is not going to make it for 3.10. For 3.10, the
> immediate need is to fix suspend and initial time for the arch timer. I
> think this should be fixed locally in arch timer code for 3.10. The
> alternative is to revert linux-next commit 023796b9be3a77481cd5 (ARM:
> arch_timer: use full 64-bit counter for sched_clock) which will cause
> the arch timer to not be used as sched_clock if another higher frequency
> sched_clock is registered.
This would make sense to me if we were already in the 3.10-rc1 or rc2
phase, but this code isn't even in Linus' tree yet. Why can't we just
fix it properly before sending off to Linus? Obviously this is up to the
maintainers to decide, so if we can't fix it properly with this patch
series I propose we revert like you say.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
Date: Tue, 23 Apr 2013 09:34:50 -0700 [thread overview]
Message-ID: <5176B82A.9070003@codeaurora.org> (raw)
In-Reply-To: <5175A1B8.1090202@gmail.com>
On 04/22/13 13:46, Rob Herring wrote:
> On 04/22/2013 12:00 PM, John Stultz wrote:
>> On 04/19/2013 05:29 PM, Stephen Boyd wrote:
>>> This is what I was thinking. I don't see why we can't move this to
>>> generic code and have arm64 use it too. Those patches will follow once
>>> I find an arm64
>>> compiler.
>> I think moving this to generic code sounds like a good idea. You could
>> probably also prototype and test the 64bit code with x86_64, using the
>> TSC counter.
> I agree this should all be common, but I'd like to see the common
> version first. That is not going to make it for 3.10. For 3.10, the
> immediate need is to fix suspend and initial time for the arch timer. I
> think this should be fixed locally in arch timer code for 3.10. The
> alternative is to revert linux-next commit 023796b9be3a77481cd5 (ARM:
> arch_timer: use full 64-bit counter for sched_clock) which will cause
> the arch timer to not be used as sched_clock if another higher frequency
> sched_clock is registered.
This would make sense to me if we were already in the 3.10-rc1 or rc2
phase, but this code isn't even in Linus' tree yet. Why can't we just
fix it properly before sending off to Linus? Obviously this is up to the
maintainers to decide, so if we can't fix it properly with this patch
series I propose we revert like you say.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2013-04-23 16:34 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 19:30 [PATCH 1/2] clocksource: arm_arch_timer: unify sched_clock init Rob Herring
2013-04-18 19:30 ` Rob Herring
2013-04-18 19:30 ` [PATCH 2/2] clocksource: arm_arch_timer: add boot and suspend sched_clock offset Rob Herring
2013-04-18 19:30 ` Rob Herring
2013-04-19 14:46 ` Catalin Marinas
2013-04-19 14:46 ` Catalin Marinas
2013-04-19 0:00 ` [PATCH 1/2] clocksource: arm_arch_timer: unify sched_clock init Stephen Boyd
2013-04-19 0:00 ` Stephen Boyd
2013-04-19 1:37 ` Rob Herring
2013-04-19 1:37 ` Rob Herring
2013-04-19 17:34 ` Stephen Boyd
2013-04-19 17:34 ` Stephen Boyd
2013-04-20 0:29 ` [PATCH 0/4] ARM 64 bit sched_clock take #2 Stephen Boyd
2013-04-20 0:29 ` Stephen Boyd
2013-04-20 0:29 ` [PATCH 1/4] ARM: sched_clock: Remove unused needs_suspend member Stephen Boyd
2013-04-20 0:29 ` Stephen Boyd
2013-04-20 0:29 ` [PATCH 2/4] ARM: sched_clock: Return suspended count earlier Stephen Boyd
2013-04-20 0:29 ` Stephen Boyd
2013-04-20 0:29 ` [PATCH 3/4] ARM: sched_clock: Add support for >32 bit sched_clock Stephen Boyd
2013-04-20 0:29 ` Stephen Boyd
2013-04-20 0:29 ` Stephen Boyd
2013-04-22 10:48 ` Will Deacon
2013-04-22 10:48 ` Will Deacon
2013-04-22 10:48 ` Will Deacon
2013-04-22 15:35 ` Stephen Boyd
2013-04-22 15:35 ` Stephen Boyd
2013-04-22 15:35 ` Stephen Boyd
2013-04-20 0:29 ` [PATCH 4/4] ARM: arch_timer: Move to setup_sched_clock_64() Stephen Boyd
2013-04-20 0:29 ` Stephen Boyd
2013-04-22 15:16 ` [PATCH 0/4] ARM 64 bit sched_clock take #2 Arnd Bergmann
2013-04-22 15:16 ` Arnd Bergmann
2013-04-22 15:34 ` Mark Rutland
2013-04-22 15:34 ` Mark Rutland
2013-04-22 15:34 ` Mark Rutland
2013-04-22 15:36 ` Stephen Boyd
2013-04-22 15:36 ` Stephen Boyd
2013-04-22 15:36 ` Stephen Boyd
2013-04-22 15:51 ` Mark Rutland
2013-04-22 15:51 ` Mark Rutland
2013-04-22 15:51 ` Mark Rutland
2013-04-22 17:00 ` John Stultz
2013-04-22 17:00 ` John Stultz
2013-04-22 20:46 ` Rob Herring
2013-04-22 20:46 ` Rob Herring
2013-04-22 20:46 ` Rob Herring
2013-04-23 16:34 ` Stephen Boyd [this message]
2013-04-23 16:34 ` Stephen Boyd
2013-05-01 0:54 ` [PATCH 5/4] sched: Make ARM's sched_clock generic for all architectures Stephen Boyd
2013-05-01 0:54 ` Stephen Boyd
2013-05-01 0:54 ` [PATCH 6/4] arm64: Move to generic sched_clock infrastructure Stephen Boyd
2013-05-01 0:54 ` Stephen Boyd
2013-05-01 9:11 ` Catalin Marinas
2013-05-01 9:11 ` Catalin Marinas
2013-05-01 9:11 ` Catalin Marinas
2013-05-01 14:44 ` Christopher Covington
2013-05-01 14:44 ` Christopher Covington
2013-05-01 14:44 ` Christopher Covington
2013-05-31 20:40 ` [PATCH 5/4] sched: Make ARM's sched_clock generic for all architectures John Stultz
2013-05-31 20:40 ` John Stultz
2013-05-31 22:13 ` Stephen Boyd
2013-05-31 22:13 ` Stephen Boyd
2013-05-31 23:50 ` John Stultz
2013-05-31 23:50 ` John Stultz
2013-04-19 14:45 ` [PATCH 1/2] clocksource: arm_arch_timer: unify sched_clock init Catalin Marinas
2013-04-19 14:45 ` Catalin Marinas
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=5176B82A.9070003@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=arm@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=john.stultz@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=robherring2@gmail.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
/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.