LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Mark Rutland <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection
Date: Thu, 14 Dec 2017 21:01:20 +0100
Message-ID: <20171214210120.6b436e0d@bbrezillon> (raw)
In-Reply-To: <CAL_JsqLm5n6s=cr2hBZp4H9pDPKHUOPWs94JMWYFYJ3hsMMxZQ@mail.gmail.com>

Hi Rob,

On Wed, 13 Dec 2017 16:57:50 -0600
Rob Herring <robh+dt@kernel.org> wrote:

> On Wed, Dec 13, 2017 at 12:53 PM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> 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.  
> 
> If all identical, then it shouldn't matter. "similar" means some
> difference. Describe those differences.

We had this discussion already. Those timers might be connected to
external pins and may serve the role of PWM generators or capture
devices. We can also chain timers and provide a clocksource with a
better resolution or one that wraps less often. In the end it's all
about how the user plans to use its system, and this has to be
described somehow. Assuming that the software can decide by itself
which timer should be used or how many of them should be chained is
just an utopia.

> 
> > Until now, multiple strategies have been used to solve that:
> >  - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK  
> 
> Compile time probably means only one option is really used.

Compile time selection prevents using the same kernel for different
boards (in other words, no multi-v7), so not really an option here.

> 
> >  - use a kernel parameter as the "clocksource" early_param in mach-omap2  
> 
> Yeah, OMAP was one of the previous times this came up and also
> attempted something like this. This parameter predates selecting
> timers based on features described in DT. Look at commit
> 2eb03937df3ebc (ARM: OMAP3: Update clocksource timer selection).

Then, would you accept to have a property saying that a specific timer
is a free-running timer (suitable for clocksource) or a programmable
timer (suitable for clkevent)? Or are you saying that you don't like the
way timers are differentiated on omap?

> 
> >  - 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.  
> 
> Open ended expansion of this does not help convince me it is needed.

It's not an open ended expansion, we're just trying to find a way to
describe which timer blocks should be used as free running timers
(clksource) and which one should be used as programmable timers
(clkevent). Automatically selecting timer blocks to assign to the
clkevent or clocksource is not so easy (as has been explained earlier)
because at the time the system registers its clksource/clkevent devices
we might not have all the necessary information to know which timer
blocks will be reserved for other usage later on. The use case I have
in mind is DT overlays, where one of the overlay is using a timer as a
PWM generator. If the clkevent or clksource has already claimed the
timer connected to the pins the overlay is using, then we're screwed,
and there's no way the system can know that ahead of time except by
pre-assigning a timer to the clksource or clkevent feature.

So really, we need a way to assign a specific timer to a specific
feature. You've refused the different proposals we made so far, so
what's your alternative? I mean a real alternative that solve the "an
auto-selected timer might be claimed by another driver at some point"
problem.

Thanks,

Boris

  reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-13 18:53 [PATCH 0/3] clocksource/drivers: introduce DT based selection Alexandre Belloni
2017-12-13 18:53 ` [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection Alexandre Belloni
2017-12-13 22:57   ` Rob Herring
2017-12-14 20:01     ` Boris Brezillon [this message]
2017-12-14 20:37       ` Boris Brezillon
2017-12-15 11:40       ` Mark Rutland
2017-12-15 12:30         ` Boris Brezillon
2017-12-15 11:32   ` Mark Rutland
2017-12-18 19:46     ` Boris Brezillon
2017-12-16  1:57   ` Grygorii Strashko
2017-12-18 17:12     ` Tony Lindgren
2017-12-19 23:20     ` Rob Herring
2017-12-13 18:53 ` [PATCH 2/3] clocksource/drivers: timer-of: parse the chosen node Alexandre Belloni
2017-12-13 18:53 ` [PATCH 3/3] clocksource/drivers: integrator-ap: " Alexandre Belloni

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171214210120.6b436e0d@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git