From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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 2F41C2E8B67 for ; Fri, 20 Mar 2026 04:25:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773980726; cv=none; b=tZGy/YbjboWiSXRb2jXxH09UYtnzVxES8ZhNIt9F42uf58/TczbVwdiKKD7beiYmBDNl4oWww3YZWo8FIoTDcimZ09C7eqUmjREjvbYoUq3Pa33R6qayObyFgjAJm5s4bY8z6uOSFuDwhSOx9Wf/qTlUShD7H8J6F06qpAK0C+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773980726; c=relaxed/simple; bh=6IbZCnAgMzbyfScoEQp8CPfeU2ha+EwH+CWvVv7ealw=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=Q7l9wuoSHttbl/Z/F2VvDAb2du0ncfVaaV/e5saksALsPKg6XhU+HqltauPVciq1n+CnCFNZOk+rn+XqexF1V0R2EEr2+C80caYxUQ1xq/J0L4LREY8tmOuhA5Yglcwr9IO7SUTW2419fGHJxPziYD7ZTASGKgZK4bFw3AeGVFg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=marek.ca; spf=pass smtp.mailfrom=marek.ca; dkim=pass (2048-bit key) header.d=marek.ca header.i=@marek.ca header.b=ZCdr9Eta; arc=none smtp.client-ip=209.85.160.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=marek.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=marek.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=marek.ca header.i=@marek.ca header.b="ZCdr9Eta" Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-509217e84a3so14188621cf.3 for ; Thu, 19 Mar 2026 21:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marek.ca; s=google; t=1773980724; x=1774585524; darn=vger.kernel.org; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject:from:to:cc :subject:date:message-id:reply-to; bh=CTWWaO+/XhoNRCAuJEz9H+WLHO2eUwKG5OIDlVViY4s=; b=ZCdr9EtamSWNboAJ18U7F4emlerQpM5zBgWRRoo+CHf11fAfS6qsGFJHwxrFK3pCRT tQXfrOIoOOllV1Sl+In39EF7Vc6QBAcZeh5i+HCdxXe/G9tD8kcYyrmbFjhsOSyQmqhQ mJdzV3dDpx/Egv85RWX2HgenXdIMhDHk0XjZ/D2FtiYAMRyhfqKFFEQ+fRSWjvAGxU24 OGpmCkJTC6WH2oQMeCwxNt/ow67EdhpiGJyM7WQG7w4qCFx5nk65Oy2GoG3ZNiCVQcAP vJlOXkUdLFWuVz2x4PrH5TpwrYQgubzLDPztgG8vVGzHNioqOdM0syWFUe4G54kciWEu ISLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773980724; x=1774585524; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CTWWaO+/XhoNRCAuJEz9H+WLHO2eUwKG5OIDlVViY4s=; b=aJyYEfQpXvxvLlktcKgffSbLpnDJ7f4S6SBGdHJNz+806VqfYSnwJsI9G4njafZCXN 2ULpg3E3a6mGOZfUwR+vz7JOUQIZSYLUsT9rNuE10bcDXBBX1GLzcTqKge/E1Q92dpfa 9zg6uMYjYCIAG188lLnTHoVwtuqLlByPW3igoxpLeNiuZWWXiR4vVObRwCVs50/Jy9cQ VdYBm95MVX3bJlBQzDOIOr7OgwLl8RPp7PaZfAyReTOTNDGHkDwCLZZ/ABuyAjHlXSoz OG+90pcqEY7l6xjPvyJfqdMEPVSZ4wT/nkI3T9qMSpiTQ969tkztfEJ3Mja/3L+an16K oa2w== X-Forwarded-Encrypted: i=1; AJvYcCVGU9WfvRadfqVwl/aMH37pTmBTQ1QteZ4t3evp3i8+TFh4fFapk3pYfOBkaBZJMPOeIjYl5uJO7PEt45Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yw4xsJ6P8FkCzeMgrJ7GwSXRCq1P36AOUjh36bulSDFzOgmfdDp CuAiEpqPAnW05w8fMlPCpV5zcB50NPpcHyRD6BZRSnI51YeS1uPWP15ScYx38n9KiBM= X-Gm-Gg: ATEYQzxXBS4rrUHkNaf6jJLI/jveDOEN55dkTmGZTB4EziNGAjfCoZrDTc2+qlaPuMM 2mkpmUAbYeXMDHpuYOn0VBAg7KS0C0DPn6toWC+lLiBdIfyyJA5dA2jt0nEqE/bq4JwzTEr52ni OJdILWVat/ELfgJpOGUbF9dep+g0BuPy0S3ijej9jNIGRTkDGCuTLgInEumicEscRsXHhf3ePsz cFRJF2VpfijntZtAp+lQEYnP0E7tJyd/+NPH1HzZlf0WP3VmiuPSjA1llTBeTmCtFuMOfUPMCht UT42XHG9vJFouRYT1ghb4kEBQNXhD2IGl8I9p97N23RFXBWFbkT2ZhZMCqHv0JeLQGH48eTGaX2 sEDQHiffDXQ+Q8Ffg79JSKfIrXWUlvECtg+On0rAyCMQYNnertQg2WoDkBEaA3UQYv9fpGC0BdS n+9iuJKqHFnUDSa2R3OkNgRs84TCNrJdLjTF8/svkrG2avDuO1EyUPvdFrF2x70yUsdspGGQ== X-Received: by 2002:a05:622a:1249:b0:509:1b76:e9b2 with SMTP id d75a77b69052e-50b37503075mr24487301cf.55.1773980724006; Thu, 19 Mar 2026 21:25:24 -0700 (PDT) Received: from [192.168.0.189] (modemcable125.110-19-135.mc.videotron.ca. [135.19.110.125]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89c85251e32sm12201056d6.16.2026.03.19.21.25.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Mar 2026 21:25:23 -0700 (PDT) Subject: Re: [PATCH v3 4/4] drm/msm/dpu: fix video mode DSC INTF timing width calculation To: Dmitry Baryshkov Cc: Neil Armstrong , Alexander Koskovich , 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 References: <20260319-dsi-rgb101010-support-v3-0-85b99df2d090@pm.me> <20260319-dsi-rgb101010-support-v3-4-85b99df2d090@pm.me> <1360a31d-669e-48df-a1be-f0af4a253cd7@linaro.org> <3gLK4s97giqqXagfHKhfiIHbfbl2snwfOj9dcTNGPUYi10w9-1EdATqzz1LPCVTpz4bLFYOm8u_Fl8PfC7t5yabows4UCzRKVwjraEWW6hc=@pm.me> <3f8763af-aad2-4d92-90c8-cfd290212503@linaro.org> <7fb9dd9d-13f9-7bba-93d1-08f42dd6ee38@marek.ca> From: Jonathan Marek Message-ID: Date: Fri, 20 Mar 2026 00:25:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 3/19/26 9:45 PM, Dmitry Baryshkov wrote: > On Thu, Mar 19, 2026 at 01:23:03PM -0400, Jonathan Marek wrote: ... >> >> That's not how it works. INTF (which feeds DSI) is after DSC 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 = ..." calculation here blames to me, but >> what I wrote originally was just "timing->width = 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 bit of > compressed data. Thus if it is not in play, pclk and timing->width > should be scaled by source_pixel_depth / compression_ratio / 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 (= 24 / (30 / 3.75)) > > - When widebus is in play (MDSS 6.x+, DSI 2.4+), the transfer takes > more than 24 bits. In this case the PCLK and timing->width 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 the 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 other adjustment (downstream doesn't have any other adjustment). a relevant downstream comment: "In DATABUS-WIDEN mode, MDP always sends out 48-bit compressed data per pclk and on average, DSI consumes an amount of compressed data equivalent to the uncompressed pixel depth per pclk." Based on that comment, this patch is correct, and the ''drm_dsc_get_bpp_int(dsc) / (3 * dsc->bits_per_component)' adjustment only applies to DSI. (note: newer downstream looks like it would divide by 3.75 here, which doesn't make sense. older downstream would divide by 3 here. I guess downstream is broken now and video mode + 10-bit dsc doesn't get tested?) on DSI side, "uncompressed pixel depth" shouldn't matter either: DSI only sees the compressed data. But based on that comment, when widebus is enabled, by setting DSI_VID_CFG0_DST_FORMAT(?) to 30bpp, then the DSI pclk is in 30-bit units instead of 24-bits. And with this series DSI side ends up with the right result if 30bpp format and widebus is enabled.