From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH 4/7] dt-bindings: chosen: Add clocksource and clockevent selection Date: Mon, 30 Sep 2019 09:32:46 -0500 Message-ID: <20190930143246.GA19967@bogus> References: <1568123236-767-1-git-send-email-claudiu.beznea@microchip.com> <1568123236-767-5-git-send-email-claudiu.beznea@microchip.com> <20190910143231.GB14966@e107533-lin.cambridge.arm.com> <20190910150826.GA18308@e107533-lin.cambridge.arm.com> <20190910151055.GX21254@piout.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org To: Claudiu.Beznea@microchip.com Cc: tmaimon77@gmail.com, linus.walleij@linaro.org, nsekhar@ti.com, guoren@kernel.org, linux-stm32@st-md-mailman.stormreply.com, heiko@sntech.de, linux-samsung-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, khilman@baylibre.com, Ludovic.Desroches@microchip.com, linux-imx@nxp.com, u.kleine-koenig@pengutronix.de, uclinux-h8-devel@lists.sourceforge.jp, marc.zyngier@arm.com, s.hauer@pengutronix.de, linux-unisoc@lists.infradead.org, khalasa@piap.pl, tglx@linutronix.de, sbranden@broadcom.com, linux-kernel@vger.kernel.org, ralf@linux-mips.org, paul.burton@mips.com, kernel@pengutronix.de, mark.rutland@arm.com, alexandre.belloni@bootlin.com, jhogan@kernel.org, palmer@sifive.com, eric@anholt.net, thierry.reding@gmail.com, manivannan.sadhasivam@linaro.org, ysato@users.sourceforge.jp, zhang.lyra@gmail.com, daniel.lezcano@linaro.org, jonathanh@nvidia.com, bgolaszewski@baylibre.co List-Id: devicetree@vger.kernel.org On Wed, Sep 11, 2019 at 07:18:07AM +0000, Claudiu.Beznea@microchip.com wrote: > > > On 11.09.2019 03:03, Linus Walleij wrote: > > External E-Mail > > > > > > On Tue, Sep 10, 2019 at 4:11 PM Alexandre Belloni > > wrote: > >> On 10/09/2019 16:08:26+0100, Sudeep Holla wrote: > >>> On Tue, Sep 10, 2019 at 02:51:50PM +0000, Claudiu.Beznea@microchip.com wrote: > > > >>> In that case, why can't we identify capability that with the compatibles > >>> for this timer IP ? > >>> > >>> IOW, I don't like the proposal as it's hardware limitation. > >> > >> To be clear, bot timers are exactly the same but can't be clocksource > >> and clockevent at the same time. Why would we have different compatibles > >> for the exact same IP? > > > > In that case why not just pick the first one you find as clocksource > > and the second one as clock event? As they all come to the > > same timer of init function two simple local state variables can > > solve that: > > > > static bool registered_clocksource; > > static bool registered_clockevent; > > > > probe(timer) { > > if (!registered_clocksource) { > > register_clocksource(timer); > > registrered_clocksource = true; > > return; > > } > > if (!registered_clockevent) { > > register_clockevent(timer); > > registered_clockevent = true; > > return; > > } > > pr_info("surplus timer %p\n", timer); > > } > > > > That was also my proposal for the driver I'm sending this series for (see > [1]) but it has been proposed to implement a mechanism similar to this one > in this series (see [2] and [3]). This comes up over and over, and the answer is still no. Either each block is identical and doesn't matter which one is used for what or there is some h/w difference that you should describe. If you want something that would even be considered to put into DT, then define something BSD or other OS's could use too. (That's not a suggestion to respin this with generalized names.) Rob