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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/17/23 16:27, Rob Herring wrote:
On Fri, Mar 17, 2023 at 4:59 AM Cristian Ciocaltea
<cristian.ciocaltea@xxxxxxxxxxxxx> 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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux