[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <30101fb9-e2eb-4050-896a-7be629ced44d@kernel.org>
Date: Tue, 7 Oct 2025 15:35:28 +0900
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Gokul Praveen <g-praveen@...com>, j-keerthy@...com, vigneshr@...com,
wbg@...nel.org, linux-kernel@...r.kernel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org
Cc: u-kumar1@...com, n-francis@...com
Subject: Re: [PATCH 1/2] dt-bindings: counter: Add new ti,omap-dmtimer-cap
compatible
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
Powered by blists - more mailing lists