From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEE39318ED2 for ; Mon, 2 Mar 2026 10:42:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772448127; cv=none; b=j5fyjmtIIh2pTz20Em3rnsejruuVTYgPKT0/cqC2v5X6BW2Umvcqy+FeZoajeax/nm8fuVRspgfa5WkiFXqbzEee+5ziJyv50PQw+9BUFs3tTundi28eE8akcNU8f72+ntsZmgqUq1+SRN+38XD6m9U5vm5cGMJd89/5R96gMG0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772448127; c=relaxed/simple; bh=bAe+izALw3+MTGbxw3vlzb4sKdgAftZ47r+NVh/UcNI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=N6SS37194mbsBWKI5172zcq2HL2AU2FoGhSiI2/AhjLCHiJWXUxPhCRpHiQkJuoC8CWhCKGK1icvLr+C1by9BYI3B0Y/thR8kDOkG+VeV4ZHPOESiabSQ9qmmugdZ0NWBrhXmW4SVA/6TejziTIy+Fw6Ugz4J7wE04irTDiTkYw= 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=gehtB3FB; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=fteU8HJc; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="gehtB3FB"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="fteU8HJc" Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62285Xvo662204 for ; Mon, 2 Mar 2026 10:42:05 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= H5oh1Y3E4ZRYRy45drg9tJ/H8Kljy9D160tvJTu3A5M=; b=gehtB3FB48mBjiiP qB2zbLDdWTGKmktVVGRoTWZHgUXMqyQN5EQC3AMsWy4m2hkA1ZDvTwlYxdP00SGL bilemr6YV5YirSHDQaKyy2toFpuH8xGNpsLgEeJVrzBpd4FKRrFlQldVzdsbOog8 /upllLXqicWm4m1pOYzh1bZDAnsoBxvNwFi9HI4wIgV6zJ3iVzcun0H8hR2zt7zE XNj5tOXBomSDcTDNuiUtRXb3vdW3UnEgEdfwWWMu0Dnnl8z1XWGhvYO2vIiquDRF Hih/1iFRjTlDOXnuZob8c1QDQWrgHW9r0RxuThue/Kn4HE8Jzgb7LqIAXMA2XFHv 3E+hXA== Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cn6r2rmt2-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 02 Mar 2026 10:42:04 +0000 (GMT) Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-89a04e9d4faso267676d6.1 for ; Mon, 02 Mar 2026 02:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772448124; x=1773052924; 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=H5oh1Y3E4ZRYRy45drg9tJ/H8Kljy9D160tvJTu3A5M=; b=fteU8HJcBn4mBzd5fCqmALYBcLYg0xTAlSdR4WP8Jib/5MkgQLz612DXR0MpcydCqj TReNrvZh4b1Jetgii1lOn24V8QCj8w0rImIuIQoaTAexnCitX/9sZSHrfNMTgc66l/LC AMqu7pl23Y5bGrCHYlri9D1vijFyUpWia1JNBzerqZN3HrlLCwDpqYHNBE9ZtOVuRhwe ulcioLa9zwMCbA2ikkE/zh4PuA5uTnrLSyJnkjVb5qVd18dE1KWNT4Vkg6nhEnrebLcx cTibtzYLQTqffvAhdNYM+4oljArLNSv4wqcESljkUqtLQHdGLSGYjM2RvI3Kw4gtOP5x 8mkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772448124; x=1773052924; 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=H5oh1Y3E4ZRYRy45drg9tJ/H8Kljy9D160tvJTu3A5M=; b=hqdzFPnez4TQhQYlz5wgvMZCws77PhFnLWvkMV2dP10kj8OPybotOd/GT9LX62QbOi cbxo/O3xJZGmcmvEv6MmyyYOLPe2iWL5xv/3xrBGKLCsuYSLH/p9A6l3oNyCqTcbm28z Uvvo5T1iA+5iglfYa2YxeEGyC4LQOhiE3mObw7c0dxOgaFiWmfEHhYRHgyTgwYSeA2sQ b+QKRQlJ/fcWt7BLluDRipIAWKTkt9aU/qnw0An40EufEv1ktsL1hX5ALo6wNCu8r1vk 3IvAkK7PlKamMZN4Kb/wVKwocOArYD50LOERc2At/yx9Yr3FBJv1FHgTcJPfUuzFwdCu OrLg== X-Forwarded-Encrypted: i=1; AJvYcCXmIvK1q4eRwJAekmAAsrTJ1HXXFqjupXybs2uvO6fbHLo1g70qKLGCFm60gxIYP9XLhotAkcB16JIPodw=@vger.kernel.org X-Gm-Message-State: AOJu0YyEb/fnrdNRjuoYiYQABAqGmnLouE84ZtiRP2vNng+3ihrJWQNS 18SeDHegTcQdwjj6smUoUMScihMvGT9gzO9+kZ0nsPIV5R7q0Y9FBIL18k2QfDTFIclLtTQbmGt sqIBZlIsYNm6F6nRL73EkGLcnFW7W7+t7ZEoycz6LTmXo6Kk56P0qSfSIQ7vlGhvH9BU= X-Gm-Gg: ATEYQzzOLaoEu9OCN34VHtQnT7uXAZqUC4Q70akhgz/y09kJOObXaLpKOso5w5e9jGv uCckRwxast8cSQ/NhMIYYNZn67ImE4NQYL7/BHdvC86gPkysCSTPfbIK037NvejsVYgtCp7c6Pu OxusZimpuoqu0c33CSI9BtewETUPeTsakUvojEFHXK0AKaUF7R6D5atflitbrvWR0z1Wtfd9gJj SG1rErAduFYUDJ6hwUPjleY2MsaTPtV+T9xcS8+FUv+aGULDhUV1TigU6VoBkiFZ63VxWN5JeWc fNCqPq1bIA+Hre39BCSTMGXe8zIWUCTtfBM0Zls7NQNWyvATZWnRLqcv5yse7QsGN2NFa0DxELQ WIlyGd9S6kAbBOwt1LjsDEpx9Gk9vdrs+kwLQWaibpLWeMAPnuZ1vdIOnI2wJza9G15rMaxKy9G 8AuiY= X-Received: by 2002:a05:6214:4705:b0:899:bff4:af84 with SMTP id 6a1803df08f44-899d1ebc53cmr112436266d6.7.1772448123939; Mon, 02 Mar 2026 02:42:03 -0800 (PST) X-Received: by 2002:a05:6214:4705:b0:899:bff4:af84 with SMTP id 6a1803df08f44-899d1ebc53cmr112435966d6.7.1772448123479; Mon, 02 Mar 2026 02:42:03 -0800 (PST) Received: from [192.168.119.254] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b935ae60c16sm455580666b.38.2026.03.02.02.42.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 02:42:02 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 11:41:59 +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: Dmitry Baryshkov Cc: yuanjiey , 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, "marijn.suijten@somainline.org" References: <20260109083808.1047-1-yuanjie.yang@oss.qualcomm.com> <20260109083808.1047-2-yuanjie.yang@oss.qualcomm.com> <4g6fyehdc3fejx3pzeysmghigazfei3jz2vmnvxrnqkkbtbxdb@bdlcddxlvbhl> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: 7V4pp-dgFzzjFFCshWdFKCnh6b89nDEL X-Proofpoint-ORIG-GUID: 7V4pp-dgFzzjFFCshWdFKCnh6b89nDEL X-Authority-Analysis: v=2.4 cv=Hpp72kTS c=1 sm=1 tr=0 ts=69a5697c cx=c_pps a=oc9J++0uMp73DTRD5QyR2A==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=DJpcGTmdVt4CTyJn9g5Z:22 a=EUspDBNiAAAA:8 a=GNz5de_MuxAREYx-QrcA:9 a=QEXdDO2ut3YA:10 a=iYH6xdkBrDN1Jqds4HTS:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAyMDA4NyBTYWx0ZWRfX5Qvp+ucXS3jW Qm38Z9haQrlb4q93aaFAoOWGsUn/NmMqrnHtMpX+8goZWNtR9E4WLnQltuF2uyUckgjZbM6tMcH gCIgjpVN2slQrrOYJkVWxXFa19po+0ToJL+i+lf9fRgjBp2sGX3k1puT6W+RaDsUyAg4MhydY33 3hn/lBUSV67a0pS2BeSh5k//NPCrqQcowhQ5xP50C6riuq6xjPcw2228IzuYWIxSgBaoVXi1WYm sbYpfKjLP1uyQhn+sMl3p4ZkM3mIEe+hWwae67FzQItn63IJVSc8zEjDzVpWzaLSEE79iGqg99q Bopx+AN3E3JGOSZJ3Ir4t4kXwwDilr4wW7sooRlBpJdJnYCf+3R+EbD0B12f7KTj6NFgVMRClq/ dPf89M6UU1seREYEKV0/IWBowujnMLz/v+hnapEehHIchxYFlze7PqMpaC6NQHiFH8U5ubG9FDI EA8nA5jHeuCXraxYNmA== 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-03-02_02,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 phishscore=0 priorityscore=1501 adultscore=0 bulkscore=0 malwarescore=0 clxscore=1015 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603020087 On 2/27/26 8:05 PM, Dmitry Baryshkov wrote: > On Fri, Feb 27, 2026 at 12:34:04PM +0100, Konrad Dybcio wrote: >> On 2/27/26 4:48 AM, Dmitry Baryshkov wrote: >>> On Thu, Feb 26, 2026 at 02:35:52PM +0100, Konrad Dybcio wrote: >>>> 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 >> >> [...] >> >>> Please correct me if I'm wrong, if we drop dev_pm_opp_set() from >>> dpu_runtime_suspend, then we should be able to also skip setting OPP >>> corner in dpu_runtime_resume(), because the previously set corner should >>> be viable until drm/msm driver commits new state / new modes. >> >> That matches my understanding. >> >>> The only important issue is to set the corner before starting up the >>> DPU, where we already have code to set MDP_CLK to the max frequency. >>> >>> Which means, we only need to drop the dev_pm_set_rate call from the >>> dpu_runtime_suspend(). >> >> I concur. >> >>>> 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 >>> >>> No. As far as I remember, MDP_CLK is necessary to access MDSS registers >>> (see commit d2570ee67a47 ("drm/msm/mdss: generate MDSS data for MDP5 >>> platforms")), I don't remember if accessing HW_REV without MDP_CLK >>> resulted in a zero reads or in a crash. At the same time it needs to be >>> enabled to any rate, which means that for most of the operations >>> msm_mdss.c can rely on DPU keeping the clock up and running. >>> >>>> 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. >>> >>> I think, dispcc already has a minimal vote on the MMCX, which fulfill >>> these needs. >> >> I have slightly mixed feelings, but I suppose that as we accepted Commit >> e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain"), >> we can generally agree that it makes sense that calling genpd->on() actually >> turns on the power indeed >> >> What I'm worried about is if the clock is pre-configured to run at a high >> frequency from the bootloader (prepare_enable only sets the EN bit in the RCG, >> and doesn't impact the state of M/N/D at a glance), we may get a brownout >> >> This rings the "downstream really did it better with putting clock dvfs states >> into the clk driver" bell, but I suppose the way to fight this would be to >> simply set_rate(fmax) there too.. >> >> I attempted an experiment with pulling out the plug. MMCX enabled with the >> AHB clock off results in a read-as-zero. I tried really hard to disable the >> mdp clock, but it seems like the "shared_ops" reflect some sort of "you >> *really* can't just disable it" type behavior (verified with debugcc) > > I think, in 8996 it was possible to disable it. Not sure about > 8998/630/660. > >> >> >> There's a possible race condition if we don't do it: >> >> ------- bootloader -------- >> configure display, mdp_clk=turbo >> ------- linux ------------- >> load rpmhpd | >> load venus | >> set mmcx=lowsvs | mdp_clk is @ turbo >> | brownout >> | >> | >> >> *but* that should be made impossible because of .sync_state(). > > Yep, sync_state should prevent MMCX or CX from dropping under the boot > level. > >> >> This may impact hacky setups like simplefb, but as the name implies, >> that's hacky. >> >> Relying on .sync_state() however will not cover the case if the mdss >> module is removed and re-inserted later, possibly with mmcx disabled >> entirely but the clock not parked at a sufficiently low rate. >> >> >> TLDR: reassess whether MDSS needs the MDP clock, if so, we should just >> plug the MDP opp table into it and set_rate(fmax) during mdss init > > And what will drop it afterwards? MDSS will still vote on the MMCX / CX > level even though DPU will change the clock freq. That's a good point. Perhaps the easiest resolution will be to leave a comment before the prepare_enable() explaining that this should have a vote, but it's easier to rely on the providers' .sync_state() keeping them online until the consumers fully probe. [...] > Let's go through them. > > All SoC except those currently supported in DPU require SMP (shared > memory pool) support to be ported from the MDP5 driver. > > Most of the remaining platforms (except MSM8994/92) also had HW cursor > implemented in a fancy way, in the LM rather than in a separate pipe. > I'd really like to postpone those, possibly first completing migration > of the other platforms and dropping support for them from MDP5. > > 1.0 - old MSM8974 > I'd rather not touch it, it had bugs and I don't have HW I have reasons to believe msm8974 v1.0 never reached store shelves. Let's remove this. > 1.1 - MSM8x26 > Probably Luca can better comment on it. Should be doable, but I > don't see upstream devices using display on it. Because there's no iommu support for these > 1.2 - MSM8974 > I think it also had issues, no IOMMU support in upstream, etc. > 1.3 - APQ8084 > Had hw issues, no testing base, no MDSS in upstream DT > 1.6 - MSM8916 / MSM8939 > Can be done, low-hanging fruit for testing > 1.7 - MSM8996 > Supported in DPU > 1.8 - MSM8936 > No upsteram testing base 8936 is 39 with some CPUs fused off (unless you have info suggesting otherwise) > 1.9 - MSM8994 > No upstream testing base, no MDSS in upstream DT, normal CURSOR planes > 1.10 - MSM8992 > Even less testing base, no MDSS in upstream DT, normal CURSOR planes > 1.11 - MSM8956 / 76 > No complete display configurations upstream +Marijn, is your computer museum still running? > 1.14 - MSM8937 > Supported in DPU > 1.15 - MSM8917 > Supported in DPU > 1.16 - MSM8953 > Supported in DPU > 1.17 - QCS405 > Zero testing base, no MDSS in upstream DT No upstream MDP5 support either. And it doesn't seem like that SoC had much uses that didn't end up with the thing glued shut.. > MSM8994/92 would have been an ideal testbeds for SMP testing, but... > they mostly don't exist (please correct me if I'm wrong). Which means > that the next viable targets are MSM8916, MSM8x26 and MSM8956/76. All of > them require SMP support and don't make sense without cursor handling. We can think about poking at some of these it one day, but certainly not high prio.. Konrad