On Tue, Sep 22, 2026 at 10:01:09AM +0200, Igor Paunovic wrote: > The three NPU cores on the RK3588 are fed by a single clock and a single > supply, and the firmware accepts a fixed set of rates for that clock. > Describing those rates as an operating-points-v2 table is what lets a > driver scale the NPU instead of leaving it at whatever rate the bootloader > set, so allow the property on the core node. > > Throttling the NPU from a thermal zone needs a core node to be usable as > a cooling device, so allow #cooling-cells too. > > The OPP table belongs on every core, with opp-shared: the cores have no > clock of their own, and one shared table for one shared clock is the same > shape a CPU cluster uses. #cooling-cells goes on one core only, the one a > thermal zone's cooling map names, because the cores cannot be throttled > independently. Naming one representative node for a shared frequency > domain is the established shape, as in "Cpufreq cooling device on CPU0" > in Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml. > > The schema cannot enforce which core carries #cooling-cells, because all > three cores share a compatible string and a node name pattern, so that > stays a devicetree convention. That is the same situation as for CPU > cooling, where cpus.yaml does not restrict #cooling-cells to cpu@0 > either. > > The example gains #cooling-cells; the operating-points-v2 property is > exercised by the RK3588 devicetree later in this series. > > Assisted-by: LLM checkpatch dt_binding_check
Drop 'dt_binding_check'. That's expected/assumed. > Signed-off-by: Igor Paunovic <[email protected]> > Acked-by: Conor Dooley <[email protected]>
