[PATCH 4/7] dt-bindings: chosen: Add clocksource and clockevent selection
sudeep.holla at arm.com
Tue Sep 10 08:08:26 PDT 2019
On Tue, Sep 10, 2019 at 02:51:50PM +0000, Claudiu.Beznea at microchip.com wrote:
> On 10.09.2019 17:32, Sudeep Holla wrote:
> > External E-Mail
> > On Tue, Sep 10, 2019 at 04:47:13PM +0300, Claudiu Beznea wrote:
> >> From: Alexandre Belloni <alexandre.belloni at bootlin.com>
> >> Some timer drivers may behave either as clocksource or clockevent
> >> or both. Until now, in case of platforms with multiple hardware
> >> resources of the same type, the drivers were chosing the first
> >> registered hardware resource as clocksource/clockevent and the
> >> next one as clockevent/clocksource. Other were using different
> >> compatibles (one for each functionality, although its about the
> >> same hardware). Add DT bindings to be able to choose the
> >> functionality of a timer.
> > Is the piece of hardware not capable of serving as both clocksource
> > and clockevent or is it just the platform choice ?
> In my case, the hardware is not capable of serving at the same time
> a clocksource device and a clockevent device.
> First, I published v1 for a hardware device having this behavior at
>  requesting 1st probed hardware device to work as clocksource and
> the 2nd one to work as clockevent. The discussion at  ended up with
> the idea of having a mechanism to specify which hardware device behaves
> as clocksource and which one behaves as clockevent.
In that case, why can't we identify capability that with the compatibles
for this timer IP ?
IOW, I don't like the proposal as it's hardware limitation.
More information about the linux-amlogic