[PATCH] drm/msm/dpu: add support for 4:2:2 and 4:4:4 planar YCbCr plane formats

[Dmitry Baryshkov]

On Thu, 21 Mar 2024 at 20:28, Abhinav Kumar <quic_abhinavk at quicinc.com> wrote:
>
>
>
> On 3/21/2024 11:09 AM, Dmitry Baryshkov wrote:
> > On Thu, 21 Mar 2024 at 19:36, Abhinav Kumar <quic_abhinavk at quicinc.com> wrote:
> >>
> >>
> >>
> >> On 3/21/2024 8:43 AM, Dmitry Baryshkov wrote:
> >>> On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar <quic_abhinavk at quicinc.com> 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 at linaro.org>
> >>>>> ---
> >>>>> Full-screen (1080p at 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.
> >
>
> Ok, I see where this discrepancy is happening now.
>
> So I took another chipset, sc8280xp and checked these formats.
>
> Those are marked "supported" in that.
>
> Our dpu_formats listed in the driver is not chipset specific and that is
> causing this discrepancy between the display overview docs and what is
> in the driver.
>
> I will plan to move the formats list to the catalog to eliminate this
> and prioritize that change.

Well, from my side, disabling of interleaved YUV formats is going to
be NAKed. They are heavily used by video players for output. So,
disabling them will harm user experience.

>
> Till then, I think we should stick to the display overview doc in terms
> which formats should be validated on which chipsets.
>
> >> 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.

Ok, I have a significantly different background here. Because
beforehand my code was frequently based on rev-eng, on the incomplete
support by the hardware vendors and the frequently incomplete docs,
the argument "work" still prevails in my head compared to "claimed to
be supported by the vendor". In the end my goal was always to get more
from the hardware than the vendor has even thought about.


-- 
With best wishes
Dmitry