From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1F77BC43458 for ; Tue, 30 Jun 2026 10:02:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lUbywPhi11XZzI5ppSu9FgDmSV/Q3ZgQenAYbUoS85o=; b=4P6GcAPV/swNiaq9DMZYp6v3P9 3Gn/8tUvNlnlLmKl3YgBsOpG/0gBPBlBo+DoYvM10cJxQrFc5V9ZBwK2z/pVRBRnI+Tnso3FlLJsc 3Y63C86W1T8+AMYkl/pTaWM8MeUMOwgGka9x8tGJvjWIKveSQlNCazrOCde9kv5Q9PtEJW9+oW5LO Bc9/YRPjndDXQj2hHpHVb13Z2tDmDp9m7bcEvYLPswYgn2RotNozp0gsc4LczN9Nltr+xOjZUwpzP X5HdRg2h8KHZIA4e7JjUfY//M93csG8A7YT2aGfJ+X3rA2wUYHZ7FGUvsLyhqglYX50Jm7dYuAiV3 S2KYqnhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1weVIX-0000000GZFw-1zjw; Tue, 30 Jun 2026 10:02:33 +0000 Received: from mx0b-0031df01.pphosted.com ([205.220.180.131]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1weVIU-0000000GZFN-1Iwn for linux-arm-kernel@lists.infradead.org; Tue, 30 Jun 2026 10:02:31 +0000 Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65U9mu4v1522287 for ; Tue, 30 Jun 2026 10:02:29 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= lUbywPhi11XZzI5ppSu9FgDmSV/Q3ZgQenAYbUoS85o=; b=RX1llCWNwdiJc+V0 v1oIbSF9gdJMDScIjA8M/NOI9cGwp0+5s3/n67gnmU7dqylWK6ZoRyXiBtRhKTYh GAe7RuW1bgSZk8uIdZSzyTflpMf6iblV7rOMIrqcSHx+ypTvikDvulQlrCbPwmik t3OY12rdA4MwZap8EzcQDs8e4EY7hHCNsMYGVt+vw2gv1npwhtxOYn/yoc6fCDN1 KqzLCklL7DyPa3ufu6b5xk7X9Gwk4w7okTX0sndYvE0Ksk5XsAgIvKXLRMnBF56A 6N/05Xvy/Z66fyP2hvooByL7W2TSCeLaaw9FHba51vlQIgxJEbcBaF3sGw7w5EWV 44OqXQ== Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4f3yw92qw1-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 30 Jun 2026 10:02:28 +0000 (GMT) Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2c987913b08so30788885ad.2 for ; Tue, 30 Jun 2026 03:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1782813748; x=1783418548; darn=lists.infradead.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=lUbywPhi11XZzI5ppSu9FgDmSV/Q3ZgQenAYbUoS85o=; b=etZBX1AkKbrYKywWAx3uKSg8lshhlDzspJ7PoPH2gZIiAVcg2CziVzWp2HxnAfJFPs wb8YdyDSzpPCvXm1Rz4k0p3vvmTCwapWhYKzx2fvLRb/WW/IephpjYXw5mfue59L9Lme zy2DS9t941IvWZRGSruqB2eiH5XqmOzXAukZ+4+pCCZszUfXc/JpT33LilATxDLN4mN1 p7Vc+h+ehSSsz8OtAjwfwdHkyuhr2kNguKWKgxyINEisRhWAthSIg36jJFLvipbsuczN MypOQfo4dm5SKHtvCA6631RS/poHnak63BSfV4WkHvyhFYWHfsJBIAciGDPAU27dqJXi vdIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782813748; x=1783418548; 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=lUbywPhi11XZzI5ppSu9FgDmSV/Q3ZgQenAYbUoS85o=; b=lJcpyTbeZFrdtB5im+n0uhjfrfZoqIfft6iwRPULoquOgpP9GaQnzfyclmMx+ACqo9 9YbxhFcejQqc2EAbbd/P5J5c2VMplHwvrkZ3baBvPXzB8zGVii61PuF3MRguPzYGfxjW xumMBBCqVDNlzwHlU/kTnIKlHfTEx7EUDDXJ56/wc0+wOQFPB/Tl2+jpG4BzYhjzTFDS fWxV+GRYG7K1ardBkmmg9ZQUGnQef6JihuAwHNwljxKZov9pL3Tn7hRxv3QQDjHeJEiX faG19/kjR5jMsxRP0fMB1Au2IE2jMsdJi4q6B0cKeNeQvjFegsmv7TrPwpnAhudJ+1ix rnag== X-Forwarded-Encrypted: i=1; AHgh+RpQ7xycQRtGRhQZh9cPqu7uMurgG3oQekmHT7KE1upB/qzfw/sNRG80KaaUfagiBvRjK5ZC58S/iomulhPFXe/D@lists.infradead.org X-Gm-Message-State: AOJu0YxIBPDwti0fsCLYKNwggFQEZj/x1KqcOiudICR6qirxxisiqtRo mDzpAcdsFK36IR/v5IDdcDtfahnbhsEmxJC8IW3IJn5BVVN7skNbj12a2sMraCV5gprvUe1mn/j M5LpAUSfF5VATde54XI/XGfgUf8md5M4yZ4tMHOvNVCIzh/QbHHo9yoSj7DoStfLD3Ub5IWpb0u 3Dcg== X-Gm-Gg: AfdE7cnA6RIte3OqVPKExDWBR0WGexAyB9tVJZ9U/LAXhIvpK19xCm5VBF36e5cuWAQ b6NBiTTRQNrv0fgr1RuV5hgJJqDAMoTHmy4BRQRMHaPljdOPZvKf09AfXPNK6xPF8s+1JqFl3/F EoxUtbv74wwKiyLyA6g26njVQB/p0gkcvr4EPVGhAHTbhdiqOYun4sR1cnyXKIy9xF5zfY9DhLp LWSphjlRI9OeE1KOgoKOQfdnQNIG1e4/iHtbfSoEfZTuHXBYgd/bw1SFgu9Xzu3nJeg+mfFuU9P 6oqt8bjlRDzY4w4ix1t7G9p+eb+tzOGPBOwWfyfV5l1XYMKQp+CYEj9sMnoYLLVEzemlneAO/Po J5KLdvFa8yWXlYNpOfOE1nBaKe9rvIoGIV4XrxVpI5KRe7JthLqBM1UiVMhOE/OZ1JvtwqfRbIX 8srGttuRScICPWdkAVyUnE8rBWPtVeo50Hegic X-Received: by 2002:a17:902:fc84:b0:2c9:b480:f5d0 with SMTP id d9443c01a7336-2ca2ea1d435mr23586165ad.39.1782813747828; Tue, 30 Jun 2026 03:02:27 -0700 (PDT) X-Received: by 2002:a17:902:fc84:b0:2c9:b480:f5d0 with SMTP id d9443c01a7336-2ca2ea1d435mr23585745ad.39.1782813747114; Tue, 30 Jun 2026 03:02:27 -0700 (PDT) Received: from [10.190.200.168] (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com. [103.229.18.19]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ca37c87ba2sm10318355ad.33.2026.06.30.03.02.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2026 03:02:26 -0700 (PDT) Message-ID: <78443e98-2d75-4e02-98f5-6a8f9460679d@oss.qualcomm.com> Date: Tue, 30 Jun 2026 15:32:18 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions To: Sudeep Holla Cc: Cristian Marussi , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sibi Sankar , MyungJoo Ham , Kyungmin Park , Chanwoo Choi , Dmitry Osipenko , Thierry Reding , Jonathan Hunter , Bjorn Andersson , Konrad Dybcio , Rajendra Nayak , Pankaj Patil , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, Amir Vajid , Ramakrishna Gottimukkula References: <20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com> <20260616-responsible-junglefowl-of-chaos-7eda7d@sudeepholla> <8725caf9-cebb-49ce-b2c8-4960a6073322@oss.qualcomm.com> <20260623-busy-beautiful-trout-8cc2ea@sudeepholla> <20260625-metal-chachalaca-of-fascination-eabc0f@sudeepholla> Content-Language: en-US From: Pragnesh Papaniya In-Reply-To: <20260625-metal-chachalaca-of-fascination-eabc0f@sudeepholla> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Info: AW1haW4tMjYwNjMwMDA5MCBTYWx0ZWRfXzk4v7gfXdFis FXTm1a+ddB0bp4pSxSIB06pQEin4dJQENVN0j7xG5DswJBRyOO+kkxAZ+rtGLVXaBg+/khJhSXQ 8Yx1Lm1RmnzVarQPAAHfPorjhR9qrAM= X-Authority-Analysis: v=2.4 cv=KfDidwYD c=1 sm=1 tr=0 ts=6a439434 cx=c_pps a=IZJwPbhc+fLeJZngyXXI0A==:117 a=Ou0eQOY4+eZoSc0qltEV5Q==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=VwQbUJbxAAAA:8 a=RZRlv3HtSbeCCbZTe5UA:9 a=QEXdDO2ut3YA:10 a=uG9DUKGECoFWVXl0Dc02:22 X-Proofpoint-GUID: qK23YunCfLF6IPHgtwHAbMICBiQe8txi X-Proofpoint-ORIG-GUID: qK23YunCfLF6IPHgtwHAbMICBiQe8txi X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjMwMDA5MCBTYWx0ZWRfX/z1EuuBT7A+O zPk/JHTTtXNkby1Q5AyDswWvQMrqmbHcR95GDPMr9QuD7cuG1JghwvR5VwYYBsJE8Xp6A6WrWTJ Z6zzvbQW8k2CsbXTs9YQebdSRRXarKleYJQ1ZVSvNfNLIEEtxNAG6gu3zfu1MGLj9GwuswiX6rY 6IqOV4zOOb1O7c5cD0ZUyNEiHlW4nnu6CjKl4IneEtsrDXc6jYLPgC8GoncVbGlWTEtLV8UTKBk h25raRRDSgo3s+Qk3m3sfMiAoS0JEKyJwXILIcsQ8UyMuyb2h4lX0e0kGBqzN7ByxpleD4z1eHA DKHxa2FCJfEwaAOq343iqRp8U0Umz/eGF0vlwBWHcpSzkUk0fJOTFt7tlMdZKBmWBijoqX4rS0O CxLu3BvvYkntTeVm28jEeHd9QjjYbjrvioigBLnSx3dvvkOpcFY1INxeLbAOAAzS1CTrdr5EbaH FJPlq8eor/j1QWH6SpA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-30_03,2026-06-26_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 impostorscore=0 bulkscore=0 clxscore=1015 spamscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2606300090 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260630_030230_470256_9510419B X-CRM114-Status: GOOD ( 41.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 27-Jun-26 7:43 PM, Sudeep Holla wrote: > On Thu, Jun 25, 2026 at 10:57:40AM +0530, Pragnesh Papaniya wrote: >> >> >> On 23-Jun-26 2:17 PM, Sudeep Holla wrote: >>> On Fri, Jun 19, 2026 at 06:01:23PM +0530, Pragnesh Papaniya wrote: >>>> >>>> On 16-Jun-26 1:57 PM, Sudeep Holla wrote: >>>> >>>>> Not sure if it was discussed in the previous versions or not, it would be >>>>> good if you can capture why some of bus scaling doesn't work with the existing >>>>> SCMI performance protocol and the monitors don't fit the MPAM mode. >>>>> >>>>> Please capture them in 1/9 as a motivation for this vendor protocol. It will >>>>> then help to understand it better as I am still struggling to. Sorry for that. >>>> >>>> Thanks for the input! >>>> >>>> SCMI perf protocol exports perf domains to kernel where kernel can set >>>> the frequency but here the scaling governor runs on the SCP while kernel >>>> just observes frequency changes made by remote governor. >>> >>> OK if it is sort of read-only w.r.t kernel, why not perf domain notifications >>> work to consume the change done by the SCMI platform. >>> >>> And why do you have set operations in the vendor protocol being proposed then. >>> It all looks like something just cooked up to make things work. I need >>> detailed reasoning as why the existing perf protocol can't work considering >>> all the existing notifications in place. >> >> Please do take another look at the documentation and driver changes to see >> how it all comes together, since it's apparent that we use SET operation for >> a ton of things. Taking another stab at explaining how the MEMLAT uses all >> the ops exposed by the vendor protocol. >> > > Sure I will have a look at the documentation again and sorry if I missed > anything. But in general I would expect the document to be self-explanatory > and not having to look at the driver on how it is used to understand the > firmware interface. Please make sure of that if not already. > >> We use the SET operation to pass on various tuneables (IPM CEIL, stall floors, >> write-back filter, freq-scale params, adaptive low/high freq, sample ms), >> the core-freq -> mem-freq map, and min/max clamps) required to run the >> MEMLAT algorithm on the SCP. You might ask why can't we have these values >> stored somewhere on the SCP itself? > > Exactly, thanks for saving a round trip. > >> We would like to but all of these are tuneable values, that can change for >> various boards for the same SoC. >> > > Sure and where do these boards get these values from ? I assume device tree ? > If so, are the fixed and can be done once at boot ? There are no memlat tunables in DT (We tried to have in device tree in the earlier revisions but they introduced unnecessary complexity). They are in kernel structs (see 7/9), fixed per SoC/board variant and pushed to the SCP exactly once at probe. The driver walks the selected config, sends the event maps, freq maps, tuneables and min/max clamps via SET, and then issues START. Any further SET traffic is limited to a sub-set of tuneables like changing sample_ms, limiting max_freq that the devfreq framework supports. > >> The START/STOP operations are meant to start/stop the algorithm, in this case >> the bus scaling algorithm. >> > > Yes you need to add more details on that algorithm. Can firmware take random > strings as input. I guess not. Please list the valid strings and explain them. > Filter invalid strings in the driver if only handful of values are valid. Thanks, will add a filter that just accepts valid strings in the next re-spin. > >> We use the GET operation to get the current frequency of memory that we >> are trying to scale. It can be also used to read back all the parameters >> that we are trying to set. Another thing to note is that exposing the current >> frequency to the userspace was something that the community wanted. >> > > More fun, user ABI involved, so the firmware interface needs to be as clear > as possible. > >> With all of ^^ in mind, re-using the perf protocol becomes impossible. >> >> https://lore.kernel.org/lkml/k4lpzxtrq3x6riyv6etxiobn7nbpczf2bp3m4oc752nhjknlit@uo53kbppzim7/ >> https://lore.kernel.org/lkml/20241115003809epcms1p518df149458f3023d33ec6d87a315e8f6@epcms1p5/ >> > > It is good to capture summary of these old discussions if they are relevant. Ack Thanks, Pragnesh > >> We'll add more call flow diagrams as part of the documentation for the next >> re-spin to make reviews a bit more easier. >> > > Anything that improves and helps in understanding this is always welcome. >