From mboxrd@z Thu Jan 1 00:00:00 1970 From: ladis@linux-mips.org (Ladislav Michl) Date: Tue, 12 Dec 2017 19:03:17 +0100 Subject: [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports In-Reply-To: <20171212170054.GD14441@atomide.com> References: <1513059137-21593-1-git-send-email-j-keerthy@ti.com> <1513059137-21593-2-git-send-email-j-keerthy@ti.com> <20171212071624.GA3453@lenoch> <20171212080134.GA9589@lenoch> <9de9b3dc-09f4-d58b-ba5a-60fcb563c665@ti.com> <20171212081923.GA10084@lenoch> <7c92b0c2-8784-9c14-66b0-a19fe68f08ad@ti.com> <20171212170054.GD14441@atomide.com> Message-ID: <20171212180317.GB10337@lenoch> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Dec 12, 2017 at 09:00:54AM -0800, Tony Lindgren wrote: > Hmm what do you mean? We don't want to export tons of custom functions from > the timers in and then be in trouble when at some point we have a Linux > generic hw timer framework. We already had to deal with these custom > exports earlier with conversion to multiarch and then again with > device tree. > > For now, it's best to pass the timer information to the pwm driver in > platform data. In the long run that will be much easier to deal with than > fixing random drivers tinkering with the timer registers directly. All that register access would happen only in drivers/clocksource/timer-dm.c? So platform data will hold all function pointers needed for event capture and the pwm driver will do only interface to pwm framework. > Ideally the pwm driver would just do a request_irq from the dmtimer code > where dmtimer code would implement an interrupt controller. That would > be already most fo the Linux generic hardware timer framework right there :) 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? Thank you, ladis