Message-ID: <c5ace95c-6ba1-4ce9-b461-82225a9fc576@oss.qualcomm.com>
Date: Fri, 30 Jan 2026 12:33:48 +0530
From: Gaurav Kohli <gaurav.kohli@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>, mathieu.poirier@...aro.org,
        robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
        rafael@...nel.org, daniel.lezcano@...aro.org, rui.zhang@...el.com,
        lukasz.luba@....com, konradybcio@...nel.org, amitk@...nel.org,
        mani@...nel.org, casey.connolly@...aro.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices


On 1/28/2026 3:15 PM, Konrad Dybcio wrote:
> On 1/28/26 10:39 AM, Gaurav Kohli wrote:
>> On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
>>> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
>>>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
>>>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>>>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>>>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>>>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>>>>>>>> From: Casey Connolly <casey.connolly@...aro.org>
>>>>>>>>>
>>>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
>>>>>>>>> remoteproc children with of_platform_populate(). This will be used to
>>>>>>>>> enable support for devices which are best represented as
>>>>>>>>> subnodes of the
>>>>>>>>> remoteproc, such as those representing QMI clients.
>>>>>>>> Please flip this around, start with the description of the problem
>>>>>>>> you're trying to solve.
>>>>>>>>
>>>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@...aro.org>
>>>>>>>> This must have your signed-off-by, where you certifies the origin of
>>>>>>>> this patch.
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>      drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>>>>>>>      drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>>>>>>>      2 files changed, 4 insertions(+), 8 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>> @@ -6,6 +6,7 @@
>>>>>>>>>       * Copyright (C) 2014 Sony Mobile Communications AB
>>>>>>>>>       * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>>>>>>>> reserved.
>>>>>>>>>       */
>>>>>>>>> +#include <linux/of_platform.h>
>>>>>>>>>      #include <linux/kernel.h>
>>>>>>>>>      #include <linux/platform_device.h>
>>>>>>>>>      #include <linux/interconnect.h>
>>>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>>>>>>>> struct platform_device *pdev,
>>>>>>>>>              return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>>>>>>>                           "failed to acquire interconnect path\n");
>>>>>>>>>      +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>>>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
>>>>>>>> Do we really want platform_devices registered for them?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Bjorn
>>>>>>> thanks for pointing this, can you please suggest the right approach.
>>>>>>>
>>>>>>> This should not impact glink, as that is registering as rproc sub node,
>>>>>>> And we need rproc cooling as child node
>>>>>>>
>>>>>>> of remote proc subsytem to create probe dependency only.
>>>>>>>
>>>>>>>
>>>>>>> Can we do platform populate for specific child, would that be right
>>>>>>> approach. or we should create rproc cooling as independent of parent ?
>>>>>>>
>>>>>> HI Bjorn,
>>>>>>
>>>>>> I’d like to highlight the impact and details of placement of remoteproc
>>>>>> cooling dt node:
>>>>>>
>>>>>>
>>>>>> ->As a child of the remote proc subsystem node:
>>>>>>        In this configuration, the cooling device will only be probed once the
>>>>>> corresponding remote proc subsystem itself is probed.
>>>>>>
>>>>>> ->Outside the remote proc subsystem, may be part of soc node:
>>>>>>        In this setup, the cooling device will be probed independently. It will
>>>>>> wait until the remoteproc subsystem is brought up
>>>>>>        before completing cooling registration.
>>>>>>        The drawback here is that if the parent remoteproc subsystem is
>>>>>> disabled, the cooling device will still undergo an
>>>>>>        unnecessary probe, even though it cannot be registered.
>>>>> Bjorns question was different. It wasn't about pushing cooling device
>>>>> outside of the remoteproc node. It is about not registering the devices.
>>>>>
>>>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
>>>>> qcom_add_glink_subdev()?
>>>> Hi Dmitry,
>>>>
>>>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
>>>> it will receive the
>>>> subsystem up notification directly. Therefore, there’s no need to make it a
>>>> subdev node or
>>>> tie it into the init/reset sequence of remoteproc subsytem.
>>> But you've added a subnode for it (and we are discussing exactly
>>> of_platform_populate()) call. So, you are tying it to the remoteproc
>>> device lifecycle instead of the remoteproc subsys, which seems strange
>>> to me. There is no cooling device if the DSP is not running.
>>
>> For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only
>> after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server.
>>
>>
>> If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc.
>> Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?
> I think the question is "why can't you register the remoteproc device
> as a cooling_device, with perhaps #cooling-cells = <1>; instead of
> any form of children?"
>
> Konrad


thanks Konrad, for the review.

As each subsystem can expose multiple thermal mitigation devices via the 
remoteproc TMD service, so need to define child node.

Powered by blists - more mailing lists