On Thu, 21 Mar 2024 at 19:36, Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx> wrote: > > > > On 3/21/2024 8:43 AM, Dmitry Baryshkov wrote: > > On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx> wrote: > >> > >> > >> > >> On 2/22/2024 3:43 AM, Dmitry Baryshkov wrote: > >>> The DPU driver provides support for 4:2:0 planar YCbCr plane formats. > >>> Extend it to also support 4:2:2 and 4:4:4 plat formats. > >>> > >> > >> I checked myself and also internally on this. On sm8250, the DPU planes > >> do not support YUV444 and YUV422 (and the corresponding YVU formats). > >> > >> May I know what was the reference to add these formats to DPU > >> considering that even downstream sources didn't add them? > >> > >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > >>> --- > >>> Full-screen (1080p@60) YV24 gave me underruns on SM8250 until I bumped > >>> the clock inefficiency factor from 105 to 117. I'm not sure that it is a > >>> correct way to handle it, so I'm sending this as an RFC. If we agree > >>> that bumping the .clk_inefficiency_factor is a correct way, I'll send > >>> v2, including catalog changes. > >>> > >>> I had no such issues for the YV16/YU16 formats. > >> > >> We don't support this too on sm8250. But interesting it worked. > > > > I have been cross-checking DPU formats list against the format list > > from the display overview docs. > > The DPU (and SDE FWIW) drivers supported NV16/61 and > > UYVY/YUY2/YVYU/VYUY formats for ages, although overview does not > > mention these semi-planar formats at all and interleaved YUV formats > > are marked as unsupported. > > > > For reference, NV24 and NV42 also seem to work. > > > > Thanks for the update. > > I cross-checked sm8250 format list in our internal docs to make sure > there is no discrepancy between those and the display overview doc. > > NV16 / NV61 (linear) are marked "NOT supported" by DPU. > > UYVY/YUY2/YVYU/VYUY (linear) are also marked "NOT supported". But all of these image formats are handled by the DPU _driver_ as supported. > So the markings are correct. > > If you notice a discrepancy between our dpu formats list in the driver > and what is marked as "supported" in the display overview docs, that is > something we can investigate and get fixed. > > If you are running some standalone tests and reporting that formats > marked as "unsupported" in the display overview docs still work, we > cannot simply add those formats on the basis of your modetest validation > as your validation alone shall not supersede the marking of the design > teams as the system level validation of those formats is what we have to > go by. > > The formats marked unsupported shall remain unsupported by the driver > and QC shall not ack adding any of those. -- With best wishes Dmitry
