Message ID | 20230619-topic-sm8550-upstream-interconnect-mask-vote-v2-0-709474b151cc@linaro.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp5753843vqr; Fri, 23 Jun 2023 06:03:06 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7uQrG6VLGQcsmhw+6i2LCpWddGvRqhFnO6Yw5W7u+tODcx7YoeE0d0GDGbKokzf8pHtEKn X-Received: by 2002:a05:6a00:18a1:b0:668:7260:bbc0 with SMTP id x33-20020a056a0018a100b006687260bbc0mr18799648pfh.32.1687525386580; Fri, 23 Jun 2023 06:03:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687525386; cv=none; d=google.com; s=arc-20160816; b=lckE6hU6r7Aoz4JNxKHheGuNbEnJo2xQYg7fN7daFtjmmhHQu5osG8S+s4tcK9B0f6 ARevZTc4kAwo/GT5HrEzpXXAHC8fM5G4DCmnjKA2T2A/T5akgaTQPEYGrfsM0Nl4m/jT 9yFPC7ZHYmN2T9ldqq+pjVYpFa1Nd0FJmbcVt2MyjIVIV2avZPc5imKggEtp8FNuAmh/ XBPpD6s/hrja3L40NJ/yRRSQ7LDl26xkNj2k8eIrJwacqbD8/924x35iFe1mQcb56w+x ifzDfEjjE6Is2wfzcssmJFGsgBUgN9mFCSrwY6Uot+Vnf7+2/M/yNZdY9kSLqDr8OJaD rp2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:content-transfer-encoding:mime-version :message-id:date:subject:from:dkim-signature; bh=38ZFJVWNUQQxQWdNSjPpbRwE1qGpIOrtYRqEuWvZ+/4=; b=RlBlL1PCwrhTsdaAjU35avJZeq43SXu6HXo5MuvuLGYLVYt+P4tURyxBzdXc0MyWHa g2IhM69R+kEYY6+1IP6Y6LedNEnmpwqTaq6xrkQmZtXQuvDmWuHliHxE+1PAEmPiz4iB 0V9xVRev7NYKCdZUgGz1ZIfFkA6MBN+sEHv1sSCHgGxtaW2ZTCktwJLJyVJo+NtPKmgz fzCaQOWPstTgd8uD4RIdiXVx53QPhBb2q2Q3BAfXJf7F9iXhMbAmY+HgMUqEh4dxSCR6 ir8v12HUbYqlbPJq7x2KDN8ylq6fpTjh7uYoCF9xuksBW13cLiQeHFFLKdFpAOmW+th+ OG9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=YpUOOjwz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f18-20020aa79d92000000b00668806fdf46si8772179pfq.390.2023.06.23.06.02.34; Fri, 23 Jun 2023 06:03:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=YpUOOjwz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231458AbjFWMvQ (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Fri, 23 Jun 2023 08:51:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231342AbjFWMvL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 23 Jun 2023 08:51:11 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 211862129 for <linux-kernel@vger.kernel.org>; Fri, 23 Jun 2023 05:50:48 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-312824aa384so588237f8f.1 for <linux-kernel@vger.kernel.org>; Fri, 23 Jun 2023 05:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1687524646; x=1690116646; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:from:to:cc:subject:date:message-id:reply-to; bh=38ZFJVWNUQQxQWdNSjPpbRwE1qGpIOrtYRqEuWvZ+/4=; b=YpUOOjwzMFvEIZShfWlC9G9X4m1UFxwzymvN/G9VN0jT4MLBCkY3Un7MS1sVdNyjO3 ZnZ16AZ8/G0Kol6CIDuaRN8Hu1LxMgVUivI44reoX4CsufuAeF6NdNkeqsVKpIGaXcI+ pP3u1e8sDjuDocGR2ijci7yNo71tlVtq+p6roarJbXC/qoudVknl6dMP/jkw1LuwhX4c dZqX5Tmsxn3fKGdIwtSY2PLzrHGQxLcCdP6luhbbYYry2XTfheNw6g8xugqZMAXQq3E4 HuRXlqwemtH45ekuFJWNkeoZdwcW89TaHkvdcGRGMPr44pvXqtkm8nxreHrqKXe9ACdW TLnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687524646; x=1690116646; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=38ZFJVWNUQQxQWdNSjPpbRwE1qGpIOrtYRqEuWvZ+/4=; b=Bqal2ArEcylt+k/OAGpu5LxzASm+uzwxhLYcrGRMazYaywSUjaXIsmvJrM/FCNBw/S 5tJjOynQp8NEcQW5nHsWMuIG09xT+hwH5PQumzw+g8a+HV+E6oeLeJcjUUr715F/1WdQ KOW4Zca7BUGrXF+RnyXyIkL2k6OFaQpUO55+YXxxO4V+fOFVXP0o87AqFEPEH9KBahaN DZMCUxZvkbsfSO1uPu/UbHibdAA5IAiOxEhK586CtfA/C+hF53SH8S6xg/EaYgdPLtQV FA988wQcE0K6ej+YG1JikutRE0qP7Tl1hU7OAgk+zPfcvfkZYOyDMjbvRiA5jrVXz4z6 Nodw== X-Gm-Message-State: AC+VfDwD2+Cfykh6sD6ev0Sl0JgY7YplfB4h61APauqtfEOvwZnO0f6C 2zQV46vkNvh+TPyvatfXeCvVyw== X-Received: by 2002:a5d:404f:0:b0:30f:c1ac:9249 with SMTP id w15-20020a5d404f000000b0030fc1ac9249mr13513756wrp.51.1687524646558; Fri, 23 Jun 2023 05:50:46 -0700 (PDT) Received: from arrakeen.starnux.net ([2a01:e0a:982:cbb0:8261:5fff:fe11:bdda]) by smtp.gmail.com with ESMTPSA id m5-20020adffe45000000b002fae7408544sm9455350wrs.108.2023.06.23.05.50.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jun 2023 05:50:46 -0700 (PDT) From: neil.armstrong@linaro.org Subject: [PATCH v2 0/4] interconnect: qcom: rpmh: sm8550: mask to send as vote Date: Fri, 23 Jun 2023 14:50:41 +0200 Message-Id: <20230619-topic-sm8550-upstream-interconnect-mask-vote-v2-0-709474b151cc@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIACGVlWQC/52OQQ6CMBBFr0K6dkwpKQFX3sOwGOoIE6El00I0h LtbPYJ/9/7i/b+rSMIU1aXYldDGkYPPYE6FciP6gYDvmZXRptJ12UIKCzuIc2OthnWJSQhnYJ9 IXPCeXIIZ4xO2kAjaGtHoytrSNiore4wEvaB3Y5b6dZpyuQg9+PX7cOsyjxxTkPfv0lZ+2z/Xt xI01DmV04i2NdeJPUo4BxlUdxzHB4ZKyyX+AAAA To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Georgi Djakov <djakov@kernel.org> Cc: linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Neil Armstrong <neil.armstrong@linaro.org>, Mike Tipton <mdtipton@codeaurora.org> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1285; i=neil.armstrong@linaro.org; h=from:subject:message-id; bh=dHlYALK7LZK9JGD1GTv8PH7HVFxRRCXWRUuHCV2V1AE=; b=owEBbQKS/ZANAwAKAXfc29rIyEnRAcsmYgBklZUjcy8hCaoLpedyJOAMD1KNd/U0sIl7+rBl6/L1 kwC3bMWJAjMEAAEKAB0WIQQ9U8YmyFYF/h30LIt33NvayMhJ0QUCZJWVIwAKCRB33NvayMhJ0T0DEA CUBYXFjABUSSNfXkbhRd6ZUxLRmT8sVvHDnlBGaMc1HnJTlZq9VCvg+o/xbI8LBT3F2RLIC/OvF92w Qikg5QnjV5qREQUOoc1QY1iH1wd2PsFVMsxJNvx3HcmMRLEoK7RFo9P5qeVnszgjq2uSK9J10e2kjF jNC1qhfmqEvyma1Td5E4lscNtq646V7JCHk8G55VGUp+MnBy3d+9+PHk8fVKdaZUEAAc8XfzchoB8p QckZsVoIVdMTW55QWEipRDPd2tc8NzC1pVFKgxWIxBK1/TKuQ+uh372XQbEWLFHKGz767KTXd4I+0r 7ENEjTc7qJtG+t1x576F1dsCaa3ACsCEkV4ZdmM6kiRb0oNpXsPliOsfn0vizrWbdNvM3zxjl1C3nE f57l47tvJLgnwEG3YSt+n0nilAgY7X2h47eeyonqLbg5YF+UuhVl20e33oZGJVNpGV3cY38NjI/0Vq 0zjjW2mNjqLw4VSFpOXUozQK2gISHYZ1qbbHf8zcfq9laVr59pUf+oPqnFvBxVVMcX21LoNAHZGn72 PoWsjpBQ/Ugj1YtxmAv3X9JgBdvabCnr+Bq9FNlP+vy6irA83VF5/VYEgby6dBA793iHFJ5AajROKX O7rEOLOGNYElmY2JiaN6h3KCZ0DAJohyQG8k/not+Ie+zul1WcJPMZJpZ77A== X-Developer-Key: i=neil.armstrong@linaro.org; a=openpgp; fpr=89EC3D058446217450F22848169AB7B1A4CFF8AE X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769498619918391120?= X-GMAIL-MSGID: =?utf-8?q?1769498619918391120?= |
Series |
interconnect: qcom: rpmh: sm8550: mask to send as vote
|
|
Message
Neil Armstrong
June 23, 2023, 12:50 p.m. UTC
On the SM8550 SoC, some nodes requires a specific bit mark
instead of a bandwidth when voting.
Add an enable_mask variable to be used instead of bandwidth.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v2:
- Took downstream patch for patch 1
- Added konrad's reviewed tag
- Added changes for sm8450 and sa8775p
- Link to v1: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v1-0-66663c0aa592@linaro.org
---
Mike Tipton (1):
interconnect: qcom: Add support for mask-based BCMs
Neil Armstrong (3):
interconnect: qcom: sm8450: add enable_mask for bcm nodes
interconnect: qcom: sm8550: add enable_mask for bcm nodes
interconnect: qcom: sa8775p: add enable_mask for bcm nodes
drivers/interconnect/qcom/bcm-voter.c | 5 +++++
drivers/interconnect/qcom/icc-rpmh.h | 2 ++
drivers/interconnect/qcom/sa8775p.c | 1 +
drivers/interconnect/qcom/sm8450.c | 9 +++++++++
drivers/interconnect/qcom/sm8550.c | 17 +++++++++++++++++
5 files changed, 34 insertions(+)
---
base-commit: 47045630bc409ce6606d97b790895210dd1d517d
change-id: 20230619-topic-sm8550-upstream-interconnect-mask-vote-96aa20355158
Best regards,
Comments
On 23.06.2023 14:50, neil.armstrong@linaro.org wrote: > On the SM8550 SoC, some nodes requires a specific bit mark > instead of a bandwidth when voting. > > Add an enable_mask variable to be used instead of bandwidth. > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > --- After reviewing this patchset and taking a peek at older downstream, it looks like ACV should be using 0x8 bmask on *all RPMh SoCs*. It's worth noting however, that 8350's downstream (the first msm kernel using the icc framework) did not incorporate that change. Not sure if intentionally or not. Probably not. Might be worth to poke Qcom to backport it in such case. If 8350 is still supported. Probably not. Check out these snippets: https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.10.2.1.c25/drivers/soc/qcom/msm_bus/msm_bus_arb_rpmh.c#L556-567 https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.10.2.1.c25/drivers/soc/qcom/msm_bus/msm_bus_arb_rpmh.c#L475-495 Notice how acv is never updated beyond effectively setting =0 or =bmask, perhaps Qualcomm never implemented something else.. Since this series is fine as-is, I'd be happy to see an incremental one. Reported-by would be cool as well :D Konrad > Changes in v2: > - Took downstream patch for patch 1 > - Added konrad's reviewed tag > - Added changes for sm8450 and sa8775p > - Link to v1: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v1-0-66663c0aa592@linaro.org > > --- > Mike Tipton (1): > interconnect: qcom: Add support for mask-based BCMs > > Neil Armstrong (3): > interconnect: qcom: sm8450: add enable_mask for bcm nodes > interconnect: qcom: sm8550: add enable_mask for bcm nodes > interconnect: qcom: sa8775p: add enable_mask for bcm nodes > > drivers/interconnect/qcom/bcm-voter.c | 5 +++++ > drivers/interconnect/qcom/icc-rpmh.h | 2 ++ > drivers/interconnect/qcom/sa8775p.c | 1 + > drivers/interconnect/qcom/sm8450.c | 9 +++++++++ > drivers/interconnect/qcom/sm8550.c | 17 +++++++++++++++++ > 5 files changed, 34 insertions(+) > --- > base-commit: 47045630bc409ce6606d97b790895210dd1d517d > change-id: 20230619-topic-sm8550-upstream-interconnect-mask-vote-96aa20355158 > > Best regards,
On Fri, Jun 23, 2023 at 03:58:09PM +0200, Konrad Dybcio wrote: > On 23.06.2023 14:50, neil.armstrong@linaro.org wrote: > > On the SM8550 SoC, some nodes requires a specific bit mark > > instead of a bandwidth when voting. > > > > Add an enable_mask variable to be used instead of bandwidth. > > > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > > --- > After reviewing this patchset and taking a peek at older downstream, > it looks like ACV should be using 0x8 bmask on *all RPMh SoCs*. > > It's worth noting however, that 8350's downstream (the first msm > kernel using the icc framework) did not incorporate that change. > Not sure if intentionally or not. Probably not. Might be worth to > poke Qcom to backport it in such case. If 8350 is still supported. > Probably not. > Your observation is correct. But, note further that command db reports ACV to have data-width of 0, resulting in the numerator, and thereby vote_x and vote_y always being 0. This is downstream worked around by: https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/commit/4d2818084015df1e05274ebcc5a0d21e6d256f93 Which should cause vote_x and vote_y to be non-zero. However without this series (and enable_mask defined for ACV on all platforms) the votes placed in the BCM would then be garbage... That said, unless I'm missing something the math involved here is unnecessary.For BCMs with enable_mask, if for any node sum_avg[bucket] or max_peak[bucket] is non-zero then the calculated vote_x and vote_y comes out non-zero and we write the mask, otherwise 0. Rewritten to avoid all the unnecessary multiplication and divisions, we wouldn't care about the unit or width and thereby don't need above referenced patch. A further tangent here is that a BCM with enable_mask != BIT(0) but keepalive set, a 0-bandwidth vote in AMC would result in an invalid (undefined?) BCM value being written out in the snippet below the loop. > Check out these snippets: > > https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.10.2.1.c25/drivers/soc/qcom/msm_bus/msm_bus_arb_rpmh.c#L556-567 > > https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.10.2.1.c25/drivers/soc/qcom/msm_bus/msm_bus_arb_rpmh.c#L475-495 > > Notice how acv is never updated beyond effectively setting =0 or =bmask, > perhaps Qualcomm never implemented something else.. > > Since this series is fine as-is, I'd be happy to see an incremental one. > Reported-by would be cool as well :D I agree, let's get this merged, backported to stable, and then fix ACV handling in a follow up commit (which doesn't necessarily need to hit stable). You should have a Jira card for this one already, but I don't mind sharing the Reported-by with you ;) Regards, Bjorn > > Konrad > > Changes in v2: > > - Took downstream patch for patch 1 > > - Added konrad's reviewed tag > > - Added changes for sm8450 and sa8775p > > - Link to v1: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v1-0-66663c0aa592@linaro.org > > > > --- > > Mike Tipton (1): > > interconnect: qcom: Add support for mask-based BCMs > > > > Neil Armstrong (3): > > interconnect: qcom: sm8450: add enable_mask for bcm nodes > > interconnect: qcom: sm8550: add enable_mask for bcm nodes > > interconnect: qcom: sa8775p: add enable_mask for bcm nodes > > > > drivers/interconnect/qcom/bcm-voter.c | 5 +++++ > > drivers/interconnect/qcom/icc-rpmh.h | 2 ++ > > drivers/interconnect/qcom/sa8775p.c | 1 + > > drivers/interconnect/qcom/sm8450.c | 9 +++++++++ > > drivers/interconnect/qcom/sm8550.c | 17 +++++++++++++++++ > > 5 files changed, 34 insertions(+) > > --- > > base-commit: 47045630bc409ce6606d97b790895210dd1d517d > > change-id: 20230619-topic-sm8550-upstream-interconnect-mask-vote-96aa20355158 > > > > Best regards,
On 6/23/2023 11:58 AM, Bjorn Andersson wrote: > On Fri, Jun 23, 2023 at 03:58:09PM +0200, Konrad Dybcio wrote: >> On 23.06.2023 14:50, neil.armstrong@linaro.org wrote: >>> On the SM8550 SoC, some nodes requires a specific bit mark >>> instead of a bandwidth when voting. >>> >>> Add an enable_mask variable to be used instead of bandwidth. >>> >>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >>> --- >> After reviewing this patchset and taking a peek at older downstream, >> it looks like ACV should be using 0x8 bmask on *all RPMh SoCs*. >> >> It's worth noting however, that 8350's downstream (the first msm >> kernel using the icc framework) did not incorporate that change. >> Not sure if intentionally or not. Probably not. Might be worth to >> poke Qcom to backport it in such case. If 8350 is still supported. >> Probably not. >> > > Your observation is correct. Mostly correct. Historically it's always been 0x8, but it's not guaranteed. And it will be different on some upcoming SoCs. > > But, note further that command db reports ACV to have data-width of 0, > resulting in the numerator, and thereby vote_x and vote_y always being > 0. > > This is downstream worked around by: > https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/commit/4d2818084015df1e05274ebcc5a0d21e6d256f93 > > Which should cause vote_x and vote_y to be non-zero. However without > this series (and enable_mask defined for ACV on all platforms) the votes > placed in the BCM would then be garbage... > > > > That said, unless I'm missing something the math involved here is > unnecessary.For BCMs with enable_mask, if for any node sum_avg[bucket] > or max_peak[bucket] is non-zero then the calculated vote_x and vote_y > comes out non-zero and we write the mask, otherwise 0. You're not missing anything. The full aggregation logic isn't necessary for BCMs with an enable_mask. It was just a bit simpler to implement this way. And the extra time spent in the aggregation logic should be minimal. But, it could certainly be rewritten to have an entirely separate, simpler "aggregation" loop than the full BCMs. > > Rewritten to avoid all the unnecessary multiplication and divisions, we > wouldn't care about the unit or width and thereby don't need above > referenced patch. Yeah, the patch shouldn't be necessary anymore in that case. Though keeping it would protect us against div-by-zero in case of something unexpected in cmd_db. > > > A further tangent here is that a BCM with enable_mask != BIT(0) but > keepalive set, a 0-bandwidth vote in AMC would result in an invalid > (undefined?) BCM value being written out in the snippet below the loop. True, though in practice it should never be a problem. Currently, there are only two use cases for enable_mask -- "on/off" BCMs and ACV. The enable_mask for on/off BCMs is always 0x1. The only time enable_mask != 0x1 is for ACV, but keepalive should never be set for ACV. I agree this is a bit of a logical hole, though. And could break in the future for as-yet undefined usage of enable_mask. > >> Check out these snippets: >> >> https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.10.2.1.c25/drivers/soc/qcom/msm_bus/msm_bus_arb_rpmh.c#L556-567 >> >> https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/blob/LA.UM.10.2.1.c25/drivers/soc/qcom/msm_bus/msm_bus_arb_rpmh.c#L475-495 >> >> Notice how acv is never updated beyond effectively setting =0 or =bmask, >> perhaps Qualcomm never implemented something else.. >> >> Since this series is fine as-is, I'd be happy to see an incremental one. >> Reported-by would be cool as well :D > > I agree, let's get this merged, backported to stable, and then fix ACV > handling in a follow up commit (which doesn't necessarily need to hit > stable). > > You should have a Jira card for this one already, but I don't mind > sharing the Reported-by with you ;) > > Regards, > Bjorn > >> >> Konrad >>> Changes in v2: >>> - Took downstream patch for patch 1 >>> - Added konrad's reviewed tag >>> - Added changes for sm8450 and sa8775p >>> - Link to v1: https://lore.kernel.org/r/20230619-topic-sm8550-upstream-interconnect-mask-vote-v1-0-66663c0aa592@linaro.org >>> >>> --- >>> Mike Tipton (1): >>> interconnect: qcom: Add support for mask-based BCMs >>> >>> Neil Armstrong (3): >>> interconnect: qcom: sm8450: add enable_mask for bcm nodes >>> interconnect: qcom: sm8550: add enable_mask for bcm nodes >>> interconnect: qcom: sa8775p: add enable_mask for bcm nodes >>> >>> drivers/interconnect/qcom/bcm-voter.c | 5 +++++ >>> drivers/interconnect/qcom/icc-rpmh.h | 2 ++ >>> drivers/interconnect/qcom/sa8775p.c | 1 + >>> drivers/interconnect/qcom/sm8450.c | 9 +++++++++ >>> drivers/interconnect/qcom/sm8550.c | 17 +++++++++++++++++ >>> 5 files changed, 34 insertions(+) >>> --- >>> base-commit: 47045630bc409ce6606d97b790895210dd1d517d >>> change-id: 20230619-topic-sm8550-upstream-interconnect-mask-vote-96aa20355158 >>> >>> Best regards,
On 23.06.2023 14:50, neil.armstrong@linaro.org wrote: > On the SM8550 SoC, some nodes requires a specific bit mark > instead of a bandwidth when voting. > > Add an enable_mask variable to be used instead of bandwidth. > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > --- Georgi, please pick this up and I'll fix up the ACV situation mentioned by Bjorn as an incremental change. Konrad
On 9.08.23 22:23, Konrad Dybcio wrote: > On 23.06.2023 14:50, neil.armstrong@linaro.org wrote: >> On the SM8550 SoC, some nodes requires a specific bit mark >> instead of a bandwidth when voting. >> >> Add an enable_mask variable to be used instead of bandwidth. >> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >> --- > Georgi, > > please pick this up and I'll fix up the ACV situation mentioned > by Bjorn as an incremental change. > > Konrad Thanks Konrad! I had sent it to Greg last week, so it will get into Torvalds tree most likely this week. BR, Georgi