From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.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 8DF3E37FF41 for ; Wed, 14 Jan 2026 10:32:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768386723; cv=none; b=H2jZxsOeskO9g5tahVAg1gKyUOT3L075bL/xKpNRP/fYdAJ/wsVenzQn2d61M1ChbVCMDvZI3PYZ5IHZmATcAqc6a8lTuyKDOo1kCZ3zWuEWfz18jcbt9mmoRH9J/J0t8kufNy7j9G25K3JkHXE+hkIdrzE6yWlYjlAv6o7qKUk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768386723; c=relaxed/simple; bh=jla/MYd4+2oFBVKTdb3a1CvjAVITJvhxRNE4Y4ypt6w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kNNKxUGIFtFfEf/w3TzqVgekLTzYHPFw/aWy8b+Gi9cCHAxKSie0V+s1pwRGrDq2zSQ1VKq8lqlOweoqKfZ6t+Fh08vJoU45Fcjtgi5EYse5G7e5jQSdzZRaeJda3kkydWDl/y4fXzVX4A9SyIxbRGeYxEAKNDSOx0lT2EQPRXg= 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=co6DMUHs; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=C7l3Xju4; arc=none smtp.client-ip=205.220.168.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="co6DMUHs"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="C7l3Xju4" Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60E7jKBL2498061 for ; Wed, 14 Jan 2026 10:32:01 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= MQGrxRY3HuMFkUxGavmviPtyWCXgkL9hJSHhfZfU4sE=; b=co6DMUHsbl9XeMSd rNFCaPTEC9LpOzgEsskhcL72QqliPgyCxuFPIdC4/ICdV+dHfe6xnvNEFdutUVRh cXlipdiy4pfoMdW4KBUGPvml0ViiD5NTw1/bUd64S9Mc0Wuflsfq+H1du4WklSSh pR14j881ghqvXzwrM5RavzKTmOtCLFhI9nSeN5Nnm43GCszFRAmicPnqvVOTrrvw 30j1feRYl5ccz9gGQQxXOTo78QcggjpLMBUNL+wrUVzxrw342QyzeBm8OX4HzoCh 9Z/1AMTz4psmsRjcbwtQUY3R0kE2cECWO527dkVpXisKuckR7CZs6AC9Dql0cFp9 Mq+fbw== Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4bp16x1xry-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 14 Jan 2026 10:32:01 +0000 (GMT) Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-5014549e7d6so3573111cf.0 for ; Wed, 14 Jan 2026 02:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1768386721; x=1768991521; 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=MQGrxRY3HuMFkUxGavmviPtyWCXgkL9hJSHhfZfU4sE=; b=C7l3Xju4WGCnj6TOGPf3pHOrQ/jBIXgAV5Nb0F8kXSXfM0rekLmXPUJdRxSuS7bp+t 2reBUuZVyVfItpxwzRwQ80gTWXcI5tnalrbZqK1e9ZrHGah4hau9Z1d5AdamBqVy/U8U sOw9+OjrpIkhode7uB+bOfPglTTvYy5LujKETU/2kpR8Jb1xNUfmnoyUe81XtkiGpMOj NZa4zKe41qe2b8iEd1mraLyabYMjbfmILYR9c3DNfCyVZX2BdQ00kNIPudZ64Rwz12ak UpNRnVUEF3KsyNRkhIk3nCe3tCQURAVaALKRO3yTMPOGCv2CkLfWqskZrdMXvdksVUed 2ESw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768386721; x=1768991521; 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=MQGrxRY3HuMFkUxGavmviPtyWCXgkL9hJSHhfZfU4sE=; b=qp/pssP1/LQGqONo6eQZPOrJOFGkg99duD9PIfdwWqdeI5/fevVzFT0D6wjn0Pnf9W kJMlIryzHW+cBM6zg90XYYOhLl3y2Wb5IvXgpCFX+JesjPnEOCR9ZQRt6ooV+iEmfmuy lkwpsnHaOud89KCT7HeTFmL6hHWmqUjK3WLih5uYQd9z0Kk/bTFiuprS9t458KKmFq4f m8I/HnnvHXykGFDn94diJ1gCTWPqUIT39ZLwHuoQVD3GzR0vzz5HiQ0j/GGV1K3g6UeN uqvDNMkfRln2nDDuR7kkEQzqhjp/U1Rt1Q1y3Ta2ofHIkeLCKupqB6YGvs16Q5SlJ3Na qklA== X-Forwarded-Encrypted: i=1; AJvYcCVZT0yrXHdfyxt2/dcr3KH379e22dA+C0lxR+IJRko65oSFvsKgPlMgR4TrYcOUZXToEB9yzbDLwJgPz24=@vger.kernel.org X-Gm-Message-State: AOJu0Yx3WLTFehDs7BXGc6O9sf7rGSV8p2LmwjTwORJSV9Wu27hjYxKg cNohK5XsQ+tyfgvG619Og9sisr+q6Mn0FikvH6BQRSArPUBbKhHka/QVECvH/Hg1RMBQQ5EI5eT 5S/CGLiM6otlf6WIEVb8RRprkEZSTpitCpEpMU1Vjinfy2kGepw9a4ILKhf9S9yN3d6U= X-Gm-Gg: AY/fxX4hkzrpHmwS6CP4ubvzblD/BC9OzagLhq6cmRQv3WYTgxBxDvNwgu1zlZ0rAUj ybk0kqH4EUEBBD7Gpl4G5XxhTee+LX8XLp0n+s+gYnE1CQoOVpoVIHRBsZgDmIJnRIjYzTn92uK X7Q1Nqu8xFyPHpRRwjikecx6aT3uGoDPB3KZBfIpATkIdddXSgbVwU4TOKvqMcY0GVYvab/oQZF mu8wr/kH8Nv8q+18pUwDSjG4iknHWajpH0y7WF3cqOL0qTd2wxTrINDjJIEZ/x+RiueIPKRXyb7 jom12s9Fs8BPigdsOh7HIMepWGKmDtu9T7cn7td1iQwrHjo4OaekRocjD598usRT6+g2kCL4pdZ CdrNdMIc+0xqVyfkXXqE4ldMIK9rt/vwwVSOGPatdzerO70dQeqO7HL4ykRV+BTc6Paw= X-Received: by 2002:ac8:5894:0:b0:4e8:a001:226d with SMTP id d75a77b69052e-5014846f892mr20028641cf.7.1768386720518; Wed, 14 Jan 2026 02:32:00 -0800 (PST) X-Received: by 2002:ac8:5894:0:b0:4e8:a001:226d with SMTP id d75a77b69052e-5014846f892mr20028481cf.7.1768386719918; Wed, 14 Jan 2026 02:31:59 -0800 (PST) Received: from [192.168.119.254] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507bf6d5e0sm22308961a12.31.2026.01.14.02.31.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 02:31:59 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 11:31:57 +0100 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 RFC RFT] interconnect: qcom: implement get_bw with rpmh_read To: Neil Armstrong , Georgi Djakov Cc: linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Andersson References: <20251106-topic-sm8x50-icc-read-rpmh-v1-1-d03a2e5ca5f7@linaro.org> <8eb528dd-71fc-408e-a97c-d484198e4f81@kernel.org> <1be287ac-fce9-4f27-aa88-b1f786e968cd@oss.qualcomm.com> <95becfde-ba4b-4024-9b90-e64e77551f0a@linaro.org> Content-Language: en-US From: Konrad Dybcio In-Reply-To: <95becfde-ba4b-4024-9b90-e64e77551f0a@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: vNtOUnN0SZyrLs2T_-jheXtxBOvcDnZ0 X-Proofpoint-ORIG-GUID: vNtOUnN0SZyrLs2T_-jheXtxBOvcDnZ0 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTE0MDA4NiBTYWx0ZWRfX9k399DiTXV2B v+Ncq7Cql8PyBACC5WesQ00gRRwxB01oKnMnfxWryJwVBPjHKFZrcOwxqMhTZgIKmpNYSguA1xy gjovDgTbPmrOvKG5X4xtpZZRPhlRF2rKKPELuitKxUCBd5IW09zZba/wM4WK2GcH+zxQfqNtiDc QmdkTMFIUXrzrVmN/w+07jER9JG/g7p8GgEqeOjy35aH2CxOXVcZrOLEo/DXt5s4eGmWTryzfHf kSv3qBhjFcLtU6w25WIT2RfGERFx0F2aUVAuSQ0J6LDcbGmMmBAag1b1uo5UQ2l+ARzlzyDmCKA U7RGw1ZeHRdn8VudkPog4uyVUZiBbiLXMI+Ifizt09JKBJscvErWoBf9+7sOb+VlVmAndwcE4Ux HUrg+09NoIu3TocTfJS/sv8s17n0r8DoZxCE6HaqW+xN9Tii4mOn8NJTng3zQGqa4klNxj51EpT eDe3NV3QcpQzzp3ekYQ== X-Authority-Analysis: v=2.4 cv=JvT8bc4C c=1 sm=1 tr=0 ts=696770a1 cx=c_pps a=EVbN6Ke/fEF3bsl7X48z0g==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=kMUB7RtO3m2hnyBDxvcA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=a_PwQJl-kcHnX1M80qC6:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2026-01-14_03,2026-01-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 bulkscore=0 suspectscore=0 adultscore=0 priorityscore=1501 clxscore=1015 impostorscore=0 malwarescore=0 phishscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2512120000 definitions=main-2601140086 On 1/14/26 11:07 AM, Neil Armstrong wrote: > On 1/14/26 11:01, Konrad Dybcio wrote: >> On 1/13/26 6:53 PM, Georgi Djakov wrote: >>> On 11/6/25 6:46 PM, Neil Armstrong wrote: >>>> Since we can actually read back the APPS rpmh interconnect >>>> BCM votes we can actually implement the get_bw() callback >>>> and provide a coherent average and peak bandwidth at probe time. >>>> >>>> The benefits of that are: >>>> - keep disabled BCMs disabled >>>> - avoid voting unused BCMs to INT_MAX >>>> >>>> If the interconnects are correctly described for a platform, >>>> all the required BCMs would be voted to the maximum bandwidth >>>> until sync_state is reached. >>>> >>>> Since we only get the BCM vote, we need to redistribute >>>> the vote values to the associated nodes. The initial BCM >>>> votes are read back at probe time in order to be ready when >>>> the get_bw() is called when a node is added. >>>> >>> >>> FWIW, I was able to finally test this on sdm845. Some nodes are indeed >>> showing reasonable bandwidth values instead of the default INT_MAX. >> >> As I learnt here >> >> https://lore.kernel.org/linux-arm-msm/1e7594dc-dca6-42e7-b478-b063e3325aff@oss.qualcomm.com/ >> >> rpmh_read() will only retrieve the currently active values, so as-is, >> this hunk: >> >> +    /* For boot-up, fill the AMC vote in all buckets */ >> +    for (i = 0; i < QCOM_ICC_NUM_BUCKETS; i++) { >> +        bcm->vote_x[i] = x; >> +        bcm->vote_y[i] = y; >> +    } >> >> is lying about the state of wake/sleep buckets >> >> this is ""fine"" today, as I don't see any "if (old_bw == new_bw)" checks >> across the framework, but debugfs is going to report incorrect values and >> if anyone decides to add the aforementioned check, it may introduce issues >> where the values aren't commited to the hardware (because Linux is going >> to believe they're already set) > > This is only for the pre-sync-state phase, where we don't need the wake/sleep > values but the interconnect rpmh implementation needs them, and anyway they will > be replaced by proper values in sync_state I realize this may not be the most convincing argument, but consider the case where sync_state can not be hit, for example with the Venus driver that requests FW at probe time and errors out if it's absent > So this is an informed & assumed choice I did here. It's a small optimization > to avoid turning on _all_ interconnects at INT_MAX, and keep boot votes > up to sync_state. Another question is, whether that's a desired change - I could easily see pinning buses to the maximum speed helping boot time KPIs, but perhaps that could/should be configurable? Konrad