From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F358D1093188 for ; Fri, 20 Mar 2026 08:17:47 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4A0E410EA8F; Fri, 20 Mar 2026 08:17:47 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; secure) header.d=pm.me header.i=@pm.me header.b="NTm0yq8E"; dkim-atps=neutral Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch [79.135.106.29]) by gabe.freedesktop.org (Postfix) with ESMTPS id DCEBC10EA8F for ; Fri, 20 Mar 2026 08:17:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1773994663; x=1774253863; bh=fM7dL1/cHCx+Ecxe9pDNzmAwYJLh6/HrEMptDcRGWZ0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=NTm0yq8EGUJ3OEgTtw6o49sQURoYcrrg1jSWltkQFjAKPx5l52jUW/NpROLBfaC14 EgwmgpsN4b2xzepLab7eOCJzXLZgiHT+10Ko7YxciXmQbmRqNzPmyGVuOr93tnfPMy 59bT/P3yXn5g0BFTxDssmpLjWwKXmgedv+xoh5A9QLZZ91rJo9kLcfqz8faOu0tMyP kajtEKit1Wkwq/zHH9VGtZfr/vJs0wrWlnRpo5NpzWi0V4+NIQm+LvW5M9ShcMCYYU eSldgWDIMdLkpveuOEcyBfEnoU8buoRBxfMNGf0pIy1+k8V+OmugfFOyi21ioaLTVy up7UM0+SAeBTQ== Date: Fri, 20 Mar 2026 08:17:39 +0000 To: Alexander Koskovich From: Alexander Koskovich Cc: Dmitry Baryshkov , Jonathan Marek , Neil Armstrong , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Jessica Zhang , Sean Paul , Marijn Suijten , Jeffrey Hugo , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org Subject: Re: [PATCH v3 4/4] drm/msm/dpu: fix video mode DSC INTF timing width calculation Message-ID: In-Reply-To: References: <20260319-dsi-rgb101010-support-v3-0-85b99df2d090@pm.me> <7fb9dd9d-13f9-7bba-93d1-08f42dd6ee38@marek.ca> <7o6ddv23aft3eerc7xz7r5rawe24d6vl3qp33ewnqllv5xkfrf@n3dosrwbvlhf> Feedback-ID: 37836894:user:proton X-Pm-Message-ID: b30bb89dbeef0ddcc77b2475bd87723c3906d17d MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Friday, March 20th, 2026 at 3:48 AM, Alexander Koskovich wrote: >=20 > On Friday, March 20th, 2026 at 3:36 AM, Dmitry Baryshkov wrote: >=20 > > On Fri, Mar 20, 2026 at 07:02:54AM +0000, Alexander Koskovich wrote: > > > On Friday, March 20th, 2026 at 2:50 AM, Alexander Koskovich wrote: > > > > > > > On Friday, March 20th, 2026 at 2:38 AM, Dmitry Baryshkov wrote: > > > > > > > > > On Fri, Mar 20, 2026 at 04:46:02AM +0000, Alexander Koskovich wro= te: > > > > > > On Friday, March 20th, 2026 at 12:25 AM, Jonathan Marek wrote: > > > > > > > > > > > > > On 3/19/26 9:45 PM, Dmitry Baryshkov wrote: > > > > > > > > On Thu, Mar 19, 2026 at 01:23:03PM -0400, Jonathan Marek wr= ote: > > > > > > > ... > > > > > > > >> > > > > > > > >> That's not how it works. INTF (which feeds DSI) is after D= SC compression. > > > > > > > >> > > > > > > > >> INTF timings are always in RGB888 (24-bit) units. Ignoring= widebus details, > > > > > > > >> the INTF timing should match what is programmed on the DSI= side (hdisplay, > > > > > > > >> which is calculated as bytes per line / 3). > > > > > > > >> > > > > > > > >> (fwiw, the current "timing->width =3D ..." calculation her= e blames to me, but > > > > > > > >> what I wrote originally was just "timing->width =3D timing= ->width / 3" with a > > > > > > > >> comment about being incomplete.) > > > > > > > >> > > > > > > > > Okay. After reading the docs (sorry, it took a while). > > > > > > > > > > > > > > > > - When widebus is not enabled, the transfer is always 24 bi= t of > > > > > > > > compressed data. Thus if it is not in play, pclk and tim= ing->width > > > > > > > > should be scaled by source_pixel_depth / compression_rat= io / 24. In > > > > > > > > case of the code it is 'drm_dsc_get_bpp_int(dsc) / 24'. > > > > > > > > > > > > > > > > For RGB101010 / 8bpp DSC this should result in the PCLK = being lowered > > > > > > > > by the factor of 3 (=3D 24 / (30 / 3.75)) > > > > > > > > > > > > > > > > - When widebus is in play (MDSS 6.x+, DSI 2.4+), the transf= er takes > > > > > > > > more than 24 bits. In this case the PCLK and timing->wid= th should be > > > > > > > > scaled exactly by the DSC compression ratio, which is > > > > > > > > 'drm_dsc_get_bpp_int(dsc) / (3 * dsc->bits_per_component= ). > > > > > > > > > > > > > > > > So, this piece of code needs to be adjusted to check for th= e widebus > > > > > > > > being enabled or not. > > > > > > > > > > > > > > > > > > > > > > The widebus adjustment on the MDP/INTF side is already in > > > > > > > dpu_hw_intf_setup_timing_engine: the "data width" is divided = by 2 for > > > > > > > 48-bit widebus instead of 24-bit. there shouldn't be any othe= r > > > > > > > adjustment (downstream doesn't have any other adjustment). > > > > > > > > > > > > > > a relevant downstream comment: "In DATABUS-WIDEN mode, MDP al= ways sends > > > > > > > out 48-bit compressed data per pclk and on average, DSI consu= mes an > > > > > > > amount of compressed data equivalent to the uncompressed pixe= l depth per > > > > > > > pclk." > > > > > > > > > > > > > > Based on that comment, this patch is correct, and the > > > > > > > ''drm_dsc_get_bpp_int(dsc) / (3 * dsc->bits_per_component)' a= djustment > > > > > > > only applies to DSI. > > > > > > > > > > > > If I keep the INTF side at /24 and change the DSI side to: > > > > > > > > > > > > if (wide_bus) > > > > > > new_hdisplay =3D DIV_ROUND_UP(mode->hdisplay * drm_dsc_= get_bpp_int(dsc), dsc->bits_per_component * 3); > > > > > > else > > > > > > new_hdisplay =3D DIV_ROUND_UP(mode->hdisplay * drm_dsc_= get_bpp_int(dsc), 24); > > > > > > > > > > Please check the actual fps (I'm usually using a vblank-synced GL= , e.g. > > > > > kmscube). > > > > > > > > > > At least this matches my expectations. > > > > > > > > Hmmm with kmscube I am getting 120FPS with 24 and 100FPS with 30. S= o I guess that's a no go > > > > > > Although it was using dsc->bits_per_component * 3 regardless before f= or > > > dsi_adjust_pclk_for_compression so I guess that's what Jonathan was > > > referring to earlier... > > > > Do you have any of the patches by Marijn or Pengyu? > > > > - https://lore.kernel.org/linux-arm-msm/20260311-dsi-dsc-regresses-agai= n-v1-1-6a422141eeea@somainline.org/ > > > > - https://lore.kernel.org/linux-arm-msm/20260307111250.105772-1-mitltla= tltl@gmail.com/ >=20 > Nope, I can test with them though if you'd like Tested the following 3 patches on top of this series: drm/msm/dsi: fix hdisplay calculation when programming dsi registers drm/msm/dsi: fix bits_per_pclk drm/msm/dsi: fix hdisplay calculation for CMD mode panel Getting constant FIFO errors with them applied: [ 64.851635] dsi_err_worker: status=3D4 [ 64.851692] dsi_err_worker: status=3D4 [ 64.851730] dsi_err_worker: status=3D4 [ 64.851766] dsi_err_worker: status=3D4 [ 64.851802] dsi_err_worker: status=3D4 [ 64.851837] dsi_err_worker: status=3D4 [ 64.851903] dsi_err_worker: status=3D4 [ 64.851940] dsi_err_worker: status=3D4 [ 64.851976] dsi_err_worker: status=3D4 [ 64.852011] dsi_err_worker: status=3D4 >=20 > > > > -- > > With best wishes > > Dmitry > > >=20 >