Le mercredi 31 juillet 2013 12:22:15 David Daney a écrit : > On 07/29/2013 04:14 AM, Florian Fainelli wrote: > > 2013/7/29 John Crispin <john@xxxxxxxxxxx>: > [...] > > >>> 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. > > I might as add my $0.02... > > There are many other clockevent drivers that do this type of thing > aren't there? The clockevent framework uses this to > install/remove/switch drivers, so why should cevt-r4k not be made to > work like this? Whatever works for you. I still would like to understand why plat_time_init() is not suitable for John's specific use case. -- Florian
