Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752665AbdLLSDn (ORCPT ); Tue, 12 Dec 2017 13:03:43 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:37592 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752262AbdLLSDh (ORCPT ); Tue, 12 Dec 2017 13:03:37 -0500 Date: Tue, 12 Dec 2017 19:03:17 +0100 From: Ladislav Michl To: Tony Lindgren Cc: Keerthy , daniel.lezcano@linaro.org, aaro.koskinen@iki.fi, thierry.reding@gmail.com, grygorii.strashko@ti.com, linux-omap@vger.kernel.org, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, linux-pwm@vger.kernel.org, sebastian.reichel@collabora.co.uk, linux-kernel@vger.kernel.org, t-kristo@ti.com, linux@armlinux.org.uk Subject: Re: [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports Message-ID: <20171212180317.GB10337@lenoch> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171212170054.GD14441@atomide.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1245 Lines: 25 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