From: Paul Mundt <lethal@linux-sh.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
Russell King <linux@arm.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 8/8] ARM: smp: Remove local timer API
Date: Sat, 23 Feb 2013 01:25:00 +0900 [thread overview]
Message-ID: <20130222162458.GA19670@linux-sh.org> (raw)
In-Reply-To: <20130222111545.GA15020@e106331-lin.cambridge.arm.com>
On Fri, Feb 22, 2013 at 11:15:45AM +0000, Mark Rutland wrote:
> One thing that struck me when I was fiddling with the broadcast mechanism was
> that it should be possible to have a generic dummy timer implementation. As
> long as the architecture calls notifiers at the appropriate times, it should
> look like any other timer driver (apart from not touching any hardware). It just
> needs to depend on ARCH_HAS_TICK_BROADCAST.
>
> I believe it shouldn't be too difficult to implement, though I may be blind to
> some problems.
>
It would be nice to have a generic dummy timer driver, quite a few
architectures could use it directly already. If no one beats me to it,
I'll give it a go as I convert the SH stuff over to using
ARCH_HAS_TICK_BROADCAST and killing off the local timer API there.
WARNING: multiple messages have this Message-ID (diff)
From: lethal@linux-sh.org (Paul Mundt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/8] ARM: smp: Remove local timer API
Date: Sat, 23 Feb 2013 01:25:00 +0900 [thread overview]
Message-ID: <20130222162458.GA19670@linux-sh.org> (raw)
In-Reply-To: <20130222111545.GA15020@e106331-lin.cambridge.arm.com>
On Fri, Feb 22, 2013 at 11:15:45AM +0000, Mark Rutland wrote:
> One thing that struck me when I was fiddling with the broadcast mechanism was
> that it should be possible to have a generic dummy timer implementation. As
> long as the architecture calls notifiers at the appropriate times, it should
> look like any other timer driver (apart from not touching any hardware). It just
> needs to depend on ARCH_HAS_TICK_BROADCAST.
>
> I believe it shouldn't be too difficult to implement, though I may be blind to
> some problems.
>
It would be nice to have a generic dummy timer driver, quite a few
architectures could use it directly already. If no one beats me to it,
I'll give it a go as I convert the SH stuff over to using
ARCH_HAS_TICK_BROADCAST and killing off the local timer API there.
next prev parent reply other threads:[~2013-02-22 16:25 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 7:27 [PATCH 0/8] Remove ARM local timer API Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` [PATCH 1/8] ARM: smp: Lower rating of dummy broadcast device Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` [PATCH 2/8] ARM: smp_twd: Divorce smp_twd from local timer API Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` [PATCH 3/8] ARM: EXYNOS4: Divorce mct " Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` [PATCH 4/8] ARM: PRIMA2: Divorce timer-marco " Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` [PATCH 5/8] ARM: MSM: Divorce msm_timer " Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-03-05 19:04 ` David Brown
2013-03-05 19:04 ` David Brown
2013-02-22 7:27 ` [PATCH 6/8] clocksource: time-armada-370-xp: Fix sparse warning Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` [PATCH 7/8] clocksource: time-armada-370-xp: Divorce from local timer API Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 7:27 ` [PATCH 8/8] ARM: smp: Remove " Stephen Boyd
2013-02-22 7:27 ` Stephen Boyd
2013-02-22 11:15 ` Mark Rutland
2013-02-22 11:15 ` Mark Rutland
2013-02-22 16:25 ` Paul Mundt [this message]
2013-02-22 16:25 ` Paul Mundt
2013-02-25 13:40 ` Mark Rutland
2013-02-25 13:40 ` Mark Rutland
2013-03-04 23:50 ` Stephen Boyd
2013-03-04 23:50 ` Stephen Boyd
2013-03-04 23:52 ` Stephen Boyd
2013-03-04 23:52 ` Stephen Boyd
2013-03-05 11:02 ` Mark Rutland
2013-03-05 11:02 ` Mark Rutland
2013-03-05 18:45 ` Stephen Boyd
2013-03-05 18:45 ` Stephen Boyd
2013-02-24 2:37 ` Stephen Boyd
2013-02-24 2:37 ` Stephen Boyd
2013-02-25 13:44 ` Mark Rutland
2013-02-25 13:44 ` Mark Rutland
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=20130222162458.GA19670@linux-sh.org \
--to=lethal@linux-sh.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=mark.rutland@arm.com \
--cc=sboyd@codeaurora.org \
/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.