This commit adds a YAML binding for OMAP DM timer used in
capture operating mode.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
.../bindings/counter/ti,omap-dmtimer-cap.yaml | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
diff --git a/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml b/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
new file mode 100644
index 000000000000..8de9cf58aee5
--- /dev/null
+++ b/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/counter/ti,omap-dmtimer-cap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI dual mode timer Capture Module
+
+maintainers:
+ - Gokul Praveen <g-praveen@ti.com>
+
+description:
+ TI dual mode timer instances have an IO pin for Capture capability.
+
+properties:
+ compatible:
+ const: ti,omap-dmtimer-cap
+
+ ti,timers:
+ description: Timer instance phandle for the Capture
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - ti,timers
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ main_cap10: dmtimer-main-cap-10 {
+ compatible = "ti,omap-dmtimer-cap";
+ ti,timers = <&main_timer10>;
+ };
--
2.34.1On 09/09/2025 10:00, Gokul Praveen wrote:
> This commit adds a YAML binding for OMAP DM timer used in
Please do not use "This commit/patch/change", but imperative mood. See
longer explanation here:
https://elixir.bootlin.com/linux/v6.16/source/Documentation/process/submitting-patches.rst#L94
Don't use "YAML binding" - there is no such thing.
Instead just describe the hardware.
> capture operating mode.
>
> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
> ---
> .../bindings/counter/ti,omap-dmtimer-cap.yaml | 34 +++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
>
> diff --git a/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml b/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
> new file mode 100644
> index 000000000000..8de9cf58aee5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
> @@ -0,0 +1,34 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/counter/ti,omap-dmtimer-cap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI dual mode timer Capture Module
> +
> +maintainers:
> + - Gokul Praveen <g-praveen@ti.com>
> +
> +description:
> + TI dual mode timer instances have an IO pin for Capture capability.
> +
> +properties:
> + compatible:
> + const: ti,omap-dmtimer-cap
Missing SoC specific part. OMAP is family, no?
> +
> + ti,timers:
> + description: Timer instance phandle for the Capture
So the only resource is phandle? That's completely fake device then. NAK.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> +required:
> + - compatible
> + - ti,timers
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + main_cap10: dmtimer-main-cap-10 {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).
Best regards,
Krzysztof
Hi Krzysztof,
Really sorry and apologies for the delay.
On 10/09/25 12:38, Krzysztof Kozlowski wrote:
> On 09/09/2025 10:00, Gokul Praveen wrote:
>> This commit adds a YAML binding for OMAP DM timer used in
>
> Please do not use "This commit/patch/change", but imperative mood. See
> longer explanation here:
> https://elixir.bootlin.com/linux/v6.16/source/Documentation/process/submitting-patches.rst#L94
>
> Don't use "YAML binding" - there is no such thing.
>
> Instead just describe the hardware.
>
Sure Krzysztof.
>> capture operating mode.
>>
>> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
>> ---
>> .../bindings/counter/ti,omap-dmtimer-cap.yaml | 34 +++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml b/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
>> new file mode 100644
>> index 000000000000..8de9cf58aee5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/counter/ti,omap-dmtimer-cap.yaml
>> @@ -0,0 +1,34 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/counter/ti,omap-dmtimer-cap.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI dual mode timer Capture Module
>> +
>> +maintainers:
>> + - Gokul Praveen <g-praveen@ti.com>
>> +
>> +description:
>> + TI dual mode timer instances have an IO pin for Capture capability.
>> +
>> +properties:
>> + compatible:
>> + const: ti,omap-dmtimer-cap
>
> Missing SoC specific part. OMAP is family, no?
>
>> +
>> + ti,timers:
>> + description: Timer instance phandle for the Capture
>
> So the only resource is phandle? That's completely fake device then. NAK.
>
The OMAP Timer IP can operate in 3 modes: Timer, PWM mode or capture
(mutually exclusive).
The timer/ti,timer-dm.yaml file describes the timer mode of operation.
It encapsulates base IP block and reg property is also part the same
binding.
This node represents the capture mode with phandle reference to the
timer DT node. This is modeled all the same lines as how PWM
functionality is implemented in pwm/ti,omap-dmtimer-pwm.yaml
Now, if this needs to change, please suggest alternate.
One solution is perhaps to add a new property to ti,timer-dm.yaml itself
to indicate the mode of IP?
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> +required:
>> + - compatible
>> + - ti,timers
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + main_cap10: dmtimer-main-cap-10 {
>
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> If you cannot find a name matching your device, please check in kernel
> sources for similar cases or you can grow the spec (via pull request to
> DT spec repo).
>
>
Sure, I will update that Krzysztof.
Regards
Gokul
> Best regards,
> Krzysztof
On 26/09/2025 18:06, Gokul Praveen wrote: >> >>> + >>> + ti,timers: >>> + description: Timer instance phandle for the Capture >> >> So the only resource is phandle? That's completely fake device then. NAK. >> > > > The OMAP Timer IP can operate in 3 modes: Timer, PWM mode or capture > (mutually exclusive). > The timer/ti,timer-dm.yaml file describes the timer mode of operation. > It encapsulates base IP block and reg property is also part the same > binding. > > This node represents the capture mode with phandle reference to the > timer DT node. This is modeled all the same lines as how PWM > functionality is implemented in pwm/ti,omap-dmtimer-pwm.yaml Different modes do not have their own device nodes. It is still one device, so one device node. > > Now, if this needs to change, please suggest alternate. > > One solution is perhaps to add a new property to ti,timer-dm.yaml itself > to indicate the mode of IP? Not sure, depends what this really is and how it is used. I can also imagine that consumer defines the mod of operation. Or mode of operation could be even configured runtime, thus not suitable for DT at all. Best regards, Krzysztof
Hi Krzysztof,
On 07/10/25 12:05, Krzysztof Kozlowski wrote:
> On 26/09/2025 18:06, Gokul Praveen wrote:
>>>
>>>> +
>>>> + ti,timers:
>>>> + description: Timer instance phandle for the Capture
>>>
>>> So the only resource is phandle? That's completely fake device then. NAK.
>>>
>>
>>
>> The OMAP Timer IP can operate in 3 modes: Timer, PWM mode or capture
>> (mutually exclusive).
>> The timer/ti,timer-dm.yaml file describes the timer mode of operation.
>> It encapsulates base IP block and reg property is also part the same
>> binding.
>>
>> This node represents the capture mode with phandle reference to the
>> timer DT node. This is modeled all the same lines as how PWM
>> functionality is implemented in pwm/ti,omap-dmtimer-pwm.yaml
>
> Different modes do not have their own device nodes. It is still one
> device, so one device node.
>
>>
>> Now, if this needs to change, please suggest alternate.
>>
>> One solution is perhaps to add a new property to ti,timer-dm.yaml itself
>> to indicate the mode of IP?
>
> Not sure, depends what this really is and how it is used. I can also
> imagine that consumer defines the mod of operation.
>
For a timer operating in capture mode, there are no consumers actually
and the only way we use it is through sysfs.
Would it be good enough if I have a separate "mode" property for the
dmtimer device node just like how it is done for USB as follows where
the usb device node has a "dr_mode" property to decide on whether the
usb should act in host, device or otg mode.
&usb0 {
status = "okay";
dr_mode = "host";
};
> Or mode of operation could be even configured runtime, thus not suitable
> for DT at all.
>
> Best regards,
> Krzysztof
On 07/10/2025 18:23, Gokul Praveen wrote: > Hi Krzysztof, > > > On 07/10/25 12:05, Krzysztof Kozlowski wrote: >> On 26/09/2025 18:06, Gokul Praveen wrote: >>>> >>>>> + >>>>> + ti,timers: >>>>> + description: Timer instance phandle for the Capture >>>> >>>> So the only resource is phandle? That's completely fake device then. NAK. >>>> >>> >>> >>> The OMAP Timer IP can operate in 3 modes: Timer, PWM mode or capture >>> (mutually exclusive). >>> The timer/ti,timer-dm.yaml file describes the timer mode of operation. >>> It encapsulates base IP block and reg property is also part the same >>> binding. >>> >>> This node represents the capture mode with phandle reference to the >>> timer DT node. This is modeled all the same lines as how PWM >>> functionality is implemented in pwm/ti,omap-dmtimer-pwm.yaml >> >> Different modes do not have their own device nodes. It is still one >> device, so one device node. >> >>> >>> Now, if this needs to change, please suggest alternate. >>> >>> One solution is perhaps to add a new property to ti,timer-dm.yaml itself >>> to indicate the mode of IP? >> >> Not sure, depends what this really is and how it is used. I can also >> imagine that consumer defines the mod of operation. >> > > For a timer operating in capture mode, there are no consumers actually > and the only way we use it is through sysfs. > > Would it be good enough if I have a separate "mode" property for the > dmtimer device node just like how it is done for USB as follows where > the usb device node has a "dr_mode" property to decide on whether the > usb should act in host, device or otg mode. No, because of all my other comments in previous email. Best regards, Krzysztof
Hi Krzysztof, On 07/10/25 15:09, Krzysztof Kozlowski wrote: > On 07/10/2025 18:23, Gokul Praveen wrote: >> Hi Krzysztof, >> >> >> On 07/10/25 12:05, Krzysztof Kozlowski wrote: >>> On 26/09/2025 18:06, Gokul Praveen wrote: >>>>> >>>>>> + >>>>>> + ti,timers: >>>>>> + description: Timer instance phandle for the Capture >>>>> >>>>> So the only resource is phandle? That's completely fake device then. NAK. >>>>> >>>> >>>> >>>> The OMAP Timer IP can operate in 3 modes: Timer, PWM mode or capture >>>> (mutually exclusive). >>>> The timer/ti,timer-dm.yaml file describes the timer mode of operation. >>>> It encapsulates base IP block and reg property is also part the same >>>> binding. >>>> >>>> This node represents the capture mode with phandle reference to the >>>> timer DT node. This is modeled all the same lines as how PWM >>>> functionality is implemented in pwm/ti,omap-dmtimer-pwm.yaml >>> >>> Different modes do not have their own device nodes. It is still one >>> device, so one device node. >>> >>>> >>>> Now, if this needs to change, please suggest alternate. >>>> >>>> One solution is perhaps to add a new property to ti,timer-dm.yaml itself >>>> to indicate the mode of IP? >>> >>> Not sure, depends what this really is and how it is used. I can also >>> imagine that consumer defines the mod of operation. >>> >> >> For a timer operating in capture mode, there are no consumers actually >> and the only way we use it is through sysfs. >> >> Would it be good enough if I have a separate "mode" property for the >> dmtimer device node just like how it is done for USB as follows where >> the usb device node has a "dr_mode" property to decide on whether the >> usb should act in host, device or otg mode. > > > No, because of all my other comments in previous email. > > Will having a separate sysfs property for enabling capture mode in dmtimer be a viable solution, which will then eliminate the need for a device tree property? It would be great to hear your feedback on this, krzysztof. Best regards Gokul > Best regards, > Krzysztof
On 07/10/2025 18:49, Gokul Praveen wrote: > Hi Krzysztof, > > On 07/10/25 15:09, Krzysztof Kozlowski wrote: >> On 07/10/2025 18:23, Gokul Praveen wrote: >>> Hi Krzysztof, >>> >>> >>> On 07/10/25 12:05, Krzysztof Kozlowski wrote: >>>> On 26/09/2025 18:06, Gokul Praveen wrote: >>>>>> >>>>>>> + >>>>>>> + ti,timers: >>>>>>> + description: Timer instance phandle for the Capture >>>>>> >>>>>> So the only resource is phandle? That's completely fake device then. NAK. >>>>>> >>>>> >>>>> >>>>> The OMAP Timer IP can operate in 3 modes: Timer, PWM mode or capture >>>>> (mutually exclusive). >>>>> The timer/ti,timer-dm.yaml file describes the timer mode of operation. >>>>> It encapsulates base IP block and reg property is also part the same >>>>> binding. >>>>> >>>>> This node represents the capture mode with phandle reference to the >>>>> timer DT node. This is modeled all the same lines as how PWM >>>>> functionality is implemented in pwm/ti,omap-dmtimer-pwm.yaml >>>> >>>> Different modes do not have their own device nodes. It is still one >>>> device, so one device node. >>>> >>>>> >>>>> Now, if this needs to change, please suggest alternate. >>>>> >>>>> One solution is perhaps to add a new property to ti,timer-dm.yaml itself >>>>> to indicate the mode of IP? >>>> >>>> Not sure, depends what this really is and how it is used. I can also >>>> imagine that consumer defines the mod of operation. >>>> >>> >>> For a timer operating in capture mode, there are no consumers actually >>> and the only way we use it is through sysfs. >>> >>> Would it be good enough if I have a separate "mode" property for the >>> dmtimer device node just like how it is done for USB as follows where >>> the usb device node has a "dr_mode" property to decide on whether the >>> usb should act in host, device or otg mode. >> >> >> No, because of all my other comments in previous email. >> >> > Will having a separate sysfs property for enabling capture mode in > dmtimer be a viable solution, which will then eliminate the need for a > device tree property? > > It would be great to hear your feedback on this, krzysztof. Could be, if this can be a runtime property. My questions and doubts are indeed not a very clear guidance, partially because I don't know all use cases for this hardware. Lack of PWM consumer is already an indication for the driver to configure it in other mode, for example. But think rather why choice of mode would be board-level static configuration. If you cannot answer that, then it should not be a DT property most likely. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.