Date:   Fri, 1 May 2020 07:11:38 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Keerthy <j-keerthy@...com>, Lokesh Vutla <lokeshvutla@...com>,
        Tero Kristo <t-kristo@...com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Nikolaus Schaller" <hns@...delico.com>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Adam Ford <aford173@...il.com>,
        Andreas Kemnade <andreas@...nade.info>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, devicetree@...r.kernel.org,
        linux-clk <linux-clk@...r.kernel.org>
Subject: Re: [PATCH 02/14] clocksource/drivers/timer-ti-dm: Add clockevent
 and clocksource support

* Rob Herring <robh@...nel.org> [200501 13:19]:
> On Thu, Apr 30, 2020 at 10:31 AM Tony Lindgren <tony@...mide.com> wrote:
> > 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.

OK. Maybe "unreliable-oscillator" type property or something like
that. Or maybe "shrodingers-cat-oscillator" :)

> 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 boards with the 32k clock issue the system boots but
is unreliable. I'm not sure how long a 32k clock based timer would
have to be monitored with another system clock based timer to
detect it.. I recall the issues start popping up with PM and
that much later and the system clock may not even be active..

Anyways, the issue is related to how the board is wired, so a
property for it makes sense here.

> > 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.)

Yes.

> > 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.

OK

> > 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...

Well luckly most system have basic timers integrated nowadays
rather than each SoC vendor doing their own timers :)

Regards,

Tony

Powered by blists - more mailing lists