Hello Tony, The way you are proposing means that I should not touch dmtimer.c? I got it wrong? I'm not sure what are you suggesting with "let's implement it using a Linux generic Framework instead, request_irq". I used request_irq in the dmtimer.c code to set a ISR for every timer that is probed. Inside ISR it is called the user callback set through omap_dm_timer_set_isr_callback. I found in the kernel source code places where it was implemented identical or very similar to what I did. Please have a look in the following. arch/mips/bcm63xx/timer.c --- client provides the callback which is called from timer ISR routine powerpc/sysdev/mpic_timer.c - client provides the actual ISR callback Please explain a little bit what you have though should be done in dmtimer.c regarding the interrupt support. Respect and regards, Andrei Varvara > -----Original Message----- > From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] > Sent: Wednesday, March 23, 2016 7:03 PM > To: Andrei Varvara <Andrei.Varvara@xxxxxxxx> > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] plat-omap: dmtimer: Add support for interrupts > > * Andrei Varvara <andrei.varvara@xxxxxxxx> [160323 09:42]: > > Added the posibility to have interrupts from any timer. > > A client module can register a callback for each timer using the new > > API function omap_dm_timer_set_isr_callback. > > A feature needed for sure.. But let's implement it using a Linux generic > framework instead, in this case request_irq(). > > You can add minimal irqchip support to dmtimer. Then you can specify > interrupts = <&timer2> in the board specific .dts file for the consumer driver. > And then we can just do request_irq() in the consumer driver to get the timer > events! > > Regards, > > Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html