On 3/21/2024 11:09 AM, Dmitry Baryshkov wrote:
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.
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.
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.
