Re: [PATCH 01/11] dt-bindings: firmware: arm,scmi: Document assigned-clocks and assigned-clock-rates

From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
To: Rob Herring <robh@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Nicolas Frattaroli <frattaroli.nicolas@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Daniel Drake <drake@endlessm.com>,
	Katsuhiro Suzuki <katsuhiro@katsuster.net>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
	alsa-devel@alsa-project.org, linux-rockchip@lists.infradead.org,
	linux-riscv@lists.infradead.org, kernel@collabora.com
Subject: Re: [PATCH 01/11] dt-bindings: firmware: arm,scmi: Document assigned-clocks and assigned-clock-rates
Date: Fri, 17 Mar 2023 19:21:03 +0200	[thread overview]
Message-ID: <793d6c43-d71e-3ffc-17c2-26062e40b4bc@collabora.com> (raw)
In-Reply-To: <CAL_JsqL_EogoKOQ1xwU75=rJSC4o7yV3Jej4vadtacX2Pt3-hw@mail.gmail.com>

On 3/17/23 16:27, Rob Herring wrote:
> On Fri, Mar 17, 2023 at 4:59 AM Cristian Ciocaltea
> <cristian.ciocaltea@collabora.com> wrote:
>>
>> On 3/17/23 00:26, Sudeep Holla wrote:
>>> On Thu, Mar 16, 2023 at 03:34:17PM -0500, Rob Herring wrote:
>>>> +Stephen
>>>>
>>>> On Wed, Mar 15, 2023 at 01:47:56PM +0200, Cristian Ciocaltea wrote:
>>>>> Since commit df4fdd0db475 ("dt-bindings: firmware: arm,scmi: Restrict
>>>>> protocol child node properties") the following dtbs_check warning is
>>>>> shown:
>>>>>
>>>>>     rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
>>>>
>>>> I think that's a somewhat questionable use of assigned-clock-rates. It
>>>> should be located with the consumer rather than the provider IMO. The
>>>> consumers of those 2 clocks are the CPU nodes.
>>>>
>>>
>>> Agreed. We definitely don't use those in the scmi clk provider driver.
>>> So NACK for the generic SCMI binding change.
>>
>> According to [1], "configuration of common clocks, which affect multiple
>> consumer devices can be similarly specified in the clock provider node".
> 
> True, but in this case it's really a single consumer because it's all
> CPU nodes which are managed together.
> 
>> That would avoid duplicating assigned-clock-rates in the CPU nodes.
> 
> Wouldn't one node be sufficient?

Yeah, that should be fine.

> Thinking more about this, why aren't you using OPP tables to define
> CPU frequencies. Assigned-clocks looks like a temporary hack because
> you haven't done proper OPP tables.

Right, this is currently not possible since it depends on some work in 
progress.

Thanks,
Cristian