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 0535739DBD9 for ; Tue, 17 Mar 2026 08:59:34 +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=1773737976; cv=none; b=KNX3xV7EZaFd3VhGAUEl1rgPlgSj6rznH3Uap0WToU/dynVLi4/gGtoWBwTp9UVbTvZ5vT6QNsUKGOF0eSfkNkBWtVi3rLZK97YBuh5K/D7JTUl3yLdTzudj8CZnSZmG2C8vue+YGDvFlVJ1Lu+nYuwnzLres6h07B4xXttKnwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773737976; c=relaxed/simple; bh=ZBC+wqfliCLFxtVPk22pe94MKkyCgfafymBGIxNpE3g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mK12Wi78MspvCHomF3QLgEf+EvDWjdwzPvZs50kPCLCdXW8/K9JvLrWy0e1Tp1dzlgkRH+CZsPdCpeOdghRTkOeLITtt26IqvgipC3ITSCsckG7caDenGutv2XkUqb81xybP3MQ71yD0wWJ81oNl1x0+z7qihHmB77u32r9ey+I= 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=BXzqdKsE; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=C5ahRIyc; 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="BXzqdKsE"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="C5ahRIyc" Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62H7TwxU2375024 for ; Tue, 17 Mar 2026 08:59:34 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= acx+HIKHCDqHg+j5iC+RJDEjPmw3fE5jWyOI6vQQqxQ=; b=BXzqdKsELrcqYKSw vPAPICHUX1gaB6p82PNKn1trHYYMTTipWxxUJ6z/ub/wgbtF3543JID+S1kfXBWO XsF2+IlJtbz9+iLRHLmMydm07q+5+k+jRQ1mBkT8LMxj9WCWZU0t3WV5NzzXkLgF 54Nka4iorxlNqPIw2mG0djcmUC0xxxd6hhBOOy6wE/RyWnmtXSbrY3/++vE2QoTI KBUb0Z7pVFTSslu0jVCss5yG2r+s+/aOE5avOtNkyuJnyNF6p3Xs2P2k9s1vWbHo +HKdI924+ovcuzWJ7lhBrmrOYMPKjcS7pEMNglR1KTRtfPoJ7EH0HaWCql9OmV82 4fjyhA== 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 4cxkby3f1x-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 17 Mar 2026 08:59:34 +0000 (GMT) Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-899fcb63705so31252776d6.1 for ; Tue, 17 Mar 2026 01:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773737973; x=1774342773; 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=acx+HIKHCDqHg+j5iC+RJDEjPmw3fE5jWyOI6vQQqxQ=; b=C5ahRIycdeaeXHk8Js2kOtDg1tARxywfjJoHQ5XeFmF36cR6YF/qOsXVyxqzyGjlu5 7kue/Kfn0zBvEaQBSdz4EeWtAfdwbU07aP859ZpcuF/hZTE4LMGozJ4cetBHIoY/rg+0 nyYGUvKLDkjd5n5zZyuVzeexlRhyMiPf7xHLyctotWyntCF8+howckd45nOqT7N6P7IS TdReQylz+e/n30hutz8UUsgYLMFDRmsp275o4lqYc405jq14x500P0D4Z+KhJcXtYe9D 4PHlPOLve5S/lpVBwjhJnysEUMZHmyje33OvirZWFPVMFTizne+FtCeA3ZtSRh8RWOWr f6cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773737973; x=1774342773; 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=acx+HIKHCDqHg+j5iC+RJDEjPmw3fE5jWyOI6vQQqxQ=; b=r2rUI/mB11hRTvHaOjLuikpiNqPTtftnTgomNIKU1+EUJcDUzgTIGI8ToXzqlC3SGG IN4sHRqxCBD+DhvagAp/grENTIZtLfrl1mpHPZlRNQvbDUI6FshPDbBRGYHvlmfvN13S GHAJcbUSRe/qJhfBYfMo5IChwKQeKRF2sNJcdnMDjqPnTb85770WJSkCMWRewSWzgzfU R+MznrqyWoNHRHnDCTN+p5CHaz0W+hRqrfdAIwcphKvZrEgmNIyg6/2J5gUUv54PoGRN ZF2yt2knTX0W361TdTcgWsC2CSPg9oYVPlvbIqrf2v23SLpP06PaP1wgcS2oiovaf3ZW 5y8w== X-Forwarded-Encrypted: i=1; AJvYcCVi+D2qg55NXhMzt9dTthI/RQZ5f9jjhAm38+/8GTfQ2p3G/gsZtJ+B2Bt4cbLHk3ldtGOEUg/l2fde/r8=@vger.kernel.org X-Gm-Message-State: AOJu0Ywk82FRCQZvDtfDiZ+OwqMPdLbzIEIaHNaZnLeceA9LKwMgUOt1 93UMLuDCAduDrbRfKuJ1Xb1yt8fY29NOkHFfN6Aoe/gwQIgOUbAsfSEsSkB98bfLfw0GJqaNIEc RJmvvTaEMw+ftz4kLKZiK5XDgTNzaZoShKIpMT1quGZuGuhTBGmXnFJgqP6qBtHj8OhE= X-Gm-Gg: ATEYQzz+7QV3/tug3Bvm01tfxaW7iUEZFcb5MV9hGU6w+1+oGKHk6712nWVj+BJyty5 hOZAs/mAuhCsPbbz5qrqU0goVTlf64KSKwOo/i1IWgzgBXBBBspwYROIRjwbRIEmqBbfB08jwCt jeR0dRY95kmH4xML1ZkkttuzLQKuK2iMFgDOApmEfNdaIRUYZLawzE54ffkLx5tdfAbbrgl30pq Mpy59E7fMptEVhTtqqA19ZVtNSss02y53hCbGIyjgRBbrEYBO+BKgWC4fPp2mG5yQf95UCc8inM RiUnAZkyg+9+r6wupADyYarDWHDUbd9xtlSyXED/m45qjmTIcDSFh/6/qpQ3fNvOkFe5b5Csbqm QtjV60nPvUiha+4PisI3vY0CC7THf6jebI+WIda99eOOsPgz7b4WLg/RPg76COgHHh/b1KdSkUD 4AtPA= X-Received: by 2002:a05:6214:6014:b0:89c:58fd:41 with SMTP id 6a1803df08f44-89c58fd062bmr41988686d6.8.1773737973053; Tue, 17 Mar 2026 01:59:33 -0700 (PDT) X-Received: by 2002:a05:6214:6014:b0:89c:58fd:41 with SMTP id 6a1803df08f44-89c58fd062bmr41988346d6.8.1773737972562; Tue, 17 Mar 2026 01:59:32 -0700 (PDT) Received: from [192.168.119.254] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b976cba6eacsm720678066b.14.2026.03.17.01.59.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2026 01:59:31 -0700 (PDT) Message-ID: <3e5f80a6-d9bc-46ee-89ca-b1b2ba744493@oss.qualcomm.com> Date: Tue, 17 Mar 2026 09:59:28 +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: Luca Weiss , 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 References: <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: 8bit X-Proofpoint-GUID: O-EATUDRDTBL1-1Z6GFlHKYBGQJCamrB X-Proofpoint-ORIG-GUID: O-EATUDRDTBL1-1Z6GFlHKYBGQJCamrB X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzE3MDA3OCBTYWx0ZWRfX4bEQLeoREy9k ee5Y8J0Z4XrsqrW+QBO5Jtkno3oEQZ5X+ivf05VLwER71YcMmcJre1OgxXUITgVf788P22cVlEX WEzWQmUaI7HnTc92I1nSgznzVUYXp3V56aeGfdSDMRgdfTjNhYCjGCVi4TdfcWwejJ8umBBZtxT 3mXF2OjVDiJiGzAZd1XF4U3HP5UYr52MAj0MDf+BKPpNbnpqIpLcOVFRBNvlWZQ3ZlyyzB66Zx3 l9mY4O/hvsA5UFKmMc+goP616s8gEe40G+Utmtcdje8asJbrqfrXofNTDlNXsSP0rvcH9Yxhc2X zL4Q9WnKOxkEPxjhd8KyomNtCfOCFEu3cHa/q+oAhTko+uTBxML4NFtESKi/KR2x3yCsFbvgNQN qeYjosWD25gHEbiZto4wQLo/rg6q0oEkmyJR3gHMQQ0BpDM2/F2Pp/moUrCEB8bh10qwBeTc8+F 3x1jh17KiVqjI59+Chw== X-Authority-Analysis: v=2.4 cv=ZpLg6t7G c=1 sm=1 tr=0 ts=69b917f6 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=Um2Pa8k9VHT-vaBCBUpS:22 a=EUspDBNiAAAA:8 a=m4NBtHgnOE4RoSRSD-cA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=iYH6xdkBrDN1Jqds4HTS:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-17_01,2026-03-16_06,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 impostorscore=0 adultscore=0 phishscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603170078 On 3/17/26 9:07 AM, Luca Weiss wrote: > On Mon Mar 2, 2026 at 4:17 PM CET, Dmitry Baryshkov wrote: >> On Mon, Mar 02, 2026 at 03:35:36PM +0100, Luca Weiss wrote: >>> On Fri Feb 27, 2026 at 8:05 PM CET, 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. >>>> >>>>> >>>>>>> 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 >>>>>> >>>>>> I'd really not bother with those two drivers, unless we start seing >>>>>> crashes. For MDP4 platforms we don't implement power domains at all, no >>>>>> interconnects, etc., which means that the system will never go to a >>>>>> lower power state. >>>>> >>>>> Right. Might be that 2030-something arrives and armv7 is gone before someone >>>>> randomly decides to work on that! >>>>> >>>>>> MDP5 platforms mostly don't have OPP tables. (I'm not counting MSM8998 / >>>>>> SDM630 / SDM660 here). MSM8917 / MSM8937 have only DSI tables, MSM8976 >>>>>> has both MDP and DSI tables (my favourite MSM8996 has none). Probably we >>>>>> should start there by adding missing bits adding corresponding >>>>>> dev_pm_set_rate() calls as required (as demostrated by the DPU driver). >>>>> >>>>> A bit off-topic, but: >>>>> >>>>> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c >>>>> >>>>> 96 is in DPU. any other candidates that should be moved over? >>>> >>>> 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 >>>> 1.1 - MSM8x26 >>>> Probably Luca can better comment on it. Should be doable, but I >>>> don't see upstream devices using display on it. >>> >>> I have at least two MSM8x26 (1x APQ8026 lg-lenok & 1x MSM8926 htc-memul) >>> devices working with MDP5 fine. I should've probably upstreamed panel >>> driver & dts but they haven't been high priority.. >> >> I think I have been saying this: having a panel & dsi enabled in DT is >> the only way for me to know that the display is working on this >> platform. I'd really kindly ask you and other activists to get at least >> some panel drivers and corresponding DT bits upstream. It is really an >> important flag for me. >> >> I can propose some kind of bounty for those getting MDSS+panel supported >> in Qcom DT. (Beer at the next conf we meet? Some stickers for the >> laptops and phones? Mämmi?) > > Hm I realized yesterday (through trying it), that also MDSS is broken > since the no-IOMMU codepath was removed from drm/msm. I thought this was > only affecting GPU but it's also affecting MDSS/MDP5 :( > > So I guess no panel enablement anytime soon until the IOMMU situation is > sorted out, for both 8226 and 8974... If you're sure the panel drivers are good (e.g. they worked on 6.whatever prior to drm/msm saying sayonara to carveout), I think no one would object to have them merged separately, so that you don't have to wait until who-knows-when and keep rebasing them by hand Konrad