On Tue, Dec 12, 2017 at 10:21:50AM -0800, Tony Lindgren wrote:

* Ladislav Michl [off-list ref] [171212 18:06]:

quoted

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