Hello Ladis, Keerthy, I'm trying out your combined patches to move dmtimer to clocksource and then activate the capture functionality. However, I have an unfortunate issue, that is that the pwm-omap-dmtimer driver gets loaded before the timer-dm clocksource driver. As such, the pwm driver cannot access the platform data of the dmtimer, because it is not yet filled in by the timer-dm driver. I was wondering if you've had this issue also, and if so, how did you resolve it? I could defer the probe if pdata is NULL, but there is no way to know if pdata is ever gonna be filled in. So I'm wondering how it worked on your systems? I looked at the working of the capture code and the TI datasheet, and I fear you are correct that there is no way of knowing of you are sampling the duty cycle or the inverse. In a real-time system, you could configure the capture mode in singledetect rising edge, reconfigure the capture mode in interrupt to falling edge, and voila. Another way would be to do a dual detection (as now), reconfigure the pin during IRQ to GPIO and read out the value. This might be doable with the ARM FIQ, but it is a hell of a workaround. So using this for duty cycle detection will never work I think without severe hacks. However, I only need frequency determination, so for me, it is usable. Thanks for your work and your input, Brecht -- 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
