From: David Lechner <david@lechnology.com>
To: Judith Mendez <jm@ti.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
William Breathitt Gray <william.gray@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [PATCH v2 2/8] dt-bindings: counter: Add new ti,am62-eqep compatible
Date: Sat, 25 May 2024 12:49:31 -0500 [thread overview]
Message-ID: <55a21233-918f-4cf4-800c-3e0eee0cd467@lechnology.com> (raw)
In-Reply-To: <2339db0d-db21-4372-808d-8648500e971a@ti.com>
On 5/24/24 4:44 PM, Judith Mendez wrote:
> On 5/24/24 3:57 PM, David Lechner wrote:
>> On 5/24/24 3:50 PM, David Lechner wrote:
>>> On 5/23/24 6:15 PM, Judith Mendez wrote:
>>>> Add new compatible ti,am62-eqep for TI K3 devices. If a device
>>>> uses this compatible, require power-domains property.
>>>>
>>>> Since there is only one functional and interface clock for eqep,
>>>> clock-names is not really required. The clock-name also changed
>>>> for TI K3 SoCs so make clock-names optional for the new compatible
>>>> since there is only one clock that is routed to the IP.
>>>>
>>>> While we are here, add an example using ti,am62-eqep compatible.
>>>>
>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>> ---
>>>> Changes since v1:
>>>> - Fix eqep binding for new compatible, require
>>>> power-domains for new compatible
>>>> ---
>>>> .../devicetree/bindings/counter/ti-eqep.yaml | 53 +++++++++++++++++--
>>>> 1 file changed, 48 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/counter/ti-eqep.yaml b/Documentation/devicetree/bindings/counter/ti-eqep.yaml
>>>> index 85f1ff83afe72..c4bb0231f166a 100644
>>>> --- a/Documentation/devicetree/bindings/counter/ti-eqep.yaml
>>>> +++ b/Documentation/devicetree/bindings/counter/ti-eqep.yaml
>>>> @@ -11,7 +11,9 @@ maintainers:
>>>> properties:
>>>> compatible:
>>>> - const: ti,am3352-eqep
>>>> + enum:
>>>> + - ti,am3352-eqep
>>>> + - ti,am62-eqep
>>>> reg:
>>>> maxItems: 1
>>>> @@ -21,19 +23,43 @@ properties:
>>>> maxItems: 1
>>>> clocks:
>>>> - description: The clock that determines the SYSCLKOUT rate for the eQEP
>>>> - peripheral.
>>>> + description: The functional and interface clock that determines the clock
>>>> + rate for the eQEP peripheral.
>>>> maxItems: 1
>>>> clock-names:
>>>> - const: sysclkout
>>>> + enum:
>>>> + - sysclkout
>>>> + - fck
>>>> +
>>>
>>> If we are making this optional for ti,am62-eqep, why add a new name?
>>>
>>> Also, we could change the description to say that sysclockout is not a
>>> great name but is required for backwards compatibility.
>>>
>>>> + power-domains:
>>>> + maxItems: 1
>>>> +
>>>> +allOf:
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + enum:
>>>> + - ti,am3352-eqep
>>>> + then:
>>>> + required:
>>>> + - clock-names
>>
>> I just looked at the Linux driver for this and the clock name is
>> not used in the driver. So we could probably just deprecate the
>> clock-names property here and not make it required for
>> ti,am3352-eqep (and not allowed for any new compatibles as
>> suggested below).
>
> We could do this, although I was under the impression that we should
> not drop DT properties just because the linux driver isn't using it,
> that is why I went with keeping clock-names around for am335x compatible
> and making it optional for am62x compatible.
>
> But if it is all the same, we could drop the the DT property.
>
> ~ Judith
>
I wasn't suggesting to remove clock-names from the bindings, just
deprecate that property in this binding and not use it with any
new compatibles.
In the AM62x technical reference manual, it looks like it calls
the functional and interface clock FICLK rather than FCK. So
I'm just suggesting maybe it just easier to not give it a name
rather than try to get the right name? No name will work with
any future SoCs as well. :-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-05-25 17:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 23:15 [PATCH v2 0/8] Enable eQEP DT support for Sitara K3 platforms Judith Mendez
2024-05-23 23:15 ` [PATCH v2 1/8] counter/ti-eqep: Add new ti-am62-eqep compatible Judith Mendez
2024-05-24 21:18 ` David Lechner
2024-05-23 23:15 ` [PATCH v2 2/8] dt-bindings: counter: Add new ti,am62-eqep compatible Judith Mendez
2024-05-24 18:38 ` Conor Dooley
2024-05-24 21:30 ` Judith Mendez
2024-05-25 15:23 ` Conor Dooley
2024-05-29 17:19 ` Judith Mendez
2024-05-24 20:50 ` David Lechner
2024-05-24 20:57 ` David Lechner
2024-05-24 21:44 ` Judith Mendez
2024-05-25 17:49 ` David Lechner [this message]
2024-05-29 18:54 ` Judith Mendez
2024-05-24 21:33 ` Judith Mendez
2024-05-23 23:15 ` [PATCH v2 3/8] arm64: dts: ti: k3-am62-main: Add eQEP nodes Judith Mendez
2024-05-23 23:15 ` [PATCH v2 4/8] arm64: dts: ti: k3-am62a-main: " Judith Mendez
2024-05-23 23:15 ` [PATCH v2 5/8] arm64: dts: ti: k3-am62p-main: " Judith Mendez
2024-05-23 23:15 ` [PATCH v2 6/8] arm64: dts: ti: k3-am64-main: " Judith Mendez
2024-05-23 23:15 ` [PATCH v2 7/8] counter: ti-eqep: Allow eQEP driver to be built for K3 devices Judith Mendez
2024-05-24 21:07 ` David Lechner
2024-05-23 23:15 ` [PATCH v2 8/8] arm64: defconfig: Enable TI eQEP Driver Judith Mendez
2024-05-24 5:59 ` Nishanth Menon
2024-05-24 14:13 ` Judith Mendez
2024-05-30 15:31 ` Judith Mendez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55a21233-918f-4cf4-800c-3e0eee0cd467@lechnology.com \
--to=david@lechnology.com \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jm@ti.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=robh@kernel.org \
--cc=vigneshr@ti.com \
--cc=will@kernel.org \
--cc=william.gray@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox