Message ID | 20240226-rpmhpd-enable-corner-fix-v1-1-68c004cec48c@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-82550-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp2438340dyb; Mon, 26 Feb 2024 17:46:12 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXvV/YbStH/V8Z/5IFi9ANNQQQlXXhNthbBVqAvlni5vSg9Pyei3tNWIadQlrg5FVOeP9L+Z1AS/iyFbYyPdHWiI35ROg== X-Google-Smtp-Source: AGHT+IE5j1kLubsH5WGx46bEuvjnmZx4l5WZubPxA0P8+uScN7hJdPxydLR18kJKlpW+/ww0+3cZ X-Received: by 2002:a05:6a21:9183:b0:1a0:df61:7948 with SMTP id tp3-20020a056a21918300b001a0df617948mr1157705pzb.54.1708998372360; Mon, 26 Feb 2024 17:46:12 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708998372; cv=pass; d=google.com; s=arc-20160816; b=UivyqRYMt/gqUg5hJdrJXGWOmSx+/sFvFqKwmx5zPE87ng8kS2k8H3dq+46RoIWgyt hoJzyo75ZXpCeJXGhZvogXKf0TpzZ7h5352VHxKo62ymrWIbXACf6GbdhQxKhho8NgJ9 0RGI9nZOqlrvlVbC7U9DIOzWnLIfsJNVihY9baEPisEhM97AM0732OSwUwN5te1NTnR4 GdZTtH0t8rweiTV0t346GjRofrUNoEMbSNiXqq4wPdKvh08xIA5x+96kivl2H0Ab+EBq 9iBUJgqjcN8mj3UlJm4+GM8am+PkuC143Lz2MdAV/vzNVPWSvIxlYm8aeIVWG14MgGky cJUw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=reply-to:cc:to:message-id:content-transfer-encoding:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:subject:date :from:dkim-signature; bh=mrL75dfaTnozTIg1ue1J871wmRlVAQyDbI0d60vIOos=; fh=oGwo46j1g74zwVx4QNoQ5l3zcTYHAuAGDAk52Cp2mhU=; b=r3vFUKTnEDw470tMWZkig4IoILeVc3EmOdz9yfbc38PJG/TvUU+MR8OhtCh2ymeS6X 11KTUfhoXKIb/t78oOfwSNWfAhJYLmwCJJlT7Gmwnnxnw2thOHesFaw2C57pNbOEJqwm XXZqKjf1/+RsNjFoSVVC7bvslUoXZXfHjCxxEfigUs+a79Gxw0D2Mywmsym7ENIIblMV coFHSUuX69YLi+r2a9giA60T0SV8tJYL1AYJkhWf4IJIkqZEF2snkS/V6/gfatrTGbNY naH0jUFQpe9YU+rVElUiXMRwLHz6u1PQYD1Aygv85rqlfiL7sEa2UiF1O2ADPUyE3KbL iCQQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=T5VWn8dP; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-82550-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-82550-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id s4-20020a170902ea0400b001d9b8bc0fd8si520461plg.68.2024.02.26.17.46.12 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 17:46:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-82550-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=T5VWn8dP; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-82550-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-82550-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id AEE0D284FA4 for <ouuuleilei@gmail.com>; Tue, 27 Feb 2024 01:46:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0AA79FBE1; Tue, 27 Feb 2024 01:45:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T5VWn8dP" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 17E1A2916; Tue, 27 Feb 2024 01:45:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708998349; cv=none; b=o/yMwPzMqufWkUzk/rjBp6W2M44mlXauMqRiTdTKy3bUtZVnHCk9CJJ+3Y8Ia0dYe1MWQpTa8DK/CQx3Xk7K83++FX6uy0LP99NG6K1C/Cpkx+S3fJQacJMkdRi9hgC9OZW8nVUcay+rOetq1JnPK7I78M7VepbbVBwzWFTogOM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708998349; c=relaxed/simple; bh=SCXTahozD0TxiPX08IBsjicUaCXkNVF/+0u0TFeGY0I=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=gFVcC15jdQlKc9qpygUl5zHFTgUy2K3GwCz2IoYj1PxGT4yiC2dExQxOVidKn8eSsBBSU1sAR0ZZ1r/SiI0xx8PRE0xRp4KRLKzxXgPqOjUdjuJMN5+RpzpATo0K1HSd8s7wo0gxovmvbSipjgrdBnAIyIQwHtLhhYGa4TDZYwU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T5VWn8dP; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPS id 91AB6C433F1; Tue, 27 Feb 2024 01:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708998348; bh=SCXTahozD0TxiPX08IBsjicUaCXkNVF/+0u0TFeGY0I=; h=From:Date:Subject:To:Cc:Reply-To:From; b=T5VWn8dPeHK/BBBoReSynEEv2vsnw2mgT+50PP5WMZn5QWRppdg3qhNAtJWbVG8mw K2qZXAuICBrlc4chwCrYja/aWcxhztOBun55O6kdCGDPnt7nMywIX2xe0/Ev8KzFyA TzxH9xeeNsFGfC6+U0jBvGZzWPiSubayJsafM68G3BYVg9a5uq6ePqLOVmhb2YKDMz ZoXpx7xEF4SQghz8q/x5yxByMhwaWi+7/vlRfTlnrXZFQeoIPiDM3a+8OPn9bLivfU qyN123mGd6GlLAcE7qiKGbUNiE2GptW8L82QXeisl4DEuraUijFLwkK7la6UE/2Nwy dCq5Wgr7oNZuw== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75FB0C48BF6; Tue, 27 Feb 2024 01:45:48 +0000 (UTC) From: Bjorn Andersson via B4 Relay <devnull+quic_bjorande.quicinc.com@kernel.org> Date: Mon, 26 Feb 2024 17:49:57 -0800 Subject: [PATCH] pmdomain: qcom: rpmhpd: Fix enabled_corner aggregation 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: <20240226-rpmhpd-enable-corner-fix-v1-1-68c004cec48c@quicinc.com> X-B4-Tracking: v=1; b=H4sIAMQ/3WUC/x2MwQqDMBAFf0X27EIMbWz9FfEQ40tdaGPYgBTEf zd4nIGZgwpUUGhoDlLsUmRLFbq2obD69AHLUpmssQ9jrWPNvzUvjOTnLzhsmqAc5c/hCdNH9PP 75ajmWVH1vR6n87wAZf/r0WoAAAA= To: Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Ulf Hansson <ulf.hansson@linaro.org>, Stephen Boyd <swboyd@chromium.org>, Johan Hovold <johan+linaro@kernel.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Johan Hovold <johan@kernel.org>, stable@vger.kernel.org, Bjorn Andersson <quic_bjorande@quicinc.com> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=openpgp-sha256; l=3004; i=quic_bjorande@quicinc.com; h=from:subject:message-id; bh=8TOgtVhYO01rdpfAVMwK9WI6pflXIuB4DQQcEbm8Zmw=; b=owEBgwJ8/ZANAwAIAQsfOT8Nma3FAcsmYgBl3T/r3KXQprzkHna4SseXUKD0ooMTxVhZKDW9m mWQ0+8CJmiJAkkEAAEIADMWIQQF3gPMXzXqTwlm1SULHzk/DZmtxQUCZd0/6xUcYW5kZXJzc29u QGtlcm5lbC5vcmcACgkQCx85Pw2ZrcUW4w//YlZS5dc2FBsqrTddOHzidbibnEQwzDs1tWPmyqH jKcngixr+2OP4XYmR/HEBprSaEe/UXls884Ema6ucg5EQtpOIrMqfxWHEptQljfkVwuhHxiav5y hR9pSDgBfIkmZYnlp+AI8VM+pQyqQB3nTZ0mgu1YTxtEIomgOZ8ifzTXMPvSrtWtU0pEXDpzE8y amaeZShoEQMs238EpgfWhbFTKWqPlUKCdVmjyjIZ/TAnE4haRDpKnCInDvpGaTXJSeK+X1cdzAu Iduu4QSFutGx/mTaLJF3I4UqWzUrFmEy/apAtGhOGnpNTkrAjR/euygJQY9OREp0OEvM+FEfjzj yn0Xi/zNqMBnEzn5vd7340NM6wSq6oHBJp9dmzLyIAimCcN9A5z769c8SZ+hacWXEZlNqdizJ34 Wv8iaWi/Rkzc7XUG/Tlx+jtdEqS1313uA1f3HPDfr3VtQ+mN4t7Ex3z4qLFKaslXbunA4AEBLK9 INzGCitwuDBUSh2NtR0fu5ZOAiQCb7g+gIMON1aDQcD39lbnwfX8rMxYv9zNYZvtnr7z4NbUkAF 0G/5IeNCRrIoQ42hHlRhVCkG5WnjZRGZbgLEIxHyxLHVUnNPXs+bCCftycKzr4BIUDfIK9W4TGz /ltQREquxuqJMmPH8tYwmHjE2s2CdDyeBQHzWutRavxA= X-Developer-Key: i=quic_bjorande@quicinc.com; a=openpgp; fpr=05DE03CC5F35EA4F0966D5250B1F393F0D99ADC5 X-Endpoint-Received: by B4 Relay for quic_bjorande@quicinc.com/default with auth_id=118 X-Original-From: Bjorn Andersson <quic_bjorande@quicinc.com> Reply-To: <quic_bjorande@quicinc.com> X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792014677010831272 X-GMAIL-MSGID: 1792014677010831272 |
Series |
pmdomain: qcom: rpmhpd: Fix enabled_corner aggregation
|
|
Commit Message
Bjorn Andersson via B4 Relay
Feb. 27, 2024, 1:49 a.m. UTC
From: Bjorn Andersson <quic_bjorande@quicinc.com> Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain")' aimed to make sure that a power-domain that is being enabled without any particular performance-state requested will at least turn the rail on, to avoid filling DeviceTree with otherwise unnecessary required-opps properties. But in the event that aggregation happens on a disabled power-domain, with an enabled peer without performance-state, both the local and peer corner are 0. The peer's enabled_corner is not considered, with the result that the underlying (shared) resource is disabled. One case where this can be observed is when the display stack keeps mmcx enabled (but without a particular performance-state vote) in order to access registers and sync_state happens in the rpmhpd driver. As mmcx_ao is flushed the state of the peer (mmcx) is not considered and mmcx_ao ends up turning off "mmcx.lvl" underneath mmcx. This has been observed several times, but has been painted over in DeviceTree by adding an explicit vote for the lowest non-disabled performance-state. Fixes: e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain") Reported-by: Johan Hovold <johan@kernel.org> Closes: https://lore.kernel.org/linux-arm-msm/ZdMwZa98L23mu3u6@hovoldconsulting.com/ Cc: <stable@vger.kernel.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> --- This issue is the root cause of a display regression on SC8280XP boards, resulting in the system often resetting during boot. It was exposed by the refactoring of the DisplayPort driver in v6.8-rc1. --- drivers/pmdomain/qcom/rpmhpd.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d change-id: 20240226-rpmhpd-enable-corner-fix-c5e07fe7b986 Best regards,
Comments
On 2/27/24 02:49, Bjorn Andersson via B4 Relay wrote: > From: Bjorn Andersson <quic_bjorande@quicinc.com> > > Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable > the domain")' aimed to make sure that a power-domain that is being > enabled without any particular performance-state requested will at least > turn the rail on, to avoid filling DeviceTree with otherwise unnecessary > required-opps properties. > > But in the event that aggregation happens on a disabled power-domain, with > an enabled peer without performance-state, both the local and peer > corner are 0. The peer's enabled_corner is not considered, with the > result that the underlying (shared) resource is disabled. > > One case where this can be observed is when the display stack keeps mmcx > enabled (but without a particular performance-state vote) in order to > access registers and sync_state happens in the rpmhpd driver. As mmcx_ao > is flushed the state of the peer (mmcx) is not considered and mmcx_ao > ends up turning off "mmcx.lvl" underneath mmcx. This has been observed > several times, but has been painted over in DeviceTree by adding an > explicit vote for the lowest non-disabled performance-state. > > Fixes: e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain") > Reported-by: Johan Hovold <johan@kernel.org> > Closes: https://lore.kernel.org/linux-arm-msm/ZdMwZa98L23mu3u6@hovoldconsulting.com/ > Cc: <stable@vger.kernel.org> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > This issue is the root cause of a display regression on SC8280XP boards, > resulting in the system often resetting during boot. It was exposed by > the refactoring of the DisplayPort driver in v6.8-rc1. > --- Very good find, thanks! Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Konrad
On Tue, 27 Feb 2024 at 03:45, Bjorn Andersson via B4 Relay <devnull+quic_bjorande.quicinc.com@kernel.org> wrote: > > From: Bjorn Andersson <quic_bjorande@quicinc.com> > > Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable > the domain")' aimed to make sure that a power-domain that is being > enabled without any particular performance-state requested will at least > turn the rail on, to avoid filling DeviceTree with otherwise unnecessary > required-opps properties. > > But in the event that aggregation happens on a disabled power-domain, with > an enabled peer without performance-state, both the local and peer > corner are 0. The peer's enabled_corner is not considered, with the > result that the underlying (shared) resource is disabled. > > One case where this can be observed is when the display stack keeps mmcx > enabled (but without a particular performance-state vote) in order to > access registers and sync_state happens in the rpmhpd driver. As mmcx_ao > is flushed the state of the peer (mmcx) is not considered and mmcx_ao > ends up turning off "mmcx.lvl" underneath mmcx. This has been observed > several times, but has been painted over in DeviceTree by adding an > explicit vote for the lowest non-disabled performance-state. > > Fixes: e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain") > Reported-by: Johan Hovold <johan@kernel.org> > Closes: https://lore.kernel.org/linux-arm-msm/ZdMwZa98L23mu3u6@hovoldconsulting.com/ > Cc: <stable@vger.kernel.org> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > This issue is the root cause of a display regression on SC8280XP boards, > resulting in the system often resetting during boot. It was exposed by > the refactoring of the DisplayPort driver in v6.8-rc1. > --- > drivers/pmdomain/qcom/rpmhpd.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Probably once this lands we can drop explicit required-opps properties.
On 2/26/2024 5:49 PM, Bjorn Andersson via B4 Relay wrote: > From: Bjorn Andersson <quic_bjorande@quicinc.com> > > Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable > the domain")' aimed to make sure that a power-domain that is being > enabled without any particular performance-state requested will at least > turn the rail on, to avoid filling DeviceTree with otherwise unnecessary > required-opps properties. > > But in the event that aggregation happens on a disabled power-domain, with > an enabled peer without performance-state, both the local and peer > corner are 0. The peer's enabled_corner is not considered, with the > result that the underlying (shared) resource is disabled. > > One case where this can be observed is when the display stack keeps mmcx > enabled (but without a particular performance-state vote) in order to > access registers and sync_state happens in the rpmhpd driver. As mmcx_ao > is flushed the state of the peer (mmcx) is not considered and mmcx_ao > ends up turning off "mmcx.lvl" underneath mmcx. This has been observed > several times, but has been painted over in DeviceTree by adding an > explicit vote for the lowest non-disabled performance-state. > > Fixes: e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain") > Reported-by: Johan Hovold <johan@kernel.org> > Closes: https://lore.kernel.org/linux-arm-msm/ZdMwZa98L23mu3u6@hovoldconsulting.com/ > Cc: <stable@vger.kernel.org> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > This issue is the root cause of a display regression on SC8280XP boards, > resulting in the system often resetting during boot. It was exposed by > the refactoring of the DisplayPort driver in v6.8-rc1. > --- > drivers/pmdomain/qcom/rpmhpd.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Quoting Bjorn Andersson via B4 Relay (2024-02-26 17:49:57) > From: Bjorn Andersson <quic_bjorande@quicinc.com> > > Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable > the domain")' aimed to make sure that a power-domain that is being > enabled without any particular performance-state requested will at least > turn the rail on, to avoid filling DeviceTree with otherwise unnecessary > required-opps properties. > > But in the event that aggregation happens on a disabled power-domain, with > an enabled peer without performance-state, both the local and peer > corner are 0. The peer's enabled_corner is not considered, with the > result that the underlying (shared) resource is disabled. > > One case where this can be observed is when the display stack keeps mmcx > enabled (but without a particular performance-state vote) in order to > access registers and sync_state happens in the rpmhpd driver. As mmcx_ao > is flushed the state of the peer (mmcx) is not considered and mmcx_ao > ends up turning off "mmcx.lvl" underneath mmcx. This has been observed > several times, but has been painted over in DeviceTree by adding an > explicit vote for the lowest non-disabled performance-state. > > Fixes: e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain") > Reported-by: Johan Hovold <johan@kernel.org> > Closes: https://lore.kernel.org/linux-arm-msm/ZdMwZa98L23mu3u6@hovoldconsulting.com/ > Cc: <stable@vger.kernel.org> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- Reviewed-by: Stephen Boyd <swboyd@chromium.org>
On Mon, Feb 26, 2024 at 05:49:57PM -0800, Bjorn Andersson via B4 Relay wrote: > From: Bjorn Andersson <quic_bjorande@quicinc.com> > > Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable > the domain")' aimed to make sure that a power-domain that is being > enabled without any particular performance-state requested will at least > turn the rail on, to avoid filling DeviceTree with otherwise unnecessary > required-opps properties. > > But in the event that aggregation happens on a disabled power-domain, with > an enabled peer without performance-state, both the local and peer > corner are 0. The peer's enabled_corner is not considered, with the > result that the underlying (shared) resource is disabled. > > One case where this can be observed is when the display stack keeps mmcx > enabled (but without a particular performance-state vote) in order to > access registers and sync_state happens in the rpmhpd driver. As mmcx_ao > is flushed the state of the peer (mmcx) is not considered and mmcx_ao > ends up turning off "mmcx.lvl" underneath mmcx. This has been observed > several times, but has been painted over in DeviceTree by adding an > explicit vote for the lowest non-disabled performance-state. > > Fixes: e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain") > Reported-by: Johan Hovold <johan@kernel.org> > Closes: https://lore.kernel.org/linux-arm-msm/ZdMwZa98L23mu3u6@hovoldconsulting.com/ > Cc: <stable@vger.kernel.org> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > This issue is the root cause of a display regression on SC8280XP boards, > resulting in the system often resetting during boot. It was exposed by > the refactoring of the DisplayPort driver in v6.8-rc1. This fixes the hard resets I've been seeing since rc1 when initialising the display subsystem of the Lenovo ThinkPad X13s at boot. With some instrumentation added I can see the resets coinciding with the call to rpmhpd_aggregate_corner() for 'mx_ao': Tested-by: Johan Hovold <johan+linaro@kernel.org>
On Tue, 27 Feb 2024 at 02:45, Bjorn Andersson via B4 Relay <devnull+quic_bjorande.quicinc.com@kernel.org> wrote: > > From: Bjorn Andersson <quic_bjorande@quicinc.com> > > Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable > the domain")' aimed to make sure that a power-domain that is being > enabled without any particular performance-state requested will at least > turn the rail on, to avoid filling DeviceTree with otherwise unnecessary > required-opps properties. > > But in the event that aggregation happens on a disabled power-domain, with > an enabled peer without performance-state, both the local and peer > corner are 0. The peer's enabled_corner is not considered, with the > result that the underlying (shared) resource is disabled. > > One case where this can be observed is when the display stack keeps mmcx > enabled (but without a particular performance-state vote) in order to > access registers and sync_state happens in the rpmhpd driver. As mmcx_ao > is flushed the state of the peer (mmcx) is not considered and mmcx_ao > ends up turning off "mmcx.lvl" underneath mmcx. This has been observed > several times, but has been painted over in DeviceTree by adding an > explicit vote for the lowest non-disabled performance-state. > > Fixes: e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain") > Reported-by: Johan Hovold <johan@kernel.org> > Closes: https://lore.kernel.org/linux-arm-msm/ZdMwZa98L23mu3u6@hovoldconsulting.com/ > Cc: <stable@vger.kernel.org> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Applied for fixes, thanks! Kind regards Uffe > --- > This issue is the root cause of a display regression on SC8280XP boards, > resulting in the system often resetting during boot. It was exposed by > the refactoring of the DisplayPort driver in v6.8-rc1. > --- > drivers/pmdomain/qcom/rpmhpd.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c > index 3078896b1300..47df910645f6 100644 > --- a/drivers/pmdomain/qcom/rpmhpd.c > +++ b/drivers/pmdomain/qcom/rpmhpd.c > @@ -692,6 +692,7 @@ static int rpmhpd_aggregate_corner(struct rpmhpd *pd, unsigned int corner) > unsigned int active_corner, sleep_corner; > unsigned int this_active_corner = 0, this_sleep_corner = 0; > unsigned int peer_active_corner = 0, peer_sleep_corner = 0; > + unsigned int peer_enabled_corner; > > if (pd->state_synced) { > to_active_sleep(pd, corner, &this_active_corner, &this_sleep_corner); > @@ -701,9 +702,11 @@ static int rpmhpd_aggregate_corner(struct rpmhpd *pd, unsigned int corner) > this_sleep_corner = pd->level_count - 1; > } > > - if (peer && peer->enabled) > - to_active_sleep(peer, peer->corner, &peer_active_corner, > + if (peer && peer->enabled) { > + peer_enabled_corner = max(peer->corner, peer->enable_corner); > + to_active_sleep(peer, peer_enabled_corner, &peer_active_corner, > &peer_sleep_corner); > + } > > active_corner = max(this_active_corner, peer_active_corner); > > > --- > base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d > change-id: 20240226-rpmhpd-enable-corner-fix-c5e07fe7b986 > > Best regards, > -- > Bjorn Andersson <quic_bjorande@quicinc.com> >
diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c index 3078896b1300..47df910645f6 100644 --- a/drivers/pmdomain/qcom/rpmhpd.c +++ b/drivers/pmdomain/qcom/rpmhpd.c @@ -692,6 +692,7 @@ static int rpmhpd_aggregate_corner(struct rpmhpd *pd, unsigned int corner) unsigned int active_corner, sleep_corner; unsigned int this_active_corner = 0, this_sleep_corner = 0; unsigned int peer_active_corner = 0, peer_sleep_corner = 0; + unsigned int peer_enabled_corner; if (pd->state_synced) { to_active_sleep(pd, corner, &this_active_corner, &this_sleep_corner); @@ -701,9 +702,11 @@ static int rpmhpd_aggregate_corner(struct rpmhpd *pd, unsigned int corner) this_sleep_corner = pd->level_count - 1; } - if (peer && peer->enabled) - to_active_sleep(peer, peer->corner, &peer_active_corner, + if (peer && peer->enabled) { + peer_enabled_corner = max(peer->corner, peer->enable_corner); + to_active_sleep(peer, peer_enabled_corner, &peer_active_corner, &peer_sleep_corner); + } active_corner = max(this_active_corner, peer_active_corner);