2013/7/29 John Crispin <john@xxxxxxxxxxx>: > Hi Florian, > > >> It is not clear to me whether this secondary cevt is also a r4k-cevt >> device, or if it is something else? If the IRQ is shared, is there any >> way to differentiate the ralink cevt from the r4k cevt, such that both >> could request the same irq with the IRQF_SHARED flag? >> > > IRQF_SHARED | IRQF_TIMER is not allowed as a combination. Good point, forgot about that. Then how about a way to let a platform specify its own callback? Pretty much like what is done with the handle_perf(r2) case? > > > >> It looks to me like you are moving the irq setup later just to ensure >> that your ralink clockevent device has been registered before and has >> set cp0_timer_irq_installed when the set_mode() r4k clockevent device >> runs, such that it won't register the same IRQ that your platforms >> uses. If that it the case, cannot you just ensure that you run your >> cevt device registration before mips_clockevent_init() is called? > > > i dont like relying on the order in which the modules get loaded. plat_time_init() runs before mips_clockevent_init() and the ordering is explicit, would not that work for what you are trying to do? > > the actual problem is not the irq sharing but that the cevt-r4k registers > the irq when the cevt is registered and not when it is activated. i believe > that the patch fixes this problem Your patch certainly does what you say it does, but that is kind of an abuse of the set_mode() callback. -- Florian
