From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 76D5041DEE1 for ; Tue, 11 Aug 2026 21:24:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786483468; cv=none; b=sjgkktxtDFj9hPjukUNjE5YWe5aB8iIToGpROIx+mmDSp60bXai0kRk2O/+LTDdfqViuwz5vzZKlyfXzE3Rppl/AjbiYrIAlU2ALRolIVHq2noGtund2+q6lF2KZwZFFAUtnNmR7flzAsWiJrpUT5j9dQQgZA3ZSBe7cJk9TQxo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786483468; c=relaxed/simple; bh=zgq4LQHa38L9neAMMzR1rW1ARfXC2D0tkqZIN+DamzE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rxiyJR0dxmpiHkzKKP9zIDDHDwbTTPFHnhKqFTqSOj7ZmZoK0s/8jFdQEqkR1TZeiSSuvUL4sjdxDNpZJ3EXRzWvVrASQXFNj2oBWBJ26BDWYgOS0ojkCPsJgsjNk3+dhQ4KpoxEOJrSGEVcjDgGcsLlkPLez6WBVgJrAKMcb4Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=G1+cPERo; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="G1+cPERo" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-46f88060e8dso33837f8f.2 for ; Tue, 11 Aug 2026 14:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786483464; x=1787088264; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=WvCeOL9JP58AfB/MRzhZ0CTB3RYi+jJQ1QyJ9ty4SVE=; b=G1+cPERo8BwwfJtAThra+ruq6Jyb2d+ApPqw486H9RMmwRL+lReQtNDbaz/cjEQNgP f6bfD/CSs4scCmVEZYh5rOZzU+XC8iCEEQGnvElVdmoicKFyXMuSdnhZW2E3VfNuSVqG GzpsmpFDV/dDROa0jc6HMDARZTGriS4FumENCAqzjzgOlmyHf1sqLmYzpVUk/R0M6mMC P5fQbooiBikcW+hZ/XYwI8pt72k9Yz589WnE05BUEN0yG93T0V0ryHRakI+MS36ycpIJ f2Mv4WoYzlBtx+TAwV/qLdxdEjWQKEbvR0p0Le2+0jK3oLYBZADRAwjaIbFf4DB/ve89 eXIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786483464; x=1787088264; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=WvCeOL9JP58AfB/MRzhZ0CTB3RYi+jJQ1QyJ9ty4SVE=; b=swPp3xbULjpJVqX55WW7HQ1wwUZqQm7H3iEo7x9dh4e/tlLDpFDfFeCzVijziEfd/I Si0IZzFxkauzl0I1fP7FHrbYcKbCBQoPsMrZCAUJWaYn0VXrNflKCwsnnklV5jEMBIpd NQX/dmy+q2pCMmKmhj3LYTj89b99auTIsX3HNLlEP6pjl7koKYeEsMh9vH7SHy/j6HCT NM4SajAj2wzmqiqx/HRD8p9gOJCsIW4uS0VNK7nqBMpk+WAUU9pYg4L8FAAPRGxPSGwo n8bMEXqN2H69YwSXEIxvAwNEEU4SkkGe31l7pe+e1/tYriFxhfC4BUqRPNQUc81p0NIg GBcQ== X-Forwarded-Encrypted: i=1; AHgh+RpJIiwrCMvJFcfhhmQyCKD22yO6s8Tpqt3eDaHsXS/VDcrDqtPcD8+Y5O2vHz8zJPct/KOVKu2LCyGvx5g=@vger.kernel.org X-Gm-Message-State: AOJu0YyhhvrpaE4XQDz59iMhnIrY9slCIhiADM/0A/HRwNpVt6pI5zZL PebgvGF//2LzAybWJG5ngt9qAuXJrgx9/LqjHnCPYudI/Vy1KiTzHLUo X-Gm-Gg: AR+sD12WYaYkZmPrskHn4OljpRrHd9i/sI4JBBpJtvBd1v2SHa288pi+XrUsSrSjqX8 rSzcPxpPiQRqdo7yGTFXlUaC2Nkkg+yNaNu9J6HbKoKjLJgdEM8PzsLxSYgiv4DKHewYoqCU5Bj IUR3w0osdJXY3Mw6RVab8MMu97k8AfRf+zzLyxYZ2UhY+6hbPGqw+MclN9j09LWb5y1nFkVOfZR bCcHaR/Bs2UHzFFhMDND5+Y3OBWdKd1QOgnX5szJq1LXx8QscqtnpbY4knRGuAo7UhxegAw/LDU qSmwQHVDwTOzqN1y8yJhpnte/4seuMRjVW8Ui5Vho2HKuM7efBEGvZMsqJ3g9PRXH28qGKnRJmw svEkYhAp6NwEwxdkKlWU+aDrFUCCl6RxPef/kBmQQyUE7qbv98zNCkylvN1yEKpdTGk7w1renC3 +2200N35xU1C+v60ot5J4rEOa/i7X242zknjRtmFPZlcX/HfwUHKKy2eupG0SDZYtEsMPglVm/h KrG4Np/G9Zd4oDDmQMmxYS7jUiJNLWo1m4Jj8vRltPwSg+x+LDcn4bMglByvNVTKdtdzg== X-Received: by 2002:a05:600c:1f82:b0:496:bbce:ef with SMTP id 5b1f17b1804b1-4997c15bc31mr801435e9.3.1786483464434; Tue, 11 Aug 2026 14:24:24 -0700 (PDT) Received: from OrangePi5-Plus.BB-HOME (20014C4E1B94ED005B06BF1B5A09FFE4.dsl.pool.telekom.hu. [2001:4c4e:1b94:ed00:5b06:bf1b:5a09:ffe4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4997aac6e85sm20674225e9.14.2026.08.11.14.24.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 14:24:23 -0700 (PDT) From: Igor Paunovic To: Chaoyi Chen Cc: Igor Paunovic , Cristian Ciocaltea , Heiko Stuebner , Andy Yan , Sandy Huang , Sebastian Reichel , Alexey Charkov , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: drm/rockchip: vop2: ACLK_VOP pinned at 500 MHz starves DP 4K120 on RK3588 Date: Tue, 11 Aug 2026 23:23:50 +0200 Message-ID: <20260811212358.9980-1-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: <20260808104240.13776-1-royalnet026@gmail.com> <33bd4a94-11af-4cf3-ae44-b7f8944250f6@collabora.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Chaoyi, Cristian, Chaoyi, your reading fits my own measurements better than mine did. The link in that test was running YCbCr 4:2:0, so dclk sat at 594 MHz for a 3840x2160@120 mode - the interface rate was the cheap part. What was not cheap was what the video port had to compose: a single full-screen 3840x2160 ARGB plane at 120 Hz. So the case I reported is one where the interface was modest and the composition was not, which is the direction you are pointing in. I framed it as a DisplayPort problem because DisplayPort was the only thing I changed; that was the wrong axis. I should say what this bears on directly, because it is not hypothetical for me. I have a patch here that I have not sent, which replaces the frl_enabled condition with a threshold on the pixel clock: static bool vop2_needs_aclk_boost(struct drm_crtc_state *crtc_state) { return vcstate->frl_enabled || crtc_state->adjusted_mode.crtc_clock > VOP2_HIGH_BW_PIXCLK_KHZ; } with VOP2_HIGH_BW_PIXCLK_KHZ at 1000000, so that any video port needing the bandwidth can ask for the higher rate. It also guards the refcount on the way, since atomic_disable() runs for ports that were never enabled and the counter is unsigned. It is written against the rockchip-devel branch, on top of the commit Cristian mentions, and I was holding it back until I had a threshold I could defend. Your reply says the quantity I keyed it on is the wrong one, and I cannot argue against that from my own data. The measurement the threshold came from is that at 500 MHz a 2560x1440@144 mode stays clean while 3840x2160@120 does not. But in both cases the port was composing a single full-screen plane at the mode's own resolution, so mode and composition moved together and the comparison cannot separate them. If the rule belongs in terms of what the port composes, then the pixel clock is at best a proxy that happens to fit the two points I have. I would rather learn that before sending the patch than after. Two things I can run here: - your first case: hold 3840x2160@120 on DP, leave ACLK at 500 MHz, and scan out a 1080p plane instead of the full-screen one. If that comes up clean, the pixel clock is not the variable and the patch as written is keyed on the wrong thing. - your second case: a modest mode with several 4K ARGB planes composed at once. I can drive that over HDMI, without the USB-C adapter in the path, so it is a cleaner test than the first. Is there a form of the condition you would consider correct? What your description suggests to me is something derived from the composed pixel rate summed over a video port's enabled planes, with max() across the active ports rather than a refcount - but you know what the hardware actually stalls on, and I am inferring it from an interrupt counter. Cristian, understood on HDMI. If FRL and TMDS can serve the same mode at different fixed rates, the mode cannot determine the rate on its own and a bandwidth rule cannot be the whole story there. That answers what I asked. Whatever shape this ends up taking should keep working for the FRL case you already handle rather than replace it. One thing worth carrying across from the dw-dp v11 thread, since not everyone on this Cc list is on that one. Heiko reported that on his 4K display he gets no output at all at the stock rate, and some output after raising ACLK_VOP to 750 MHz, although that output is garbled: https://lore.kernel.org/all/20767137.geO5KgaWL5@diego/ So the starvation reproduces on hardware other than mine, which until now I could not tell apart from a fault in my adapter. The garbling at 750 MHz is not something I see here - the picture was correct the moment the write landed and stayed correct - so that looks like a separate problem, and I have replied to him on that thread rather than fold it into this one. Igor