Linux-OMAP Archive on lore.kernel.org
 help / color / Atom feed
From: Rob Herring <robh@kernel.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Keerthy <j-keerthy@ti.com>, Lokesh Vutla <lokeshvutla@ti.com>,
	Tero Kristo <t-kristo@ti.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Nikolaus Schaller" <hns@goldelico.com>,
	Aaro Koskinen <aaro.koskinen@iki.fi>,
	Adam Ford <aford173@gmail.com>,
	Andreas Kemnade <andreas@kemnade.info>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	devicetree@vger.kernel.org, linux-clk <linux-clk@vger.kernel.org>
Subject: Re: [PATCH 02/14] clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support
Date: Fri, 1 May 2020 08:18:31 -0500
Message-ID: <CAL_Jsq+Xqv0JByAK-tYj8aHDhuB5rYrn0NXQxkm97j0P1zqGPg@mail.gmail.com> (raw)
In-Reply-To: <20200430153119.GX37466@atomide.com>

On Thu, Apr 30, 2020 at 10:31 AM Tony Lindgren <tony@atomide.com> wrote:
>
> * Rob Herring <robh@kernel.org> [200430 14:01]:
> > On Mon, Apr 27, 2020 at 08:23:29AM -0700, Tony Lindgren wrote:
> > > * Daniel Lezcano <daniel.lezcano@linaro.org> [200427 15:03]:
> > > > On 27/04/2020 16:31, Tony Lindgren wrote:
> > > > > Hi,
> > > > >
> > > > > * Daniel Lezcano <daniel.lezcano@linaro.org> [200427 09:19]:
> > > > >> On 17/04/2020 18:55, Tony Lindgren wrote:
> > > > >>> --- a/Documentation/devicetree/bindings/timer/ti,timer.txt
> > > > >>> +++ b/Documentation/devicetree/bindings/timer/ti,timer.txt
> > > > >>> @@ -14,6 +14,8 @@ Required properties:
> > > > >>>                       ti,omap5430-timer (applicable to OMAP543x devices)
> > > > >>>                       ti,am335x-timer (applicable to AM335x devices)
> > > > >>>                       ti,am335x-timer-1ms (applicable to AM335x devices)
> > > > >>> +                     ti,dmtimer-clockevent (when used as for clockevent)
> > > > >>> +                     ti,dmtimer-clocksource (when used as for clocksource)
> > > > >>
> > > > >> Please, submit a separate patch for this.
> > > > >>
> > > > >> Before you resend as is, this will be nacked as clocksource / clockevent
> > > > >> is not a hardware description but a Linux thing.
> > > > >>
> > > > >> Finding a way to characterize that from the DT is an endless discussion
> > > > >> since years, so I suggest to use a single property for the timer eg
> > > > >> <ti,dmtimer> and initialize the clocksource and the clockevent in the
> > > > >> driver.
> > > > >
> > > > > Hmm good point. We still need to specify which timer is a clocksource
> > > > > and which one a clockevent somehow.
> > > > >
> > > > > Maybe we could have a generic properties like the clock framework such as:
> > > > >
> > > > > assigned-system-clocksource
> > > > > assigned-system-clockevent
> > > >
> > > > I think that will be the same problem :/
> > >
> > > Seems like other SoCs have the same issue too with multiple timers
> > > to configure.
> > >
> > > > Is it possible to check the interrupt for the clockevent ? A timer node
> > > > with the interrrupt is the clockevent, without it is a clocksource.
> > >
> > > OK let's try that. So the configuration would become then:
> > >
> > > compatible = "ti,dmtimer;   /* reserved for system timers */
> > > /delete-property/interrupts;        /* ok so it's a clocksource */
> > > /delete-property/interrupts-extended;
> >
> > That's not really what was meant.
>
> OK, so let's figure out something better then.
>
> > Let's say you have N timers. Either every timer is exactly the same and
> > the OS can just assign them however it wants or there is some difference
> > in the h/w making certain timer better for certain functions. Describe
> > that difference. It could be clock rate, number of counter bits, always
> > on, secure mode access only, has or doesn't have output compare or input
> > capture, etc.
>
> Hmm. Trying to detect this automatically will get messy. For example,
> we have few omap3 boards with the following options that also need to
> consider if the separate 32KiHz counter is available:
>
> 1. The best case scenario
>
> ti,omap-counter32k clocksource
> ti,sysc-omap2-timer ti,timer-alwon clockevent (timer1)
>
> 2. Boards relying on internal clock with unusable 32k counter
>
> ti,sysc-omap2-timer ti,timer-alwon clocksource (timer12)
> ti,sysc-omap2-timer clockevent (typically gpt2)
>
> In the second case, the 32k counter is unusable, and timer1
> is unusable with the external 32k always on clock. But timer1
> can be used with the system clock just fine for other purposes.
> So ideally we would not tag timer1 as disabled :)

I'm perfectly fine with a 'broken 32k clk' type property.

Though I think the compatibility story is not good changing DT for
stuff needed to boot and needed early in boot. It's one thing to break
something not required to get a system booted.

> For the second case, we could remove ti,timer-alwon property
> for timer1, and tag the 32k counter as disabled as the source
> clock is unreliable. Then somewhere in the code we would need
> to check if ti,omap-counter32k is availabe, then check if
> timer1 is always-on, then use timer12 if not a secure device
> like n900.

IIRC, there's some OMAP timer properties for secure vs. non-secure.
(It's not the first time we've had this discussion on TI timers.)

> If the board wants to use the system clock as the source for
> a higher resolution with assigned-clock-parents, then we'd need
> to ignore the always-on property and not use the 32k counter as
> the clocksource. Basically to somehow figure out that a higher
> resolution configuration is preferred over a
> low-power configuration.

That could be something you want to pick at run-time.

> So what's your take on just adding the generic properties for
> assigned-system-clocksource and clockevent?

I'm tired of discussing this for 10 years...

Rob

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 16:55 [PATCH 00/14] Update omaps to use drivers/clocksource timers Tony Lindgren
2020-04-17 16:55 ` [PATCH 01/14] clocksource/drivers/timer-ti-32k: Add support for initializing directly Tony Lindgren
2020-04-17 16:55 ` [PATCH 02/14] clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support Tony Lindgren
2020-04-27  9:18   ` Daniel Lezcano
2020-04-27 14:31     ` Tony Lindgren
2020-04-27 15:02       ` Daniel Lezcano
2020-04-27 15:23         ` Tony Lindgren
2020-04-30 14:00           ` Rob Herring
2020-04-30 15:31             ` Tony Lindgren
2020-05-01 13:18               ` Rob Herring [this message]
2020-05-01 14:11                 ` Tony Lindgren
2020-04-17 16:55 ` [PATCH 03/14] clk: ti: dm816: enable sysclk6_ck on init Tony Lindgren
2020-04-17 16:55 ` [PATCH 04/14] bus: ti-sysc: Ignore timer12 on secure omap3 Tony Lindgren
2020-04-17 16:55 ` [PATCH 05/14] ARM: OMAP2+: Add omap_init_time_of() Tony Lindgren
2020-04-17 16:55 ` [PATCH 06/14] ARM: dts: Configure system timers for am335x Tony Lindgren
2020-04-17 16:55 ` [PATCH 07/14] ARM: dts: Configure system timers for am437x Tony Lindgren
2020-04-17 16:55 ` [PATCH 08/14] ARM: dts: Configure system timers for omap4 Tony Lindgren
2020-04-17 16:55 ` [PATCH 09/14] ARM: dts: Configure system timers for omap5 and dra7 Tony Lindgren
2020-04-17 16:55 ` [PATCH 10/14] ARM: dts: Configure system timers for omap3 Tony Lindgren
2020-04-17 16:55 ` [PATCH 11/14] ARM: dts: Configure system timers for ti81xx Tony Lindgren
2020-04-17 16:55 ` [PATCH 12/14] ARM: dts: Configure system timers for omap2 Tony Lindgren
2020-04-17 16:55 ` [PATCH 13/14] ARM: OMAP2+: Drop old timer code for dmtimer and 32k counter Tony Lindgren
2020-04-17 16:55 ` [PATCH 14/14] bus: ti-sysc: Timers no longer need legacy quirk handling Tony Lindgren
2020-04-27  7:01 ` [PATCH 00/14] Update omaps to use drivers/clocksource timers Daniel Lezcano
2020-05-07 17:23 [PATCHv3 " Tony Lindgren
2020-05-07 17:23 ` [PATCH 02/14] clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support Tony Lindgren

Reply instructions:

You may reply publicly 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=CAL_Jsq+Xqv0JByAK-tYj8aHDhuB5rYrn0NXQxkm97j0P1zqGPg@mail.gmail.com \
    --to=robh@kernel.org \
    --cc=aaro.koskinen@iki.fi \
    --cc=aford173@gmail.com \
    --cc=andreas@kemnade.info \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hns@goldelico.com \
    --cc=j-keerthy@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    --cc=t-kristo@ti.com \
    --cc=tglx@linutronix.de \
    --cc=tony@atomide.com \
    /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

Linux-OMAP Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-omap/0 linux-omap/git/0.git

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

Example config snippet for mirrors

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


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