From: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx>
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.
Signed-off-by: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx>
Signed-off-by: Claudiu Beznea <claudiu.beznea@xxxxxxxxxxxxx>
---
Documentation/devicetree/bindings/chosen.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 45e79172a646..aad3034cdbdf 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -135,3 +135,23 @@ e.g.
linux,initrd-end = <0x82800000>;
};
};
+
+linux,clocksource and linux,clockevent
+--------------------------------------
+
+Those nodes have a timer property. This property is a phandle to the timer to be
+chosen as the clocksource or clockevent. This is only useful when the platform
+has multiple identical timers and it is not possible to let linux make the
+correct choice.
+
+/ {
+ chosen {
+ linux,clocksource {
+ timer = <&timer0>;
+ };
+
+ linux,clockevent {
+ timer = <&timer1>;
+ };
+ };
+};
--
2.7.4
