From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2BC6B200110 for ; Sat, 31 Jan 2026 10:12:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769854330; cv=none; b=VDc68xABvRZ36RA2xBtXsctgSB+m+NLUOYdLL7MsTqPUjZZrQzXcoW20obL8gQtvkTfSI8OsmM/cvglkV1H2wgvBapTWqrYcnyi4JTWFcRHkYU0eMt/srwAb7XnJFqfiorGUDFhVb2f6Pr5BJvdSuNsWyBHSFyK5rsOQADwON0o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769854330; c=relaxed/simple; bh=VEAe+X0FB9vXgAIQSobQOgIUGriG07alQ3j6JuJdLgU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=t6JBATVpRUKr7+xeY+wqZvdyESi6HZTlNUvw0Avw2H6givEqx7Ae1E0OwsL03OV9pHfbTHFonKqZxfB4Ry73jzlRjTN/PjukgUwi1Ya3kecZCq62GDcqi060Uv1tSAb6GkkzTcxhh555VI2p3BQcu/nsosDz7TnFrAdFcCmSyyA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=CXjeDBOr; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=c+JfPaxy; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="CXjeDBOr"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="c+JfPaxy" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60V4cvqk4076780 for ; Sat, 31 Jan 2026 10:12:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= 6puvbklaTf3KTbyOtju0g8M5/JWaZ7LLZ6JZVfLJvCM=; b=CXjeDBOrd+YGpxtH 3vqNNlm00ThaO1HBbWg5w5Q1NKvSA8z1TZ62ZCM24X1crs+9MAIPKzIhJz8XXv3L D4hK5vix0F+kVlllUa3CoBI8pP0LQ/Wsp1Z83U9bMxOGh/ckGp4iSJAjRL619Bcn kcWkUP1Tw7FM4D5Sv65yM5TWJOpmO+bF5808MR8jzUSzLfvd1T/fE1nPxdZvbmwC zNm2ZY3CEIRHVoyblN/7ZWIw0yQZypOzdmzCoUKSADs9ujEfU0z16GmffJKOpIzV 1BnMMAkIQMaJ/JS5MXDjitIKfpLnzxH5hwaUGf6xsFFDCLpy1lTMBfLNVi5Mm05E rTa0Rw== Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4c1avx0jr0-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sat, 31 Jan 2026 10:12:08 +0000 (GMT) Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-c6187bdadcdso1612260a12.0 for ; Sat, 31 Jan 2026 02:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1769854327; x=1770459127; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6puvbklaTf3KTbyOtju0g8M5/JWaZ7LLZ6JZVfLJvCM=; b=c+JfPaxyuw6mPVQKZah3rNiROahLOGJZ1TS5Lr2MrWeMi08E35S+jFgumfRV/Nl9Lr 22p+PIvAat39IIF9DhKSgMdf6lxRA+LS98DPSakLuv19kaeJag1r1iAQoTL2GlOINX7Z LkRAvmZyS1rVM/udtr9CZKYqcM3pSANEvzg2eC2KyFr1VblDnKzmPGxtD0RfOqwdQ1io je77sv6AcTbFc/81MQIgKk51SFEP0TqKNGDfT2wOK9P759lsBvPrPEPirVgyw0RYi2Cg A4o0gsTH7UhIVXKUOxIs0ZP2ew1coiY4bv2FMlqEv7aqLPO9L9c7gtyCMTlX9eCtHHan XQfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769854327; x=1770459127; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6puvbklaTf3KTbyOtju0g8M5/JWaZ7LLZ6JZVfLJvCM=; b=XB3rStgtvGG6k5P4QDxiLMWB8aJMpQVzkZrmIYK+kwkgl1R8DgMWpm0cJEvZQbDPf8 2BoQo/2o/7leCkAz/ojn6OBUBGVQRuuxapaNfunr25GNXNiayeCdrwHvNBJZnh7yc0El ukchtIfAfRR70r8XQJvaIuPTPb903PFr4+s1+djZNyLtqZoTwy8y8HIXhZmx+fN/fvUY oXwmhlUz9pZ2Ge+ticvmFKaptrsLTI5vH6jQF3/Fp8/yJ4UA87Bce61I5KPZ+wpkWcND 5wftFw0wniOpTLJ+0I94xlmKGZthNZCj7M2lxcqwsYQn6AV5753w0WoDcddoW/+NPQ// OaTA== X-Forwarded-Encrypted: i=1; AJvYcCX5u2r+65yKa7OgsookRX+4qv1D1ZqOLwCsLsYsLSidTz9fnp9JZF2COwi/O0bcjcBUisWTSQbZ+15Iq/0=@vger.kernel.org X-Gm-Message-State: AOJu0YykBuh1ym4YsRnFWzn8oRGNE8hvKF2N71WEZHzHr7tg8QYbgTnc bbj33nFbf1lJ5ZTeYpCjVocwI7oNNP7uBPfni5YuhOTVZmX0Qkex754wbthqB2d17zBHAH0KiAv 1tR9iLgthTdkfrAS6Vfas1b28vP3bUoYVaRnI2LluB7GO61+N2JXSjBJ4uYULYLDNbus= X-Gm-Gg: AZuq6aKrQn35uSMisU5Tdc9TYqafTTToy1kqh4Jd2rvvaIXa8+V4CLGqRGPRKaC9kYp 8kaswuuMEN37rwHaBj+Ue+7SOqFPviL04ARGJi+Dvxgz5bOJcvlIOlT6mne0hZJM1BGqXH4IlEG XuBkBxjYCU4usz01QuzCouDUXnYmQaiqN+iX+gm2SC1lsET7zSAQjFIaY4odkVjj4LNlgrHYFmp f5nrM7RkY3lB5OsnXfBTD3Wf+Hln1nGpWzeuun0TqTV/VfSQz+HfOSMjgYRx0hivYFsDQPLnYGn IM3mwYM0qe6aD9wGqf4wuy0+Emi2a/ihX32OBqXQn9MaQXFl0o0VwQTilK06p6Uv7UzFB5Xzo0R IA8mYGoRye6BVwGeavG1xnQafzJwOCRCS3XR/rpU= X-Received: by 2002:a05:6a20:2d10:b0:38d:f2a1:a44f with SMTP id adf61e73a8af0-392e011afbdmr5448819637.48.1769854326812; Sat, 31 Jan 2026 02:12:06 -0800 (PST) X-Received: by 2002:a05:6a20:2d10:b0:38d:f2a1:a44f with SMTP id adf61e73a8af0-392e011afbdmr5448796637.48.1769854326265; Sat, 31 Jan 2026 02:12:06 -0800 (PST) Received: from [192.168.1.6] ([106.222.229.24]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3543d73386asm1734885a91.14.2026.01.31.02.11.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 31 Jan 2026 02:12:05 -0800 (PST) Message-ID: <998079d0-1c38-4a93-a63d-6bf9c91c4a83@oss.qualcomm.com> Date: Sat, 31 Jan 2026 15:41:58 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices To: Dmitry Baryshkov , Konrad Dybcio Cc: Bjorn Andersson , mathieu.poirier@linaro.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, rafael@kernel.org, daniel.lezcano@linaro.org, rui.zhang@intel.com, lukasz.luba@arm.com, konradybcio@kernel.org, amitk@kernel.org, mani@kernel.org, casey.connolly@linaro.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, manaf.pallikunhi@oss.qualcomm.com References: <57493aef-fb35-4377-8cf3-1df7f53470c9@oss.qualcomm.com> <74h7r3vsig3csejax3eu3uk53mdiimg2hjx7ntmmfrwdai6s3j@eiztghclfcvt> <5db5dafd-3c1f-4844-b822-bbfe86b3eb4d@oss.qualcomm.com> <98397a59-8ef2-4202-ae41-015c895d6bce@oss.qualcomm.com> <33kugspepphj3ywp642bp5ee4zd6pk6pxbooe4knv62coeofo6@5zqxy4n37k3j> Content-Language: en-US From: Gaurav Kohli In-Reply-To: <33kugspepphj3ywp642bp5ee4zd6pk6pxbooe4knv62coeofo6@5zqxy4n37k3j> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: UfjHWx63uE-YOXkDax8RIrV1rE-r6skV X-Proofpoint-GUID: UfjHWx63uE-YOXkDax8RIrV1rE-r6skV X-Authority-Analysis: v=2.4 cv=P4w3RyAu c=1 sm=1 tr=0 ts=697dd578 cx=c_pps a=oF/VQ+ItUULfLr/lQ2/icg==:117 a=EBd7WcfsMYPMwvoCMWz0vA==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=KKAkSRfTAAAA:8 a=i2r6_wRwnSb4ox3zbhYA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=3WC7DwWrALyhR5TkjVHa:22 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTMxMDA4NCBTYWx0ZWRfX7ZWJILCpzVDn tsC4+3a+O0m6j+xVqfLD7HjUPWpViZCULtyXevSHpxnL6A3fphNoPWqMCEzfla861N5lb30jhFq dEV+0nii2asRcv1EZh+RuyGzBmX30JgnowthKXzUYWrDUrEjY2P6y7ZLjGZy2eft9FACgOCT1h2 UJmUODfXN5+ySBCnF6Q+lglFYfbrQRnGp+L0RfFPu4Q1UsoL7zRf3IHTXcxxkfB2E8qD7qSd8Ih fmY0szjFD2d8Db95+3W2O72e8bETJYjWtIiYvTTExmnRyMOpL9Y5FmX1cmVTP2GEuqrkDzah8zl vTAC25rmt4OZMBSMHYZkctjY8lTetZOKF2y9EW9xn9aksEvnaSAusPvtoNNKVMuUyDWaIL2AvqZ GxVHz2eTIhSNPqhGUfFavRjmzoby39H2xiyRHzwS41mAAgmHbx2hBbTha5AIIjHOwa45Ut1j9nG 8ZuukuxT12CXfIs56IQ== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-01-31_01,2026-01-30_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 spamscore=0 clxscore=1015 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2601150000 definitions=main-2601310084 On 1/31/2026 1:36 PM, Dmitry Baryshkov wrote: > On Fri, Jan 30, 2026 at 10:13:06AM +0100, Konrad Dybcio wrote: >> On 1/30/26 8:03 AM, Gaurav Kohli wrote: >>> >>> 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 >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>> 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 >>>>>>>>>>>>      #include >>>>>>>>>>>>      #include >>>>>>>>>>>>      #include >>>>>>>>>>>> @@ -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. >> >> I think you're stuck in an XY problem - you keep insisting that adding >> a subnode is your end goal, while you really want to achieve being able >> to register multiple cooling devices. Or at least that's how I read your >> messages since you happen not to give any explanation as to why it's >> actually necessary. >> >> In my previous message, I forgot that cells for cooling devices actually >> represent the minimum and maximum cooling state allowed. But since the >> API is just part of the kernel, there's nothing preventing us from >> evolving it. >> >> Currently, we have: >> >> Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml >> >> properties: >> "#cooling-cells": >> description: >> Must be 2, in order to specify minimum and maximum cooling state used in >> the cooling-maps reference. The first cell is the minimum cooling state >> and the second cell is the maximum cooling state requested. >> const: 2 >> >> But I think it would be perfectly fine to suggest a change such that >> if cells > 2, the last two cells keep the current behavior and the former >> ones let you index into a cooling device exposed through a single OF node > > This might be a big change, which probably needs to be coordinated with > thermal and DT maintainers first. > >> >> e.g. >> >> rproc_xyz: remoteproc { >> compatible = "qcom,rproc-xyz"; >> >> ... >> >> #cooling-device-cells = <3>; >> }; > > Which brings in another topic. In DT we have labels for different DT > children, which correspond to different handlers on the DSP side. For > the CDSP we see a "cdsp_sw" only. I think I've asked several times, but > didn't get an example of the device having more than one, just claims > that there might be more thane one TMD. > > Do we need different cooling cells here? Or would it be enough to send > the same max state to all TMDs on the DSP side? > For newer targets, Within the CDSP we have compute core(cdsp-sw), npu(hmx-sw) core and both have independent dcvs and also dedicated tsens on each core. And For Modem also we have multiple mitigation devices based on different modem tech, for e.g tech level side we have modem-lte, modem-nr etc and mitigation at different power amplifier side like modem-pa etc. We have not added modem node for current series target as it does not support modem. >> >> ... >> >> thermal-zones { >> super-rproc-therm-a { >> thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_A >> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; >> >> trips { ... } ; >> }; >> >> super-rproc-therm-b { >> thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_B >> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; >> >> trips { ... } ; >> }; >> }; >> >> This would be resolved by allowing drivers to register an .of_xlate-type >> function which would take the RPROC_XYZ_COOLING_n argument and e.g. use >> it as an index into struct thermal_cooling_device cdev[]; within the >> driver struct. > > > >> >> Konrad >