Re: [PATCH 1/2] dt-bindings: counter: Add new ti,omap-dmtimer-cap compatible
From: Gokul Praveen
Date: Tue Oct 07 2025 - 05:49:41 EST
Hi Krzysztof,
On 07/10/25 15:09, Krzysztof Kozlowski wrote:
On 07/10/2025 18:23, Gokul Praveen wrote: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?
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.
It would be great to hear your feedback on this, krzysztof.
Best regards
Gokul
Best regards,
Krzysztof