Messages in this thread | | | Date | Wed, 13 Dec 2017 10:15:27 +0100 | From | Ladislav Michl <> | Subject | Re: [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports |
| |
On Tue, Dec 12, 2017 at 10:21:50AM -0800, Tony Lindgren wrote: > * Ladislav Michl <ladis@linux-mips.org> [171212 18:06]: > > I do not follow. Each general-purpose timer module has its own interrupt line, > > so claiming that irq directly using request_irq seems enough. Could you > > explain interrupt controller idea a bit more? > > Well let's assume we have drivers/clocksource/timer-dm.c implement > an irq controller. Then the pwm driver would just do: > > pwm9: dmtimer-pwm { > compatible = "ti,omap-dmtimer-pwm"; > #pwm-cells = <3>; > ti,timers = <&timer9>; > ti,clock-source = <0x00>; /* timer_sys_ck */ > interrupts-extended = <&timer9 IRQ_TYPE_SOMETHING>; > }; > > Then you can do whatever you need to in the pwm driver with > enable_irq/disable_irq + a handler?
That seems to work. Now should we map 1:1 to timer interrupt or have separate interrupt for match, overflow and capture? Former would need some more dm_timer_ops to determine interrupt source, while later would work "automagically" - but I haven't tested it yet.
> If reading the line status is needed.. Then maybe the GPIO framework > needs to have hardware timer support instead?
It does not seem OMAP can read event pin value in event capture mode.
> Anyways, just thinking out loud how we could have a Linux generic > hardware timer framework that drivers like pwm could then use.
I need a bit longer chain: dmtimer -> pwm -> rc (which calls ir_raw_event_store from interrupt) Is extending pwm core with interrpt callback the right thing there? Something like: (*pulse_captured)(ktime_t width, ktime_t last_edge);
Thank you, ladis
| |