What is the right way to setup MIPS timer irq in 2.6.29?

What is the right way to setup MIPS timer irq in 2.6.29?

[David Wuertele]

Has the system timer paradigm changed between 2.6.18 and 2.6.29?
I'm trying to update my Broadcom-based embedded system to 2.6.29,
and I'm running into problems getting the system timer to run.
I'm looking for a clue about how to port forward my arch/mips/brcmstb/*
files, specifically I want to write a plat_time_init() function
that does for 2.6.29 what plat_timer_setup(struct irqaction *irq)
did for 2.6.18.

In 2.6.18, arch/mips/kernel/time.c defines a high-level ISR called
timer_interrupt (which does things like lock xtime_lock, call
mips_hpt_read() and do_timer(regs), and return IRQ_HANDLED). time.c
then defines a struct irqaction timer_irqaction and sets
timer_interrupt to be the .handler field.  Finally, time.c calls
plat_timer_setup(timer_irqaction), which is defined by the Broadcom
patches to call setup_irq(timer_irqaction).

In 2.6.29, arch/mips/kernel/time.c has a comment saying that the new
plat_time_init hook does not receive the irqaction pointer argument
anymore, because each "clock_event_device" should use its own struct
irqrequest.

I tried having the broadcom arch's plat_time_init() function create an
irqaction and call setup_irq(), but the timer_interrupt() function
that used to be in arch/mips/kernel/time.c doesn't exist anymore, and
I can't seem to find the replacement.

Is there a replacement for timer_interrupt()?  I thought that maybe
the hrtimer_interrupt() might be the one, but it requires something
called a struct clock_event_device.  When I looked at clock_event_device
it was very complex, and I get the feeling I'm barking up the wrong tree.

Can anyone offer pointers on how to call setup_irq() from plat_time_init()?

Thanks,
Dave

Re: What is the right way to setup MIPS timer irq in 2.6.29?

[Jon Fraser]

Which platform?

On Wed, 2009-04-08 at 09:57 -0700, David Wuertele wrote:
> Has the system timer paradigm changed between 2.6.18 and 2.6.29?
> I'm trying to update my Broadcom-based embedded system to 2.6.29,
> and I'm running into problems getting the system timer to run.
> I'm looking for a clue about how to port forward my arch/mips/brcmstb/*
> files, specifically I want to write a plat_time_init() function
> that does for 2.6.29 what plat_timer_setup(struct irqaction *irq)
> did for 2.6.18.
> 
> In 2.6.18, arch/mips/kernel/time.c defines a high-level ISR called
> timer_interrupt (which does things like lock xtime_lock, call
> mips_hpt_read() and do_timer(regs), and return IRQ_HANDLED). time.c
> then defines a struct irqaction timer_irqaction and sets
> timer_interrupt to be the .handler field.  Finally, time.c calls
> plat_timer_setup(timer_irqaction), which is defined by the Broadcom
> patches to call setup_irq(timer_irqaction).
> 
> In 2.6.29, arch/mips/kernel/time.c has a comment saying that the new
> plat_time_init hook does not receive the irqaction pointer argument
> anymore, because each "clock_event_device" should use its own struct
> irqrequest.
> 
> I tried having the broadcom arch's plat_time_init() function create an
> irqaction and call setup_irq(), but the timer_interrupt() function
> that used to be in arch/mips/kernel/time.c doesn't exist anymore, and
> I can't seem to find the replacement.
> 
> Is there a replacement for timer_interrupt()?  I thought that maybe
> the hrtimer_interrupt() might be the one, but it requires something
> called a struct clock_event_device.  When I looked at clock_event_device
> it was very complex, and I get the feeling I'm barking up the wrong tree.
> 
> Can anyone offer pointers on how to call setup_irq() from plat_time_init()?
> 
> Thanks,
> Dave
> 
> 
> 

Re: What is the right way to setup MIPS timer irq in 2.6.29?

[David Wuertele]

Cable STB SOC, I'm away from my desk but I think it was BCM7456D0.

> 
> Which platform?
> > 
> > Can anyone offer pointers on how to call setup_irq() from plat_time_init()?

Re: What is the right way to setup MIPS timer irq in 2.6.29?

[Brian Foster]

On Wednesday 08 April 2009 18:57:33 David Wuertele wrote:
> Has the system timer paradigm changed between 2.6.18 and 2.6.29?
> I'm trying to update my Broadcom-based embedded system to 2.6.29,
> and I'm running into problems getting the system timer to run.
> I'm looking for a clue about how to port forward my arch/mips/brcmstb/*
> files, specifically I want to write a plat_time_init() function
> that does for 2.6.29 what plat_timer_setup(struct irqaction *irq)
> did for 2.6.18.

David,

   This is just a guess....  The main change (that I know of)
  was in 2.6.24 to support “tickless idle”.  I just finished(?)
  fighting the battle to get the system timer to run reliably
  (discovering, in the process, a (minor) bug with our SoC ;-\ ).
  I've a meeting in a few minutes and so no time to write down
  any details (now), but hopefully Ralf or someone can either
  fill you in or point (both of us) to some doc.

cheers!
	-blf-
-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: What is the right way to setup MIPS timer irq in 2.6.29?

[David Wuertele]

I wrote:

> Has the system timer paradigm changed between 2.6.18 and 2.6.29?
> I'm trying to update my Broadcom-based embedded system to 2.6.29,
> and I'm running into problems getting the system timer to run.

I solved my problem, though I'm still a little unclear about the reasoning.

The solution was to enable these:
CONFIG_CEVT_R4K=y
CONFIG_CSRC_R4K=y

I also had to define get_c0_compare_int() to return the system timer
interrupt.  Once I had done these things, start_kernel() calls time_init(),
which calls mips_clockevent_init() and init_mips_clocksource().
init_mips_clocksource() calls the init_r4k_clocksource() that was
enabled with the new config options.  Now my system clock runs like I think it
should.

I think I might not need the CEVT components... I'm going to look into that
next.  But I wish there was some easy to find documentation about why this
code had to be moved into the arch/mips/cevt-*.c and arch/mips/csrc-*.c
libraries.

Dave

Re: What is the right way to setup MIPS timer irq in 2.6.29?

[David Daney]

David Wuertele wrote:
> I wrote:
> 
>> Has the system timer paradigm changed between 2.6.18 and 2.6.29?
>> I'm trying to update my Broadcom-based embedded system to 2.6.29,
>> and I'm running into problems getting the system timer to run.
> 
> I solved my problem, though I'm still a little unclear about the reasoning.
> 
> The solution was to enable these:
> CONFIG_CEVT_R4K=y
> CONFIG_CSRC_R4K=y
> 
> I also had to define get_c0_compare_int() to return the system timer
> interrupt.  Once I had done these things, start_kernel() calls time_init(),
> which calls mips_clockevent_init() and init_mips_clocksource().
> init_mips_clocksource() calls the init_r4k_clocksource() that was
> enabled with the new config options.  Now my system clock runs like I think it
> should.
> 
> I think I might not need the CEVT components... I'm going to look into that
> next.

No, you do need them.  That is the source of the interrupts.  Using the 
standard cevt-r4k.c you get nice things like the tickless kernel all for 
free.


> But I wish there was some easy to find documentation about why this
> code had to be moved into the arch/mips/cevt-*.c and arch/mips/csrc-*.c
> libraries.
> 

It had to change because the entire Linux time keeping infrastructure 
change to use the generic clock source and clock event system.

David Daney

Re: What is the right way to setup MIPS timer irq in 2.6.29?

[Kevin D. Kissell]

David Wuertele wrote:
> I think I might not need the CEVT components... I'm going to look into that
> next.  But I wish there was some easy to find documentation about why this
> code had to be moved into the arch/mips/cevt-*.c and arch/mips/csrc-*.c
> libraries.
>   
The "architecture independent" common event timer infrastructure has the
defects of being very poorly documented and (in my opinion) messier than
it needs to be.  But it has the virtue of making it straightforward to
get tickless operation via CONFIG_NO_HZ, which improves both throughput
and power consumption on most MIPS platforms.  If you've got it working
on your platform, keep it!

          Regards,

          Kevin K.

Re: What is the right way to setup MIPS timer irq in 2.6.29?

[Brian Foster]

On Thursday 09 April 2009 22:01:43 David Wuertele wrote:
> I wrote:
> 
> > Has the system timer paradigm changed between 2.6.18 and 2.6.29?
> > I'm trying to update my Broadcom-based embedded system to 2.6.29,
> > and I'm running into problems getting the system timer to run.
> 
> I solved my problem, though I'm still a little unclear about the reasoning.
> 
> The solution was to enable these:
> CONFIG_CEVT_R4K=y
> CONFIG_CSRC_R4K=y
> 
> I also had to define get_c0_compare_int() to return the system timer
> interrupt.  Once I had done these things, start_kernel() calls time_init(),
> which calls mips_clockevent_init() and init_mips_clocksource().
> init_mips_clocksource() calls the init_r4k_clocksource() that was
> enabled with the new config options.  Now my system clock runs like
> I think it should.

   Yep!  That's the bunny.  I do wish it was documented
  someplace in a useful fashion.  In my case, since all
  of our interrupts are routed through an our SoC's PIC,
  I also had to back-port compare_change_hazard() from
  8531a35e5e275b17c57c39b7911bc2b37025f28c plus some
  other changes specific to our SoC and its PIC (we're
  currently moving to 2.6.24, hence the back-porting).

> I think I might not need the CEVT components... I'm going to look into that
> next.  But I wish there was some easy to find documentation about why this
> code had to be moved into the arch/mips/cevt-*.c and arch/mips/csrc-*.c
> libraries.

   You “need” them if you use the core's counter for
  jiffies and want “tickless idle” (which you have to
  enable (with CONFIG_NO_HZ or something like that
  (I don't recall))), or at least that's my current
  understanding.  If you do happen to find some doc
  about the API changes, I'd love to see/read it.

cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com