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
