[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200430140040.GA8363@bogus>
Date: Thu, 30 Apr 2020 09:00:40 -0500
From: Rob Herring <robh@...nel.org>
To: Tony Lindgren <tony@...mide.com>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.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@...r.kernel.org
Subject: Re: [PATCH 02/14] clocksource/drivers/timer-ti-dm: Add clockevent
and clocksource support
On Mon, Apr 27, 2020 at 08:23:29AM -0700, Tony Lindgren wrote:
> * Daniel Lezcano <daniel.lezcano@...aro.org> [200427 15:03]:
> > On 27/04/2020 16:31, Tony Lindgren wrote:
> > > Hi,
> > >
> > > * Daniel Lezcano <daniel.lezcano@...aro.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.
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.
Rob
Powered by blists - more mailing lists