[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d009e0b2-2906-4436-b6a6-c24fecce9298@kernel.org>
Date: Mon, 18 Aug 2025 08:31:02 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Aaron Kling <webgeek1234@...il.com>
Cc: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>, Joseph Lo <josephl@...dia.com>,
Peter De Schrijver <pdeschrijver@...dia.com>,
Prashant Gaikwad <pgaikwad@...dia.com>, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org, Thierry Reding <treding@...dia.com>
Subject: Re: [PATCH 1/5] dt-bindings: clock: tegra124-dfll: Add property to
limit frequency
On 18/08/2025 05:23, Aaron Kling wrote:
>>>
>>> +Optional properties for limiting frequency:
>>> +- nvidia,dfll-max-freq: Maximum scaling frequency.
>>
>>
>> 1. Frequency is in units.
> Ack, will fix in whatever form a new revision takes.
>
>> 2. OPP defines it already, doesn't it?
> The dfll driver generates the cpu opp table based on soc sku's, it
> doesn't use dt opp tables. This property is intended to modify the
> generation of said table. That said, if there's a generic dt opp
> paradigm for this that I missed which works without dt opp tables, I'd
> be happy to use that instead.
Usually list of frequencies is via OPP, if it is not applicable here, it
should be explained briefly.
Just like - why same devices have different values should be explained
(commit msg is not precise here).
Best regards,
Krzysztof
Powered by blists - more mailing lists