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
