Message ID | 20240119-rpmh-rsc-fixes-v2-1-e42c0a9e36f0@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-30904-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2bc4:b0:101:a8e8:374 with SMTP id hx4csp867223dyb; Fri, 19 Jan 2024 00:27:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IFomP68vS6mCqIdZseiWZy87IrWYhuyA6ZCWnw5tMz4ptc/k7NWBi4yTIcF3eHmZBycjuXP X-Received: by 2002:a05:6214:b6c:b0:681:a812:5b07 with SMTP id ey12-20020a0562140b6c00b00681a8125b07mr1203710qvb.60.1705652849907; Fri, 19 Jan 2024 00:27:29 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705652849; cv=pass; d=google.com; s=arc-20160816; b=leN3wjbj1T4rzTAak4cBGBOoXGG/f7POwmei0D3QUYwANv6JEpQj9Oa0Vyx0iQrGU9 sZr5cdw5a29vr+jrhlz3Jmq6NjHq8PM7y4KXQH6m1t4uAXc17FOE48+Tag695pRUxB0T 7lmEOTqpmzKjK1THT5iYq/3z5VfKAg/fLy+Bx90MEJHrBljStcJnRC3rigjivw2t60QU XumLqEmnjkpF/y2BebdS2ScXT3L2v2v9YcmoaPToNPNVZN6jiWEgxssuGaKsJFHMOe9i MzvAoR2iKIQ+PbUQi1hZYgrH18h2SKA7wjsMSlnCskfrzSN862AjThzrpVh4iOsjnEn6 ETXw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:message-id:content-transfer-encoding:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:subject:date :from:dkim-signature; bh=3M56Dj3GSMYxGpt9ZWmuVrjJFtZtzWljDNbou+qC98o=; fh=CtH4OYV+a5hFgZ88g8dESROUO+A2wmqMP2VmDQQIPiw=; b=tl6rrZRl/FjlN5wTIux5CFrKrQkQF6DmlQH2Ic9NEFW3aY6MYTbu3uwpxy7MFmZ1YE TMBY7eWdMcxIIBwcwdtkbUTaBDKSYirmpDgRn2vtnxHPvdAJ/Qjbq8OXA892EWAWPf82 byevA6lqh06kzdKM4QjrbMa8h2sGdG9Cf2Mb8i4oe3iZ+sD3lD/2FgPAPSjR7YKZHTWe sgdldF63z+h3YGjLdOlspShJ58db85yLeaLwtVQzMnAcEBzX86t2xTsFnxdhnmED7snm iMT/YBtkW5W5uFkDxR7ii7x2l53q4cK9Te4W8w0GRQa9fVyk4dfgdzs6spYD8RFkZt3Z xgiA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b="gqGN/RTY"; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-30904-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-30904-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id k17-20020a0cb251000000b006817f6c91a1si4654268qve.295.2024.01.19.00.27.29 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jan 2024 00:27:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-30904-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b="gqGN/RTY"; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-30904-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-30904-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id A1D971C22988 for <ouuuleilei@gmail.com>; Fri, 19 Jan 2024 08:27:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9816928E0F; Fri, 19 Jan 2024 08:27:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="gqGN/RTY" 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 3F0F124B2C; Fri, 19 Jan 2024 08:27:11 +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=1705652833; cv=none; b=WJMCRaCrVMSysIEkO8UwM+kXlmjj8oeugk0yuvnvVY599bFRopArnjKLjt6ZghnfryAN0mm7N8vRzaRacYkHsHt64BQGLdjda3PR4Eu2upSsqpLGKbQycEOgtJdlfwmMijccmZ5yH9AeQLI3kMFNzdDzhlBHcRb7N5QXPDG6tTs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705652833; c=relaxed/simple; bh=+FOihNrOosZdp1tCvq1a3qbL37vxph33JQlJkukPYVQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-ID:To:CC; b=I0GQtCEJA9S0vcMG4/3nUvoq+OCVHKdIxxsIGj81LCaczQThiJC2a7wqVAel1B50Yrxb70r95YiWUHCFFCGZhhoH4DJQzVi9LWCJPIZLJ8yr01ULS5RDv9Zivr6doPDfHtuuNlgo/KDMGY1CIWVCBcf3QkaEz/sQpoUnbrHl0NM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=gqGN/RTY; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 40J47D73027020; Fri, 19 Jan 2024 08:27:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= from:date:subject:mime-version:content-type :content-transfer-encoding:message-id:to:cc; s=qcppdkim1; bh=3M5 6Dj3GSMYxGpt9ZWmuVrjJFtZtzWljDNbou+qC98o=; b=gqGN/RTYMb+n6ZR/pyR bFigrk27hGUoysZiPcw5pmXYcR/yGOAiz0N7M22tIS+7OScJ4QjaFFAj5K9md3Xd BkLTIITEbeA6pOx3ZqE7YHxx4Ve8NBqW+h0rIrDuTU793UFLDU64kfhnHIU/cWdT ArfGeW00EEV2OXqgrdhvTGtQ8utW2MuQi5Vqx7X6U4rMfuk1HS6d08O2sgadmrS5 imFnMpjpg2N+T0Tq7S4yxMhNP2ZDg/3pyys49gRIIqtzqbuueso2CPed1nFumbVr HC59yGlRcn/jqRgoEObZSKsxDUY7vFVLsHPahP0xV7XYxKJyicBJ77q2iygyCp8o BPg== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3vqhs9gegd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jan 2024 08:27:00 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 40J8R04i015174 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jan 2024 08:27:00 GMT Received: from hu-mkshah-hyd.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Fri, 19 Jan 2024 00:26:57 -0800 From: Maulik Shah <quic_mkshah@quicinc.com> Date: Fri, 19 Jan 2024 13:56:54 +0530 Subject: [PATCH v2] soc: qcom: rpmh-rsc: Enhance check for VREG in-flight request Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <20240119-rpmh-rsc-fixes-v2-1-e42c0a9e36f0@quicinc.com> X-B4-Tracking: v=1; b=H4sIAE0yqmUC/3WMMQ7CMAxFr1J5xigOgURM3AN1qIxLPLQpCVSgq ncndGd8/+u9BYpklQLnZoEssxZNYwW7a4BjN94F9VYZrLHOEHnM0xAxF8Ze31LwxO7A3hwp2AB VmrJsR3WubeWo5ZnyZ+vP9Fv/pmZCQk8irg+9t527PF7KOvKe0wDtuq5fZHUFVa4AAAA= To: Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org> CC: <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <quic_eberman@quicinc.com>, <quic_collinsd@quicinc.com>, <quic_lsrao@quicinc.com>, Maulik Shah <quic_mkshah@quicinc.com> X-Mailer: b4 0.12.5-dev-2aabd X-Developer-Signature: v=1; a=ed25519-sha256; t=1705652817; l=2980; i=quic_mkshah@quicinc.com; s=20240109; h=from:subject:message-id; bh=+FOihNrOosZdp1tCvq1a3qbL37vxph33JQlJkukPYVQ=; b=alY8OpsiE8fKNnNipPdw3Pc/qnK57zC4iKb973Z4z6bRwXyviyswZ3k6RMGde9vfCz49eQdmJ aFZLQ5NwmyrCfKuIZShmWZgmPUkVNOj42DIz8hq0rZUrvknhZKKoECP X-Developer-Key: i=quic_mkshah@quicinc.com; a=ed25519; pk=bd9h5FIIliUddIk8p3BlQWBlzKEQ/YW5V+fe759hTWQ= X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: kRD7uAHuSIb4qyowqQ5zuXvSzMYTlocN X-Proofpoint-ORIG-GUID: kRD7uAHuSIb4qyowqQ5zuXvSzMYTlocN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-19_04,2024-01-17_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 bulkscore=0 clxscore=1015 malwarescore=0 mlxlogscore=999 adultscore=0 phishscore=0 spamscore=0 suspectscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2311290000 definitions=main-2401190031 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788327193954247537 X-GMAIL-MSGID: 1788506642746069086 |
Series |
[v2] soc: qcom: rpmh-rsc: Enhance check for VREG in-flight request
|
|
Commit Message
Maulik Shah
Jan. 19, 2024, 8:26 a.m. UTC
Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte aligned addresses associated with it. These control voltage, enable state, mode, and in legacy targets, voltage headroom. The current in-flight request checking logic looks for exact address matches. Requests for different addresses of the same RPMh resource as thus not detected as in-flight. Enhance the in-flight request check for VREG requests by ignoring the address offset. This ensures that only one request is allowed to be in-flight for a given VREG resource. This is needed to avoid scenarios where request commands are carried out by RPMh hardware out-of-order leading to LDO regulator over-current protection triggering. Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> --- Changes in v2: - Use GENMASK() and FIELD_GET() - Link to v1: https://lore.kernel.org/r/20240117-rpmh-rsc-fixes-v1-1-71ee4f8f72a4@quicinc.com --- drivers/soc/qcom/rpmh-rsc.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) --- base-commit: 943b9f0ab2cfbaea148dd6ac279957eb08b96904 change-id: 20240117-rpmh-rsc-fixes-6c43c7051828 Best regards,
Comments
On 19/01/2024 08:26, Maulik Shah wrote: > Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte aligned > addresses associated with it. These control voltage, enable state, mode, > and in legacy targets, voltage headroom. The current in-flight request > checking logic looks for exact address matches. Requests for different > addresses of the same RPMh resource as thus not detected as in-flight. This commit log implies you are fixing a bug. Can you do some inspection of the git commit log and figure out where to backport this change to ? Your change would apply to 40482e4f73640d but a quick pass on the logic in check_for_req_inflight() shows its probably _applicable_ to 658628e7ef78e8 > /* > * Here's a high level overview of how all the registers in RPMH work > * together: > @@ -557,7 +568,15 @@ static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs, > for_each_set_bit(j, &curr_enabled, MAX_CMDS_PER_TCS) { > addr = read_tcs_cmd(drv, drv->regs[RSC_DRV_CMD_ADDR], i, j); > for (k = 0; k < msg->num_cmds; k++) { > - if (addr == msg->cmds[k].addr) > + /* > + * Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte > + * aligned addresses associated with it. Ignore the offset to check > + * for in-flight VREG requests. > + */ > + if (ACCL_TYPE(msg->cmds[k].addr) == HW_ACCL_VREG && > + VREG_ADDR(msg->cmds[k].addr) == VREG_ADDR(addr)) > + return -EBUSY; > + else if (addr == msg->cmds[k].addr) Consider removing the /* comment */ if it helps to apply the change earlier than 658628e7ef78e8. --- bod
On 19/01/2024 10:34, Bryan O'Donoghue wrote: > Consider removing the /* comment */ if it helps to apply the change > earlier than 658628e7ef78e8. > > --- > bod > Earlier than 40482e4f73640d ! --- bod
On Fri, Jan 19, 2024 at 01:56:54PM +0530, Maulik Shah wrote: > Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte aligned > addresses associated with it. These control voltage, enable state, mode, > and in legacy targets, voltage headroom. The current in-flight request > checking logic looks for exact address matches. Requests for different > addresses of the same RPMh resource as thus not detected as in-flight. > > Enhance the in-flight request check for VREG requests by ignoring the > address offset. This ensures that only one request is allowed to be > in-flight for a given VREG resource. This is needed to avoid scenarios > where request commands are carried out by RPMh hardware out-of-order > leading to LDO regulator over-current protection triggering. > > Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Just noticed I commented on v1 when v2 was already out, sorry. Copy pasting this just to keep it on the latest thread: Two minor things: 1. Does this deserve a Fixes: tag? 2. The Signed-off-by chain here confuses me, you sent the patch so your SOB should be last, but then that makes me believe Elliot was the author which I don't think is reflected here (no From: line). Please read [0] for a bit more details [0] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 > --- > Changes in v2: > - Use GENMASK() and FIELD_GET() > - Link to v1: https://lore.kernel.org/r/20240117-rpmh-rsc-fixes-v1-1-71ee4f8f72a4@quicinc.com > --- > drivers/soc/qcom/rpmh-rsc.c | 21 ++++++++++++++++++++- > 1 file changed, 20 insertions(+), 1 deletion(-) > > diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c > index a021dc71807b..e480cde783fe 100644 > --- a/drivers/soc/qcom/rpmh-rsc.c > +++ b/drivers/soc/qcom/rpmh-rsc.c > @@ -1,11 +1,13 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. > + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved. > */ > > #define pr_fmt(fmt) "%s " fmt, KBUILD_MODNAME > > #include <linux/atomic.h> > +#include <linux/bitfield.h> > #include <linux/cpu_pm.h> > #include <linux/delay.h> > #include <linux/interrupt.h> > @@ -91,6 +93,15 @@ enum { > #define CMD_STATUS_ISSUED BIT(8) > #define CMD_STATUS_COMPL BIT(16) > > +#define ACCL_TYPE(addr) FIELD_GET(GENMASK(19, 16), addr) > +#define VREG_ADDR(addr) FIELD_GET(GENMASK(19, 4), addr) > + > +enum { > + HW_ACCL_CLK = 0x3, > + HW_ACCL_VREG, > + HW_ACCL_BUS, > +}; > + > /* > * Here's a high level overview of how all the registers in RPMH work > * together: > @@ -557,7 +568,15 @@ static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs, > for_each_set_bit(j, &curr_enabled, MAX_CMDS_PER_TCS) { > addr = read_tcs_cmd(drv, drv->regs[RSC_DRV_CMD_ADDR], i, j); > for (k = 0; k < msg->num_cmds; k++) { > - if (addr == msg->cmds[k].addr) > + /* > + * Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte > + * aligned addresses associated with it. Ignore the offset to check > + * for in-flight VREG requests. > + */ > + if (ACCL_TYPE(msg->cmds[k].addr) == HW_ACCL_VREG && > + VREG_ADDR(msg->cmds[k].addr) == VREG_ADDR(addr)) > + return -EBUSY; > + else if (addr == msg->cmds[k].addr) > return -EBUSY; > } > } > > --- > base-commit: 943b9f0ab2cfbaea148dd6ac279957eb08b96904 > change-id: 20240117-rpmh-rsc-fixes-6c43c7051828 > > Best regards, > -- > Maulik Shah <quic_mkshah@quicinc.com> > >
On 1/19/2024 7:47 AM, Andrew Halaney wrote: > On Fri, Jan 19, 2024 at 01:56:54PM +0530, Maulik Shah wrote: >> Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte aligned >> addresses associated with it. These control voltage, enable state, mode, >> and in legacy targets, voltage headroom. The current in-flight request >> checking logic looks for exact address matches. Requests for different >> addresses of the same RPMh resource as thus not detected as in-flight. >> >> Enhance the in-flight request check for VREG requests by ignoring the >> address offset. This ensures that only one request is allowed to be >> in-flight for a given VREG resource. This is needed to avoid scenarios >> where request commands are carried out by RPMh hardware out-of-order >> leading to LDO regulator over-current protection triggering. >> >> Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > > Just noticed I commented on v1 when v2 was already out, sorry. Copy > pasting this just to keep it on the latest thread: > > Two minor things: > > 1. Does this deserve a Fixes: tag? > 2. The Signed-off-by chain here confuses me, you sent the patch > so your SOB should be last, but then that makes me believe Elliot > was the author which I don't think is reflected here (no From: > line). Please read [0] for a bit more details > > [0] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 > Maulik's S-o-B should be last. This change was authored by him in our downstream driver and this change was pointed out as also being a fix for the upstream driver. I helped rebase/apply the change to upstream to test and shared patch back with him for posting to the list. When he got the rebased patch, my S-o-B would've been last, but now need to be updated again so his is last. >> --- >> Changes in v2: >> - Use GENMASK() and FIELD_GET() >> - Link to v1: https://lore.kernel.org/r/20240117-rpmh-rsc-fixes-v1-1-71ee4f8f72a4@quicinc.com >> --- >> drivers/soc/qcom/rpmh-rsc.c | 21 ++++++++++++++++++++- >> 1 file changed, 20 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c >> index a021dc71807b..e480cde783fe 100644 >> --- a/drivers/soc/qcom/rpmh-rsc.c >> +++ b/drivers/soc/qcom/rpmh-rsc.c >> @@ -1,11 +1,13 @@ >> // SPDX-License-Identifier: GPL-2.0 >> /* >> * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. >> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved. >> */ >> >> #define pr_fmt(fmt) "%s " fmt, KBUILD_MODNAME >> >> #include <linux/atomic.h> >> +#include <linux/bitfield.h> >> #include <linux/cpu_pm.h> >> #include <linux/delay.h> >> #include <linux/interrupt.h> >> @@ -91,6 +93,15 @@ enum { >> #define CMD_STATUS_ISSUED BIT(8) >> #define CMD_STATUS_COMPL BIT(16) >> >> +#define ACCL_TYPE(addr) FIELD_GET(GENMASK(19, 16), addr) >> +#define VREG_ADDR(addr) FIELD_GET(GENMASK(19, 4), addr) >> + >> +enum { >> + HW_ACCL_CLK = 0x3, >> + HW_ACCL_VREG, >> + HW_ACCL_BUS, >> +}; >> + >> /* >> * Here's a high level overview of how all the registers in RPMH work >> * together: >> @@ -557,7 +568,15 @@ static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs, >> for_each_set_bit(j, &curr_enabled, MAX_CMDS_PER_TCS) { >> addr = read_tcs_cmd(drv, drv->regs[RSC_DRV_CMD_ADDR], i, j); >> for (k = 0; k < msg->num_cmds; k++) { >> - if (addr == msg->cmds[k].addr) >> + /* >> + * Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte >> + * aligned addresses associated with it. Ignore the offset to check >> + * for in-flight VREG requests. >> + */ >> + if (ACCL_TYPE(msg->cmds[k].addr) == HW_ACCL_VREG && >> + VREG_ADDR(msg->cmds[k].addr) == VREG_ADDR(addr)) >> + return -EBUSY; >> + else if (addr == msg->cmds[k].addr) >> return -EBUSY; >> } >> } >> >> --- >> base-commit: 943b9f0ab2cfbaea148dd6ac279957eb08b96904 >> change-id: 20240117-rpmh-rsc-fixes-6c43c7051828 >> >> Best regards, >> -- >> Maulik Shah <quic_mkshah@quicinc.com> >> >> >
On 1/19/24 09:26, Maulik Shah wrote: > Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte aligned > addresses associated with it. These control voltage, enable state, mode, > and in legacy targets, voltage headroom. The current in-flight request > checking logic looks for exact address matches. Requests for different > addresses of the same RPMh resource as thus not detected as in-flight. > > Enhance the in-flight request check for VREG requests by ignoring the > address offset. This ensures that only one request is allowed to be > in-flight for a given VREG resource. This is needed to avoid scenarios > where request commands are carried out by RPMh hardware out-of-order > leading to LDO regulator over-current protection triggering. > > Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> As others have pointed out, a fixes: would be in order. If you're going to resend, please name the enum but no biggie Konrad
On Fri, Jan 19, 2024 at 01:56:54PM +0530, Maulik Shah wrote: > Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte aligned > addresses associated with it. These control voltage, enable state, mode, > and in legacy targets, voltage headroom. The current in-flight request > checking logic looks for exact address matches. Requests for different > addresses of the same RPMh resource as thus not detected as in-flight. > > Enhance the in-flight request check for VREG requests by ignoring the > address offset. This ensures that only one request is allowed to be > in-flight for a given VREG resource. This is needed to avoid scenarios > where request commands are carried out by RPMh hardware out-of-order > leading to LDO regulator over-current protection triggering. > > Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> The s-o-b chain doesn't look right. > --- > Changes in v2: > - Use GENMASK() and FIELD_GET() > - Link to v1: https://lore.kernel.org/r/20240117-rpmh-rsc-fixes-v1-1-71ee4f8f72a4@quicinc.com > --- > drivers/soc/qcom/rpmh-rsc.c | 21 ++++++++++++++++++++- > 1 file changed, 20 insertions(+), 1 deletion(-) > > diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c > index a021dc71807b..e480cde783fe 100644 > --- a/drivers/soc/qcom/rpmh-rsc.c > +++ b/drivers/soc/qcom/rpmh-rsc.c > @@ -1,11 +1,13 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. > + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved. > */ > > #define pr_fmt(fmt) "%s " fmt, KBUILD_MODNAME > > #include <linux/atomic.h> > +#include <linux/bitfield.h> > #include <linux/cpu_pm.h> > #include <linux/delay.h> > #include <linux/interrupt.h> > @@ -91,6 +93,15 @@ enum { > #define CMD_STATUS_ISSUED BIT(8) > #define CMD_STATUS_COMPL BIT(16) > > +#define ACCL_TYPE(addr) FIELD_GET(GENMASK(19, 16), addr) Command DB is there so we don't have to make assumptions about the addresses of resources. As such, I dislike this define. > +#define VREG_ADDR(addr) FIELD_GET(GENMASK(19, 4), addr) > + > +enum { > + HW_ACCL_CLK = 0x3, > + HW_ACCL_VREG, > + HW_ACCL_BUS, We already define these in the kernel, but with different names: CMD_DB_HW_ARC, CMD_DB_HW_VRM, CMD_DB_HW_BCM. I see no reason to use different names for the same thing. > +}; > + > /* > * Here's a high level overview of how all the registers in RPMH work > * together: > @@ -557,7 +568,15 @@ static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs, > for_each_set_bit(j, &curr_enabled, MAX_CMDS_PER_TCS) { > addr = read_tcs_cmd(drv, drv->regs[RSC_DRV_CMD_ADDR], i, j); > for (k = 0; k < msg->num_cmds; k++) { > - if (addr == msg->cmds[k].addr) > + /* > + * Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte > + * aligned addresses associated with it. Ignore the offset to check > + * for in-flight VREG requests. > + */ > + if (ACCL_TYPE(msg->cmds[k].addr) == HW_ACCL_VREG && > + VREG_ADDR(msg->cmds[k].addr) == VREG_ADDR(addr)) I'm sure this work, at least for some targets, but I don't fancy encoding this information here. It feels like a hack. Furthermore, I really would like TP_printk() of trace_rpmh_send_msg() to be able to resolve the symbolic names for VRMs as well, and it would need the same information... Please consider how we can query command db for the type and/or grouping information. Regards, Bjorn > + return -EBUSY; > + else if (addr == msg->cmds[k].addr) > return -EBUSY; > } > } > > --- > base-commit: 943b9f0ab2cfbaea148dd6ac279957eb08b96904 > change-id: 20240117-rpmh-rsc-fixes-6c43c7051828 > > Best regards, > -- > Maulik Shah <quic_mkshah@quicinc.com> >
Hi, On 1/28/2024 9:13 AM, Bjorn Andersson wrote: > On Fri, Jan 19, 2024 at 01:56:54PM +0530, Maulik Shah wrote: >> >> Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > > The s-o-b chain doesn't look right. I will fix in v3. > >> --- >> >> +#define ACCL_TYPE(addr) FIELD_GET(GENMASK(19, 16), addr) > > Command DB is there so we don't have to make assumptions about the > addresses of resources. As such, I dislike this define. sure i will consider querying command db for resource type. > >> +#define VREG_ADDR(addr) FIELD_GET(GENMASK(19, 4), addr) >> + >> +enum { >> + HW_ACCL_CLK = 0x3, >> + HW_ACCL_VREG, >> + HW_ACCL_BUS, > > We already define these in the kernel, but with different names: > CMD_DB_HW_ARC, CMD_DB_HW_VRM, CMD_DB_HW_BCM. I see no reason to use > different names for the same thing. > >> +}; Right, I missed it, With querying cmd-db would not need this enum. >> + >> /* >> * Here's a high level overview of how all the registers in RPMH work >> * together: >> @@ -557,7 +568,15 @@ static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs, >> for_each_set_bit(j, &curr_enabled, MAX_CMDS_PER_TCS) { >> addr = read_tcs_cmd(drv, drv->regs[RSC_DRV_CMD_ADDR], i, j); >> for (k = 0; k < msg->num_cmds; k++) { >> - if (addr == msg->cmds[k].addr) >> + /* >> + * Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte >> + * aligned addresses associated with it. Ignore the offset to check >> + * for in-flight VREG requests. >> + */ >> + if (ACCL_TYPE(msg->cmds[k].addr) == HW_ACCL_VREG && >> + VREG_ADDR(msg->cmds[k].addr) == VREG_ADDR(addr)) > > I'm sure this work, at least for some targets, but I don't fancy > encoding this information here. It feels like a hack. > > Furthermore, I really would like TP_printk() of trace_rpmh_send_msg() to > be able to resolve the symbolic names for VRMs as well, and it would > need the same information... I can update in separate patch for trace_() to resolve symbolic names. > > Please consider how we can query command db for the type and/or grouping > information. Sure, i will update in v3 to query command db for the type. Thanks, Maulik
Hi, On 1/19/2024 9:17 PM, Andrew Halaney wrote: >> Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > > Just noticed I commented on v1 when v2 was already out, sorry. Copy > pasting this just to keep it on the latest thread: > > Two minor things: > > 1. Does this deserve a Fixes: tag? > 2. The Signed-off-by chain here confuses me, you sent the patch > so your SOB should be last, but then that makes me believe Elliot > was the author which I don't think is reflected here (no From: > line). Please read [0] for a bit more details > > [0] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 Yes, this looks good to have patch, will include fixes: tag and will fix SOB in v3. Thanks, Maulik
diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c index a021dc71807b..e480cde783fe 100644 --- a/drivers/soc/qcom/rpmh-rsc.c +++ b/drivers/soc/qcom/rpmh-rsc.c @@ -1,11 +1,13 @@ // SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved. */ #define pr_fmt(fmt) "%s " fmt, KBUILD_MODNAME #include <linux/atomic.h> +#include <linux/bitfield.h> #include <linux/cpu_pm.h> #include <linux/delay.h> #include <linux/interrupt.h> @@ -91,6 +93,15 @@ enum { #define CMD_STATUS_ISSUED BIT(8) #define CMD_STATUS_COMPL BIT(16) +#define ACCL_TYPE(addr) FIELD_GET(GENMASK(19, 16), addr) +#define VREG_ADDR(addr) FIELD_GET(GENMASK(19, 4), addr) + +enum { + HW_ACCL_CLK = 0x3, + HW_ACCL_VREG, + HW_ACCL_BUS, +}; + /* * Here's a high level overview of how all the registers in RPMH work * together: @@ -557,7 +568,15 @@ static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs, for_each_set_bit(j, &curr_enabled, MAX_CMDS_PER_TCS) { addr = read_tcs_cmd(drv, drv->regs[RSC_DRV_CMD_ADDR], i, j); for (k = 0; k < msg->num_cmds; k++) { - if (addr == msg->cmds[k].addr) + /* + * Each RPMh VREG accelerator resource has 3 or 4 contiguous 4-byte + * aligned addresses associated with it. Ignore the offset to check + * for in-flight VREG requests. + */ + if (ACCL_TYPE(msg->cmds[k].addr) == HW_ACCL_VREG && + VREG_ADDR(msg->cmds[k].addr) == VREG_ADDR(addr)) + return -EBUSY; + else if (addr == msg->cmds[k].addr) return -EBUSY; } }