From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay03.th.seeweb.it (relay03.th.seeweb.it [5.144.164.164]) (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 AF927175A9C for ; Thu, 12 Mar 2026 23:33:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=5.144.164.164 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773358399; cv=none; b=fDbHHg7pj5+v3OL4KFo6XpheaZymasfKHOot+4aMf0/TNks+jFAKbh4jsBNA4/jl7L1/bw6g3v41olMo+g8F4vDEdqlh7ISX3VXHb2AZ2PVim2TzPKBIKpzLjHavQLpZEn/vtfoqoA4+c6o8WmBI1VvxHYve5S6kNI1LManHDFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773358399; c=relaxed/simple; bh=cNtkSwF4xuj8kUsbL9et7goSZBHkj/+juv2mOYwDesA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YwUYL+5eF3gLOiP/A6C+m79tHCEyLud2uDKW20oaRd753+RD+zEGy5dbqEHW2w2/wbUusbr9N3HFmY5sDmWsq62N/ghfM/AF5ufOOBr5kGIA51V7aWatGjEYeRdHGRRWJRkmAbrgbqsxp3YfhoKHN4kwdFDlCqtZdedDS2tAW8M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=somainline.org; spf=pass smtp.mailfrom=somainline.org; arc=none smtp.client-ip=5.144.164.164 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=somainline.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=somainline.org Received: from SoMainline.org (94-211-6-86.cable.dynamic.v4.ziggo.nl [94.211.6.86]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r1.th.seeweb.it (Postfix) with ESMTPSA id A9410208BD; Fri, 13 Mar 2026 00:08:16 +0100 (CET) Date: Fri, 13 Mar 2026 00:08:15 +0100 From: Marijn Suijten To: AngeloGioacchino Del Regno Cc: Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Jessica Zhang , Sean Paul , David Airlie , Simona Vetter , Pengyu Luo , ~postmarketos/upstreaming@lists.sr.ht, Konrad Dybcio , Martin Botka , Jami Kettunen , Dmitry Baryshkov , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/msm/dsi: Restore widebus calculation for CMDMode panels Message-ID: References: <20260311-dsi-dsc-regresses-again-v1-1-6a422141eeea@somainline.org> 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=us-ascii Content-Disposition: inline In-Reply-To: On 2026-03-12 14:18:43, AngeloGioacchino Del Regno wrote: ... > Marijn et al, > > I don't really know this hardware specifically, but I had a very fast look > at this patch, and I believe that however you put it, this looks like being > either plain wrong or very weird. I would say I also don't know the hardware here very well, and which parameters apply when and were. Most importantly, just be aware that the code we're looking at is for **DSC**, i.e. when we're no longer transfering single pixels per pclk, but compressed slices of a given number of bytes that can loosely be converted back to a "number of pixels". > I think this should be, instead.... > > /* (don't add this comment) assuming RGB888/666, this will be 24 for both Command > and Video modes */ > bits_per_pclk = mipi_dsi_pixel_format_to_bpp(msm_host->format); That would make sense, if it weren't for DSC. The older downstream kernel I'm looking at -for at least CMD mode- disregards the format entirely, and just divides the "width" (computed like msm_dsc_get_bytes_per_line()) by 3 or 6 depending on widebus. In other words that's clearly demonstrating that input/output "bits per component" (in uncompressed space) are irrelevant when we're transmitting compressed pixels. > /* Can send twice the bits per clock if WideBus with Video Mode */ > if (wide_bus_enabled && msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) > bits_per_pclk *= 2; And this is where the original patch got things wrong too; widebus isn't limited to VIDEO mode, in fact we were specifically only allowing CMD mode to use it thus far. That comment and condition should be inverted. In this old downstream, widebus also doesn't seem to affect the pclk rate for VIDEO mode, only the ratio between bits per component and the chroma format (making up the total size of the pixel) and the configured "bits per pixel" value are taken into account; that ratio is generally 3. > ...because, unless there's a hardware quirk (and that should be really clarified > with a big comment stating that), I don't see why command mode should always be > 24 bits per clock, and I also don't see why a widebus case would do 48 bits per > clock even in the RGB666_PACKED and RGB565 cases (which may not even be possible > but *meh*). > > Just my two cents. > > Reminding you all again that I don't know this HW, so I may have said something > wrong here. > > Cheers! > Angelo Kind regards, Marijn