Re: [PATCH v6 5/6] arm64: dts: qcom: Add device tree for Nord Ride board

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 7/20/26 6:20 AM, Shawn Guo wrote:
> On Thu, Jul 16, 2026 at 07:14:56PM +0200, Konrad Dybcio wrote:
>> On 7/16/26 4:26 PM, Shawn Guo wrote:
>>> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>>>
>>> Add initial device tree for the Qualcomm SA8797P Ride reference board,
>>> which is built on Nord GearVM variant.

[...]

>>> +&scmi15 {
>>> +	status = "okay";
>>> +};
>>> +
>>> +&scmi23 {
>>> +	status = "okay";
>>> +};
>>
>> Why only these ones? Can all of the SCMI servers be enabled?
> 
> These are the ones that have actual/enabled client/consumer devices,
> e.g. scmi3 for ufs, scmi11 for uart, scmi23 for thermal sensors.

We normally refrain from enabling resources in the DT only because the
OS (really just Linux) doesn't have the necessary support to cope with
the ""complete"" system description. In this case, there's a firmware
layer drives everything and handles on/off requests gracefully
(hopefully).

> We can enable all the SCMI servers, but I'm afraid that cause kernel
> to map shared memory and issue SMC calls to discover protocols (like
> power domains, DVFS, resets) that have no consumers, which might waste
> a small amount of memory and boot time.

Please give it a shot and see if there's any immediate
problems.

Big SoC requires big init times. Thankfully it also happens to be
fast so it evens out. Maybe we can look into doing async probe for
the related drivers.

My understanding is that most of these SCMI servers are actually
already bound to managing some hardware (or will be in a fw update),
but not all of them have the drivers to utilize that yet. Is that
the case?

Konrad