[RFC PATCHv2] picoxcell: add support for the system timers

Jamie Iles jamie at jamieiles.com
Wed Dec 8 12:26:56 EST 2010


On Wed, Dec 08, 2010 at 04:14:11PM +0000, Russell King - ARM Linux wrote:
> On Fri, Nov 26, 2010 at 11:11:16AM +0000, Jamie Iles wrote:
> > +static irqreturn_t timer_interrupt(int irq, void *dev_id)
> > +{
> > +	struct timer_instance *timer = &timers[TIMER_ID_CLOCKEVENT];
> > +
> > +	/* If we are in oneshot mode, we need to stop receiving interrupts. */
> > +	if (CLOCK_EVT_MODE_ONESHOT == clockevent_picoxcell.mode) {
> > +		unsigned long val = readl(timer->base +
> > +					  TIMER_CONTROL_REG_OFFSET);
> > +		val |= TIMER_INTERRUPT_MASK;
> > +		writel(val, timer->base + TIMER_CONTROL_REG_OFFSET);
> > +	}
> 
> It's normal not to emulate behaviours here which the hardware doesn't
> support - that's the point of the generic clockevents/clocksource
> layers.  They're there to handle whatever the hardware can support and
> turn it into something the kernel wants.

Ok, I underestimated clockevents and how NO_HZ works and thought that we'd 
keep on receiving too many interrupts but that's not the case! I'll fix up the 
next revision to remove this hack.

> > +/*
> > + * Overwrite weak default sched_clock with something more precise.
> > + *
> > + * On picoXcell we have a RTC that clocks at 200MHz so a multiply by 5 gives
> > + * us a nanosecond count.
> > + */
> > +unsigned long long notrace sched_clock(void)
> > +{
> > +#define CYCLES_TO_NSEC_MULT	(NSEC_PER_SEC / CLOCK_TICK_RATE)
> > +	return cnt32_to_63(readl(IO_ADDRESS(PICOXCELL_RTCLK_BASE) +
> > +				 RTCLK_CCV_REG_OFFSET)) * CYCLES_TO_NSEC_MULT;
> 
> Have you read the comments in include/linux/cnt32_to_63.h, or thought
> about the '63' part of the name ?

Sadly not, this was one I'd taken from the mailing list for mach-tegra as we 
were missing a sched_clock() implementation before. Since then I've had a go 
at taking Linus' sched_clock() implementation for plat-nomadik and using that 
to increase the wrap period which I'll roll into the next revision.

Jamie



More information about the linux-arm-kernel mailing list