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 >> >> >>>> <[email protected]> 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 <[email protected]> >> >> >> >> [...] >> >> >> >> > 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 >> >> | >> >> | <mdss would only probe here> >> >> >> >> *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... Regards Luca > >> >> Btw IOMMU support is here missing as well, so no GPU support anymore >> since 6.17 if I'm not mistaken. >> >> > 1.2 - MSM8974 >> > I think it also had issues, no IOMMU support in upstream, etc. >> >> Plenty of 'issues' for sure ;) but apart from GPU driver having dropped >> no-IOMMU codepath they should be fairly fine, for what's currently >> upstream. >> >> I think also here, plenty of devices that do have panel support but not >> much upstream. It's kind of all the same though, nothing exciting. Panel >> driver with init sequence plus the same dts enablement bits.
