From mboxrd@z Thu Jan 1 00:00:00 1970 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 D504B2C21FF for ; Thu, 26 Feb 2026 13:35:58 +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=1772112960; cv=none; b=PxMEH63lXMPf2fT+Yq+Rir2EUCcj/liuNB8OGnnzSvVAtVpE/OCC205YzvQ6CxW5vAWLMCHyXddvwol0WeBW7TlWfgM0tP/hz7nTf0wBRhdGNvu10ztJt6f+h7J1tmjMyapxZAPjF92wJ6fPfd1fccisqX1Yqvmoo5Pb6rUS9XM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772112960; c=relaxed/simple; bh=dfp57Wh7NygrlbAmtuE1trvXXicq9uTT2x5859/wlj4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=A0f7yVzwSL44epV4raBkVQcPi0/4+2qI0aSYNLVIItfWWl5d3tKRISN9Ic2kRanNYmeoOPDicPutZpIntahzFToOjq8oNI9gOUMV3hJ0hH+uVC7IeE/gE/1RhWZjq5hCpOov7N/5tq+Z8IMUUXXGPpO+/2FbVcK6SO4Bk4TAJmQ= 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=Ea09rAuf; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=GeNVU4tS; arc=none smtp.client-ip=205.220.180.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="Ea09rAuf"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="GeNVU4tS" Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 61QAL81F3987252 for ; Thu, 26 Feb 2026 13:35:58 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= DS2CxEyTgthuGQAVEtlYxEVVfe8xEdQStYBbw5wclOI=; b=Ea09rAufso4PE63R c9tJcD9lzTBGPzZVxa35/fpMuphM+jvxULuB3yEpMdpnSAkq0X5HfZs4Avjbr4DZ AngN5q+gWk+8PbXIsX1NPX6vFRnVedlL86eQ5xrWq36rFfgfxYtzWo1Bt9ic7CNk Jv1C/eZ1ngLecugaK/NgJcr0tgoS2R//ItkSHpbLuA4fCJ8VKjiLosgdLN0uAU38 0PI6UH7ygZOfKbGwjPJyHI2v4ZOe+8VTpF7sDAE41p6WwHd8qITqCXgWk7FGWniX IQQ7DR1JQVuCTuSeCVqeaZm8043sg36wxw2RqPV67pewWfCqIJSnJbuiEcojRuAs cZg0vg== Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cjdph1t67-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 26 Feb 2026 13:35:57 +0000 (GMT) Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-8c7177d4ab4so76273485a.2 for ; Thu, 26 Feb 2026 05:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772112957; x=1772717757; 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=DS2CxEyTgthuGQAVEtlYxEVVfe8xEdQStYBbw5wclOI=; b=GeNVU4tSSDu4lk4lSONP4glWHaXU887RH2+bl2VLVMxMBX2Qbzig+GgdWincrP5OCJ eW6JJmgZmNbFrOEGNgQhQ2vTafzQ9Qqc5XYM4NkIbPOY+HB/4kPav+X+Zy397KtP0Xe1 2TqjCSzXLY2aab6uur2QbPJe3YEmQY8Su3vOXFn1c9hi1fC8id4piNq0jjjjoUvjG6Sr nh91VWsUxL7Ufo8zR2BJ84ggY+ITgwoSmhGCrupIRGS6PoTCOxXe3/51JGpQjBujA7nn qnndyYgx9S3v9l8x8UUt14342QgEBQfyBoG0ffYmg8N3M+iw7lyc1w+wsiPMQDBul4ov wMEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772112957; x=1772717757; 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=DS2CxEyTgthuGQAVEtlYxEVVfe8xEdQStYBbw5wclOI=; b=T8VosDe9fD1dtcH9s4/1zyMxTNGKowA8qeAsm0J+tC4fv0MKjBYHbEUFcRFopEEcjf m12k/bwZFV36FBEsSD6c81251e3j3pMsTp7YBNri8cpNx9uX/K6rUQJOoqymRWCKZ10j zvkTApUqO2XbX36hf1mmuVJgZm7JU21Mfpn0URd2HJpiwDdnOe93z81dbjZpOazir8Sn d1FNj2K5DhDEe2ywyIhA8wWrKXyiJz/1hDq2Bq36bZcftdvSPeuZQ+fIINKT0e0zJqIa e7vm0EYv95tYfuRub6iWgq8EwbPE0q7bje7fRpjkos+weFLHdqjqgQc6Txii4tuINk0L 75eA== X-Forwarded-Encrypted: i=1; AJvYcCUibUWkpqwjJlzbX5kDmVTAWEFjR3jqE7wzexk0fWUsszrdlv2lgiqerIaM3jyOGkHQMHlECSSjE9B6sNg=@vger.kernel.org X-Gm-Message-State: AOJu0YzuhBN/WYIxAM8+acNaImlZKurr2b4UZdbUQ6GtTTUSD457QTm4 EZzccBh6m++NZksF5kRfdc63VZAfFSTNKcTDmdletDWKeehOVZI0Tnywm2pE6sbcfopNwdPTPu+ rii+X73S1vnXXSSq2GIz1Tm3X5IolVqXrXl0gf2zu4rfKiQN+mV8280Y3Z3E/A6HxtDs= X-Gm-Gg: ATEYQzzTQUkPnWr5GCkGYr2hHM/s1GSY2BgZM75ZAIslVFxyuHpgD1GFKT7nLJuTZW9 zS4YgLSsfozS78H50pmtEyuMnZORCLIH3QINhkpmb4LMl0J4DkcaioMfKIsWjcowaJXeC7ERabb d4zB/vyLQi67azP/BT/JX7F2AyGyODc59qeyfkVp1oepitY0/PTuJf5YDnw79dKimwDAZNe/7VE gX4Ny7HXGXEBP7WjZvV8KL7XabVNe/A53uArLjUrUrzrRoFe1UTcLDDH9gXTWE0uBSwoP7NL3aH bblqOjqk1qeeZGM6/wLF1tUovtI1BINa8MuDP8F1ydLT0qArl1hFY7X+Xwc3NQAuMPqvYRbiS+9 ZuSmeK9ZASpoA895H5vC98FPConeMtq+fa597Dxj5VI1B9W6lybzLNgIWkeTP70wUoZ5562DrAh GZC4Q= X-Received: by 2002:a05:620a:4093:b0:8cb:71e3:242c with SMTP id af79cd13be357-8cb8ca936bamr1771696185a.8.1772112956864; Thu, 26 Feb 2026 05:35:56 -0800 (PST) X-Received: by 2002:a05:620a:4093:b0:8cb:71e3:242c with SMTP id af79cd13be357-8cb8ca936bamr1771692885a.8.1772112956297; Thu, 26 Feb 2026 05:35:56 -0800 (PST) Received: from [192.168.119.254] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b935ab13540sm56921666b.11.2026.02.26.05.35.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Feb 2026 05:35:55 -0800 (PST) Message-ID: Date: Thu, 26 Feb 2026 14:35:52 +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 1/2] drm/msm/dpu: fix mismatch between power and frequency To: yuanjiey , Dmitry Baryshkov Cc: robin.clark@oss.qualcomm.com, lumag@kernel.org, abhinav.kumar@linux.dev, jesszhan0024@gmail.com, sean@poorly.run, marijn.suijten@somainline.org, airlied@gmail.com, simona@ffwll.ch, krzysztof.kozlowski@linaro.org, linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org, tingwei.zhang@oss.qualcomm.com, aiqun.yu@oss.qualcomm.com, yongxing.mou@oss.qualcomm.com References: <20260109083808.1047-1-yuanjie.yang@oss.qualcomm.com> <20260109083808.1047-2-yuanjie.yang@oss.qualcomm.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: qtD--bB-snX18Rrw3glXPJ6p2sa-KrBq X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMjI2MDEyMyBTYWx0ZWRfX/HUYQsWqm4bt bb3sBJIKQJKYTw9JFfoOC2TQirv/uqaRkwM48MdU3T6Ve1LLojZFD46N9u3HJqSU2oGwtST5Qct yO8mEMODRR015cDxcf0a0Rgo5l/0tO+iLOXUUNxUaJaktHvEGPSLEqilhu4IAIUG4L94xUqvbMU wCEb3roO49PwZ4DzaWEsBZS8kU6wveW4HurqtkWjN+s/SV1UmIRnvnIEbQqOOvEUt5+lh2vAREp 5W1RMPT2zhxWKTabiExMpOe8VW8Ap5UmkI+9eEpcKd4OLDchSz87dJ0u4vVRbekhDiZn8Vo/nyb KVvAvP7jN08Mw8j9WGcW+a/fUzpe3gYNUH4YBb7X/NI37+cMCVqycdwTd9qukvnNjGnGe4S5d+Z 7oOXpCaAKV/PJF9FUwyufGsFfa6HPJsZ1uyfDTPhklRobAsJhtdJVIpX21eHJF7eij6ibkDlmFA eDYNh0vfRlDDjXEW6Zg== X-Authority-Analysis: v=2.4 cv=NJLYOk6g c=1 sm=1 tr=0 ts=69a04c3d cx=c_pps a=hnmNkyzTK/kJ09Xio7VxxA==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=HzLeVaNsDn8A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=EUspDBNiAAAA:8 a=JKcAygG6zsn5jYD1T1IA:9 a=QEXdDO2ut3YA:10 a=PEH46H7Ffwr30OY-TuGO:22 X-Proofpoint-GUID: qtD--bB-snX18Rrw3glXPJ6p2sa-KrBq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-02-25_04,2026-02-26_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 suspectscore=0 malwarescore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2602260123 On 1/12/26 9:25 AM, yuanjiey wrote: > On Mon, Jan 12, 2026 at 09:38:41AM +0200, Dmitry Baryshkov wrote: >> On Mon, 12 Jan 2026 at 08:23, yuanjiey wrote: >>> >>> On Fri, Jan 09, 2026 at 05:22:37PM +0200, Dmitry Baryshkov wrote: >>>> On Fri, Jan 09, 2026 at 04:38:07PM +0800, yuanjie yang wrote: >>>>> From: Yuanjie Yang >>>>> >>>>> During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops >>>>> the MMCX rail to MIN_SVS while the core clock frequency remains at its >>>>> original (highest) rate. When runtime resume re-enables the clock, this >>>>> may result in a mismatch between the rail voltage and the clock rate. >>>>> >>>>> For example, in the DPU bind path, the sequence could be: >>>>> cpu0: dev_sync_state -> rpmhpd_sync_state >>>>> cpu1: dpu_kms_hw_init >>>>> timeline 0 ------------------------------------------------> t >>>>> >>>>> After rpmhpd_sync_state, the voltage performance is no longer guaranteed >>>>> to stay at the highest level. During dpu_kms_hw_init, calling >>>>> dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to >>>>> fall to MIN_SVS while the core clock is still at its maximum frequency. >>>> >>>> Ah, I see. dev_pm_set_rate(0) transforms to _disable_opp_table(), which >>>> doesn't do anything with clocks. I think we should have a call to >>>> clk_disable_unprepare() before that and clk_prepare_enable() in the >>>> resume path. >>> >>> I do check the backtrace on kaanapali: >>> >>> active_corner = 3 (MIN_SVS) >>> rpmhpd_aggregate_corner+0x168/0x1d0 >>> rpmhpd_set_performance_state+0x84/0xd0 >>> _genpd_set_performance_state+0x50/0x198 >>> genpd_set_performance_state.isra.0+0xbc/0xdc >>> genpd_dev_pm_set_performance_state+0x60/0xc4 >>> dev_pm_domain_set_performance_state+0x24/0x3c >>> _set_opp+0x370/0x584 >>> dev_pm_opp_set_rate+0x258/0x2b4 >>> dpu_runtime_suspend+0x50/0x11c [msm] >>> pm_generic_runtime_suspend+0x2c/0x44 >>> genpd_runtime_suspend+0xac/0x2d0 >>> __rpm_callback+0x48/0x19c >>> rpm_callback+0x74/0x80 >>> rpm_suspend+0x108/0x588 >>> rpm_idle+0xe8/0x190 >>> __pm_runtime_idle+0x50/0x94 >>> dpu_kms_hw_init+0x3a0/0x4a8 >>> >>> dev_pm_opp_set_rate(dev, 0); just low power to MIN_SVS. >>> And freq MDP: 650MHz >>> >>> >>> And I try change the order: >>> from: >>> dev_pm_opp_set_rate(dev, 0); >>> clk_bulk_disable_unprepare(dpu_kms->num_clocks, dpu_kms->clocks); >>> to: >>> clk_bulk_disable_unprepare(dpu_kms->num_clocks, dpu_kms->clocks); >>> dev_pm_opp_set_rate(dev, 0); >>> >>> But the issue is still here. >> >> But which clock is still demanding higher MMCX voltage? All DPU clocks >> should be turned off at this point. > Yes, no DPU clock demand higher MMCX voltage here. But next time pm_runtime_get_sync > need higher MMCX voltagei due to high freq. > >>> >>> >>>>> When the power is re-enabled, only the clock is enabled, leading to a >>>>> situation where the MMCX rail is at MIN_SVS but the core clock is at its >>>>> highest rate. In this state, the rail cannot sustain the clock rate, >>>>> which may cause instability or system crash. >>>>> >>>>> Fix this by setting the corresponding OPP corner during both power-on >>>>> and power-off sequences to ensure proper alignment of rail voltage and >>>>> clock frequency. >>>>> >>>>> Fixes: b0530eb11913 ("drm/msm/dpu: Use OPP API to set clk/perf state") >>>>> >>>>> Signed-off-by: Yuanjie Yang >>>> >>>> No empty lines between the tags. Also please cc stable. >>> >>> Sure, will fix. >>> >>>>> --- >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 16 ++++++++++++---- >>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 3 +++ >>>>> 2 files changed, 15 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c >>>>> index 0623f1dbed97..c31488335f2b 100644 >>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c >>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c >>>>> @@ -1306,9 +1306,14 @@ static int dpu_kms_init(struct drm_device *ddev) >>>>> struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms); >>>>> struct dev_pm_opp *opp; >>>>> int ret = 0; >>>>> - unsigned long max_freq = ULONG_MAX; >>>>> + dpu_kms->max_freq = ULONG_MAX; >>>>> + dpu_kms->min_freq = 0; >>>>> >>>>> - opp = dev_pm_opp_find_freq_floor(dev, &max_freq); >>>>> + opp = dev_pm_opp_find_freq_floor(dev, &dpu_kms->max_freq); >>>>> + if (!IS_ERR(opp)) >>>>> + dev_pm_opp_put(opp); >>>>> + >>>>> + opp = dev_pm_opp_find_freq_ceil(dev, &dpu_kms->min_freq); >>>>> if (!IS_ERR(opp)) >>>>> dev_pm_opp_put(opp); >>>>> >>>>> @@ -1461,8 +1466,8 @@ static int __maybe_unused dpu_runtime_suspend(struct device *dev) >>>>> struct msm_drm_private *priv = platform_get_drvdata(pdev); >>>>> struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms); >>>>> >>>>> - /* Drop the performance state vote */ >>>>> - dev_pm_opp_set_rate(dev, 0); >>>>> + /* adjust the performance state vote to low performance state */ >>>>> + dev_pm_opp_set_rate(dev, dpu_kms->min_freq); >>>> >>>> Here min_freq is the minumum working frequency, which will keep it >>>> ticking at a high frequency. I think we are supposed to turn it off >>>> (well, switch to XO). Would it be enough to swap these two lines >>>> instead? >>> >>> Yes, just clk_bulk_disable_unprepare(dpu_kms->num_clocks, dpu_kms->clocks) to >>> disable clk is OK. >>> we can drop change here. >>> >>>>> clk_bulk_disable_unprepare(dpu_kms->num_clocks, dpu_kms->clocks); >>>>> >>>>> for (i = 0; i < dpu_kms->num_paths; i++) >>>>> @@ -1481,6 +1486,9 @@ static int __maybe_unused dpu_runtime_resume(struct device *dev) >>>>> struct drm_device *ddev; >>>>> >>>>> ddev = dpu_kms->dev; >>>>> + /* adjust the performance state vote to high performance state */ >>>>> + if (dpu_kms->max_freq != ULONG_MAX) >>>>> + dev_pm_opp_set_rate(dev, dpu_kms->max_freq); >>>> >>>> This one should not be necessary, we should be setting the performance >>>> point while comitting the DRM state. >>> >>> No, issue is during dpu binding path. And in msm_drm_kms_init driver just >>> pm_runtime_resume_and_get enable power and pm_runtime_put_sync disable power. >>> But We do not set the appropriate OPP each time the power is enabled. >>> As a result, a situation may occur where the rail stays at MIN_SVS while the >>> MDP is running at a high frequency. >> >> Please move dev_pm_opp_set_rate() from dpu_kms_init() to dpu_kms_hw_init(). > > During dpu_kms_hw_init and msm_drm_kms_init and msm_drm_kms_post_init. > > There are multiple places where pm_runtime_get_sync(pm_runtime_resume_and_get)and pm_runtime_put_sync are called. > And each time after pm_runtime_get_sync(pm_runtime_resume_and_get) will access register depond on MDP clk. > > Do I need to add dev_pm_opp_set_rate after every pm_runtime_get_sync and pm_runtime_resume_and_get? So I took another look at this thread and I think the correct resolution here would be to stop calling dev_pm_opp_set_rate(dev, 0) altogether if the clock is getting disabled, since the PM APIs seem to take care of removing the vote during runtime suspend: diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index 61d7e65469b3..ddc6aeae8f55 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -1462,7 +1462,7 @@ static int __maybe_unused dpu_runtime_suspend(struct device *dev) struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms); /* Drop the performance state vote */ - dev_pm_opp_set_rate(dev, 0); + pr_err("!!!! SUSPENDING DPU\n"); clk_bulk_disable_unprepare(dpu_kms->num_clocks, dpu_kms->clocks); for (i = 0; i < dpu_kms->num_paths; i++) [root@sc8280xp-crd ~]# XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 xset dpms force off [ 163.099585] [drm:dpu_runtime_suspend:1465] !!!! SUSPENDING DPU [root@sc8280xp-crd ~]# grep ^ /sys/kernel/debug/pm_genpd/mmcx/* /sys/kernel/debug/pm_genpd/mmcx/active_time:159146 ms /sys/kernel/debug/pm_genpd/mmcx/current_state:off-0 /sys/kernel/debug/pm_genpd/mmcx/devices:ad00000.clock-controller /sys/kernel/debug/pm_genpd/mmcx/devices:af00000.clock-controller /sys/kernel/debug/pm_genpd/mmcx/devices:ae01000.display-controller /sys/kernel/debug/pm_genpd/mmcx/devices:aea0000.displayport-controller /sys/kernel/debug/pm_genpd/mmcx/devices:ae90000.displayport-controller /sys/kernel/debug/pm_genpd/mmcx/devices:ae98000.displayport-controller /sys/kernel/debug/pm_genpd/mmcx/idle_states:State Time(ms) Usage Rejected Above Below S2idle /sys/kernel/debug/pm_genpd/mmcx/idle_states:S0 67845 3 0 0 0 0 /sys/kernel/debug/pm_genpd/mmcx/idle_states_desc:State Latency(us) Residency(us) Name /sys/kernel/debug/pm_genpd/mmcx/idle_states_desc:S0 0 0 N/A /sys/kernel/debug/pm_genpd/mmcx/perf_state:0 /sys/kernel/debug/pm_genpd/mmcx/sub_domains:titan_top_gdsc /sys/kernel/debug/pm_genpd/mmcx/sub_domains:disp0_mdss_gdsc /sys/kernel/debug/pm_genpd/mmcx/sub_domains:disp0_mdss_int2_gdsc /sys/kernel/debug/pm_genpd/mmcx/total_idle_time:67846 ms (and the correct vote comes back up as the DPU resumes) At the same time, we *do* need to ensure the correct level is set *before* clk_prepare_enable and any set_rate operations (the latter is already done via dev_pm_opp_set_rate()) clk_prepare_enable() happens in: msm_mdss.c : msm_mdss_enable() dpu_kms.c : dpu_runtime_resume() (they refer to two disjoint sets of clocks but both cases need the fix) I think the easiest solution in the MDP case would be to set the clocks to the highest available OPP (lowest or *any* would work too, but going turbo seems like it's going to give us a stronger foundation for adopting cont_splash one day, avoiding potentially momentarily undervolting running hw) during probe and count on these votes being adjusted either through suspend (if unused) or to the actually needed frequency (via dpu_perf) For MDSS, we're currently generally describing the MDSS_AHB clock, the GCC_AHB clock and the MDP clock (sounds wrong?) - there's not even an OPP table.. The GCC clock is sourced from (and scaled by) the NoC, but the MDSS_AHB one seems to have 3 actually configurable performance points that neither we nor seemingly the downstream driver seem to really care about (i.e. both just treat it as on/off). If we need to scale it, we should add an OPP table, if we don't, we should at least add required-opps. The MDP4/MDP5 drivers are probably wrong too in this regard, but many targets supported by these may not even have OPP tables and are generally not super high priority for spending time on.. that can, I'd kick down the road unless someone really wants to step up Konrad