From: Jamie Iles <jamie@jamieiles.com>
To: jacob pan <jacob.jun.pan@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jamie Iles <jamie@jamieiles.com>,
LKML <linux-kernel@vger.kernel.org>,
John Stultz <johnstul@us.ibm.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] clocksource: clocksource/clockevent driver for Synopsys dw_apb_timer
Date: Thu, 31 Mar 2011 18:42:47 +0100 [thread overview]
Message-ID: <20110331174247.GE3371@pulham.picochip.com> (raw)
In-Reply-To: <20110331095051.7933c7b9@jacob-laptop>
On Thu, Mar 31, 2011 at 09:50:51AM -0700, jacob pan wrote:
> On Thu, 31 Mar 2011 17:33:12 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > On Thu, 31 Mar 2011, Jamie Iles wrote:
> >
> > > This patch adds a driver for the Synopsys DesignWare APB timer block
> > > found in some ARM systems. This uses the timers with an IRQ as a
> > > clockevents device and a timer without an IRQ as a clocksource
> > > device.
> >
> > Interesting. That's probably the same thing as:
> >
> > arch/x86/kernel/apb_timer.c
> >
> > So if we merge that thing, then we should make sure, that we can
> > replace the x86 one with it.
> >
> It seems we have room to consolidate, here is my 2c:
> 1. need to support multiple timer channels
> 2. support percpu clockevent, need to deal with cpu online/offline
> 3. early boot needs. I don't know if abp timer is needed for booting on
> ARM platforms. But for Moorestown, we need timer before platform bus
> running. So I guess we cannot enumerate the timer as platform device.
ARM does need it quite early to calibrate the delay loop but I've been
registering it early by creating an early_platform_device. The other
difference is that x86 doesn't support the clk API.
How about factoring out the clockevent and clocksource operations
(.set_next_event, .set_mode, .read etc) and the bits that actually drive
the hardware into an apb_timer.c then have stuff that does platform
device registration or langwell specific stuff in a higher layer?
It looks like arch/x86/kernel/apb_timer.c would still need some lower
level access to the timers for doing things like the calibration in
apbt_quick_calibrate() before registering the clocksource.
Jamie
next prev parent reply other threads:[~2011-03-31 17:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-31 15:12 Jamie Iles
2011-03-31 15:33 ` Thomas Gleixner
2011-03-31 16:50 ` jacob pan
2011-03-31 17:00 ` Thomas Gleixner
2011-03-31 17:42 ` Jamie Iles [this message]
2011-03-31 19:19 ` jacob pan
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=20110331174247.GE3371@pulham.picochip.com \
--to=jamie@jamieiles.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®