Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753638AbdLSXUj (ORCPT ); Tue, 19 Dec 2017 18:20:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:60518 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753144AbdLSXUg (ORCPT ); Tue, 19 Dec 2017 18:20:36 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2EA221921 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh+dt@kernel.org X-Google-Smtp-Source: ACJfBotrigWWikf+iCQYWPLKuGF1nHQYM0eWhTnkTallgVyYcXGb8FJBO7WAWsC5mnI1Mpqm6rnjs8AxXeOC1+CDuEo= MIME-Version: 1.0 In-Reply-To: <8fe1dce0-3fd2-d740-8456-bf3b734e571a@ti.com> References: <20171213185313.20017-1-alexandre.belloni@free-electrons.com> <20171213185313.20017-2-alexandre.belloni@free-electrons.com> <8fe1dce0-3fd2-d740-8456-bf3b734e571a@ti.com> From: Rob Herring Date: Tue, 19 Dec 2017 17:20:14 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection To: Grygorii Strashko Cc: Alexandre Belloni , Daniel Lezcano , Mark Rutland , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , Boris Brezillon , Tony Lindgren Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3136 Lines: 75 On Fri, Dec 15, 2017 at 7:57 PM, Grygorii Strashko wrote: > > > On 12/13/2017 12:53 PM, Alexandre Belloni wrote: >> The clocksource and clockevent timer are probed early in the boot process. >> At that time it is difficult for linux to know whether a particular timer >> can be used as the clocksource or the clockevent or by another driver, >> especially when they are all identical or have similar features. >> >> Until now, multiple strategies have been used to solve that: >> - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK >> - use a kernel parameter as the "clocksource" early_param in mach-omap2 >> - registering the first seen timer as a clockevent and the second one as >> a clocksource as in rk_timer_init or dw_apb_timer_init >> >> Add a linux,clocksource and a linux,clockevent node in chosen with a timer >> property pointing to the timer to use. Other properties, like the targeted >> precision may be added later. >> >> Signed-off-by: Alexandre Belloni >> --- >> Documentation/devicetree/bindings/chosen.txt | 20 ++++++++++++++++++++ >> 1 file changed, 20 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt >> index e3b13ea7d2ae..c7ee3ecb5276 100644 >> --- a/Documentation/devicetree/bindings/chosen.txt >> +++ b/Documentation/devicetree/bindings/chosen.txt >> @@ -120,3 +120,23 @@ e.g. >> While this property does not represent a real hardware, the address >> and the size are expressed in #address-cells and #size-cells, >> respectively, of the root node. >> + >> +linux,clocksource and linux,clockevent >> +-------------------------------------- >> + >> +Those nodes have a timer property. This property is a phandle to the timer to be >> +chosen as the clocksource or clockevent. This is only useful when the platform >> +has multiple identical timers and it is not possible to let linux make the >> +correct choice. >> + >> +/ { >> + chosen { >> + linux,clocksource { >> + timer = <&timer0>; >> + }; >> + >> + linux,clockevent { >> + timer = <&timer1>; >> + }; >> + }; >> +}; >> > > It'd be nice if smth. like this will actually happen, as on some OMAP > platforms can be up to 3-4 alternatives for each clocksource/clockevent and > different combination need to be selected depending on SoC and platform > (and sometime - use case) which is pain in multi-platform environment now. Can we have some concrete examples with why the current selection logic is broken. For use-cases, if a board maker can't make that decision, then I think those should be kernel command-line options (if boot time) or sysfs controlled. > But more important note from my side is clocksource and clockevent selections seems > not enough :( There are also sched clock (sched_clock_register()) and delay_timer > (register_current_timer_delay() at least on ARM). > Both above can't be unregistered (at least last time I've checked). Sounds like an OS problem... Rob