From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 139FEC001B1
	for <linux-kernel@archiver.kernel.org>; Fri, 23 Jun 2023 07:19:45 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S230373AbjFWHTo (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 23 Jun 2023 03:19:44 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55070 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S229607AbjFWHTl (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 23 Jun 2023 03:19:41 -0400
Received: from relay06.th.seeweb.it (relay06.th.seeweb.it [5.144.164.167])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44E31C6;
        Fri, 23 Jun 2023 00:19:40 -0700 (PDT)
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 (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
        (No client certificate requested)
        by m-r2.th.seeweb.it (Postfix) with ESMTPSA id 6C97D3EBDD;
        Fri, 23 Jun 2023 09:19:38 +0200 (CEST)
Date:   Fri, 23 Jun 2023 09:19:35 +0200
From:   Marijn Suijten <marijn.suijten@somainline.org>
To:     Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc:     Jessica Zhang <quic_jesszhan@quicinc.com>,
        freedreno@lists.freedesktop.org, Sean Paul <sean@poorly.run>,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        Rob Clark <robdclark@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>, linux-arm-msm@vger.kernel.org,
        Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        David Airlie <airlied@gmail.com>
Subject: Re: [Freedreno] [PATCH 3/3] drm/msm/dsi: Enable DATABUS_WIDEN for
 DSI command mode
Message-ID: <xrqiat4otnfwtss6zwubh77qx3frdyi77flna2xljzycvr6r2v@riimvmhoondt>
References: <20230525-add-widebus-support-v1-0-c7069f2efca1@quicinc.com>
 <20230525-add-widebus-support-v1-3-c7069f2efca1@quicinc.com>
 <ky7sgsaohak2pcdf6pbhedfyrwk4ea7y3ekfqlw7rn6cpk4rhe@rjuhb23n37oz>
 <cf968ab4-e4c4-dcad-f7d1-4edff6f08147@quicinc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cf968ab4-e4c4-dcad-f7d1-4edff6f08147@quicinc.com>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2023-06-22 17:01:34, Abhinav Kumar wrote:
<snip>
> > More interesting would be a link to the Mesa MR upstreaming this
> > bitfield to dsi.xml [2] (which I have not found on my own yet).
> > 
> > [2]: https://gitlab.freedesktop.org/mesa/mesa/-/blame/main/src/freedreno/registers/dsi/dsi.xml
> > 
> 
> Thats because we havent submitted a MR yet for this on mesa.
> 
> Generally, our team does not have legal permissions yet for mesa MRs 
> other than mesa drm because we got permissions for the modetest.
> 
> Rob/Dmitry, can one of you pls help with the corresponding mesa MR for this?

Thanks!

> The xml file change was autogenerated so this patch can go in.
<snip>
> >>   		 *
> >>   		 * hdisplay will be divided by 3 here to account for the fact
> >>   		 * that DPU sends 3 bytes per pclk cycle to DSI.
> >> +		 *
> >> +		 * If widebus is supported, set DATABUS_WIDEN register and divide hdisplay by 6
> >> +		 * instead of 3
> > 
> > So this should allow us to divide pclk by 2, or have much lower latency?
> > Otherwise it'll tick enough times to transmit the data twice.
> > 
> > Note that I brought up the exact same concerns when you used the 3:1
> > ratio from dsi_bpp / dsc_bpp in your pclk reduction patch (instad of the
> > number of bits/bytes that DPU sends to DSI per pclk), but no-one has
> > replied to my inquiry yet.
> > 
> 
> Ideally yes, we could have done pclk/2 on uncompressed pixels but we are 
> not going to add support for widebus on DSI without DSC as that is not 
> recommended in our docs.

No-one here mentioned uncompressed pixels?

None of this code suddenly makes DPU send twice as many pixels/bytes to
the DSI, yet we are enabling a feature that makes the bus twice as wide,
so the clock can be halved *for comressed pixels*?

> So this cannot be done.
> 
> We tried our best to respond and explain to all your queries both on the 
> bug and the patch but i guess it just kept coming :)

Then send less patches!  As long as there is activity on the mailing
list there'll always be questions going back and forth, and I don't
think that's unreasonable.

Unless you want to push patches into mainline without questioning.

> I am going to try one more time to explain it in the documentation change.

Would love to hear, why, for compressed streams, the bus is twice as
wide yet pclk is not reduced to account for that.

<snip>
> > Can we also support widebus for uncompressed streams (sending 2 pixels
> > of bpp=24 per pclk), and if so, is that something you want to add in the
> > future (a comment would be nice)?
> 
> No, we cannot support widebus on uncompressed streams on DSI so we wont 
> be adding that.

And here we start talking about uncompressed pixels *separately*.  Okay,
if it is not supported (e.g. widebus is specific to / reserved for DSC)
it of course makes no sense to add it.

- Marijn