diff mbox series

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

Message ID 20240222-fd-dpu-yv16-yv24-v1-1-4aa833cdc641@linaro.org
State New
Headers show
Series drm/msm/dpu: add support for 4:2:2 and 4:4:4 planar YCbCr plane formats | expand

Commit Message

Dmitry Baryshkov Feb. 22, 2024, 11:43 a.m. UTC
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.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
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.
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c    | 24 ++++++++++++++++++++++++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  4 ++++
 2 files changed, 28 insertions(+)


---
base-commit: ffa0c87f172bf7a0132aa960db412f8d63b2f533
change-id: 20240222-fd-dpu-yv16-yv24-6bf152dfa7f3

Best regards,

Comments

Abhinav Kumar Feb. 23, 2024, 8:48 p.m. UTC | #1
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@linaro.org>
> ---
> 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.

> ---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c    | 24 ++++++++++++++++++++++++
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  4 ++++
>   2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> index e366ab134249..1b763cd95e5a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> @@ -475,6 +475,30 @@ static const struct dpu_format dpu_format_map[] = {
>   		C1_B_Cb, C2_R_Cr, C0_G_Y,
>   		false, DPU_CHROMA_420, 1, DPU_FORMAT_FLAG_YUV,
>   		DPU_FETCH_LINEAR, 3),
> +
> +	PLANAR_YUV_FMT(YUV422,
> +		0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> +		C2_R_Cr, C1_B_Cb, C0_G_Y,
> +		false, DPU_CHROMA_H2V1, 1, DPU_FORMAT_FLAG_YUV,
> +		DPU_FETCH_LINEAR, 3),
> +
> +	PLANAR_YUV_FMT(YVU422,
> +		0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> +		C1_B_Cb, C2_R_Cr, C0_G_Y,
> +		false, DPU_CHROMA_H2V1, 1, DPU_FORMAT_FLAG_YUV,
> +		DPU_FETCH_LINEAR, 3),
> +
> +	PLANAR_YUV_FMT(YUV444,
> +		0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> +		C2_R_Cr, C1_B_Cb, C0_G_Y,
> +		false, DPU_CHROMA_RGB, 1, DPU_FORMAT_FLAG_YUV,
> +		DPU_FETCH_LINEAR, 3),
> +
> +	PLANAR_YUV_FMT(YVU444,
> +		0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> +		C1_B_Cb, C2_R_Cr, C0_G_Y,
> +		false, DPU_CHROMA_RGB, 1, DPU_FORMAT_FLAG_YUV,
> +		DPU_FETCH_LINEAR, 3),
>   };
>   
>   /*
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index ccbee0f40ad7..949c86a44ec7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -195,6 +195,10 @@ static const uint32_t plane_formats_yuv[] = {
>   	DRM_FORMAT_YVYU,
>   	DRM_FORMAT_YUV420,
>   	DRM_FORMAT_YVU420,
> +	DRM_FORMAT_YUV422,
> +	DRM_FORMAT_YVU422,
> +	DRM_FORMAT_YUV444,
> +	DRM_FORMAT_YVU444,
>   };
>   
>   static const u32 rotation_v2_formats[] = {
> 
> ---
> base-commit: ffa0c87f172bf7a0132aa960db412f8d63b2f533
> change-id: 20240222-fd-dpu-yv16-yv24-6bf152dfa7f3
> 
> Best regards,
Dmitry Baryshkov Feb. 23, 2024, 8:52 p.m. UTC | #2
On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar <quic_abhinavk@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?

No reference. I was interested in checking different YUV formats for
the test. It worked, so I wanted to discuss this. In the end, we are
just changing several bits, which are used for other formats.

>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> > 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.

As I wrote, YV24 also works if I slightly bump the clock inefficiency.
I think this points out that maybe we should calculate clock factor
dynamically.

>
> > ---
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c    | 24 ++++++++++++++++++++++++
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  4 ++++
> >   2 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> > index e366ab134249..1b763cd95e5a 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> > @@ -475,6 +475,30 @@ static const struct dpu_format dpu_format_map[] = {
> >               C1_B_Cb, C2_R_Cr, C0_G_Y,
> >               false, DPU_CHROMA_420, 1, DPU_FORMAT_FLAG_YUV,
> >               DPU_FETCH_LINEAR, 3),
> > +
> > +     PLANAR_YUV_FMT(YUV422,
> > +             0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> > +             C2_R_Cr, C1_B_Cb, C0_G_Y,
> > +             false, DPU_CHROMA_H2V1, 1, DPU_FORMAT_FLAG_YUV,
> > +             DPU_FETCH_LINEAR, 3),
> > +
> > +     PLANAR_YUV_FMT(YVU422,
> > +             0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> > +             C1_B_Cb, C2_R_Cr, C0_G_Y,
> > +             false, DPU_CHROMA_H2V1, 1, DPU_FORMAT_FLAG_YUV,
> > +             DPU_FETCH_LINEAR, 3),
> > +
> > +     PLANAR_YUV_FMT(YUV444,
> > +             0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> > +             C2_R_Cr, C1_B_Cb, C0_G_Y,
> > +             false, DPU_CHROMA_RGB, 1, DPU_FORMAT_FLAG_YUV,
> > +             DPU_FETCH_LINEAR, 3),
> > +
> > +     PLANAR_YUV_FMT(YVU444,
> > +             0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> > +             C1_B_Cb, C2_R_Cr, C0_G_Y,
> > +             false, DPU_CHROMA_RGB, 1, DPU_FORMAT_FLAG_YUV,
> > +             DPU_FETCH_LINEAR, 3),
> >   };
> >
> >   /*
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > index ccbee0f40ad7..949c86a44ec7 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > @@ -195,6 +195,10 @@ static const uint32_t plane_formats_yuv[] = {
> >       DRM_FORMAT_YVYU,
> >       DRM_FORMAT_YUV420,
> >       DRM_FORMAT_YVU420,
> > +     DRM_FORMAT_YUV422,
> > +     DRM_FORMAT_YVU422,
> > +     DRM_FORMAT_YUV444,
> > +     DRM_FORMAT_YVU444,
> >   };
> >
> >   static const u32 rotation_v2_formats[] = {
> >
> > ---
> > base-commit: ffa0c87f172bf7a0132aa960db412f8d63b2f533
> > change-id: 20240222-fd-dpu-yv16-yv24-6bf152dfa7f3
> >
> > Best regards,
Dmitry Baryshkov March 21, 2024, 3:43 p.m. UTC | #3
On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar <quic_abhinavk@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@linaro.org>
> > ---
> > 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.


--
With best wishes
Dmitry
Abhinav Kumar March 21, 2024, 5:35 p.m. UTC | #4
On 3/21/2024 8:43 AM, Dmitry Baryshkov wrote:
> On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar <quic_abhinavk@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@linaro.org>
>>> ---
>>> 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".

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
Dmitry Baryshkov March 21, 2024, 6:09 p.m. UTC | #5
On Thu, 21 Mar 2024 at 19:36, Abhinav Kumar <quic_abhinavk@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@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@linaro.org>
> >>> ---
> >>> 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.
Abhinav Kumar March 21, 2024, 6:27 p.m. UTC | #6
On 3/21/2024 11:09 AM, Dmitry Baryshkov wrote:
> On Thu, 21 Mar 2024 at 19:36, Abhinav Kumar <quic_abhinavk@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@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@linaro.org>
>>>>> ---
>>>>> 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.
> 
>
Dmitry Baryshkov March 21, 2024, 6:43 p.m. UTC | #7
On Thu, 21 Mar 2024 at 20:28, Abhinav Kumar <quic_abhinavk@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@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@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@linaro.org>
> >>>>> ---
> >>>>> 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.

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.
diff mbox series

Patch

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index e366ab134249..1b763cd95e5a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -475,6 +475,30 @@  static const struct dpu_format dpu_format_map[] = {
 		C1_B_Cb, C2_R_Cr, C0_G_Y,
 		false, DPU_CHROMA_420, 1, DPU_FORMAT_FLAG_YUV,
 		DPU_FETCH_LINEAR, 3),
+
+	PLANAR_YUV_FMT(YUV422,
+		0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+		C2_R_Cr, C1_B_Cb, C0_G_Y,
+		false, DPU_CHROMA_H2V1, 1, DPU_FORMAT_FLAG_YUV,
+		DPU_FETCH_LINEAR, 3),
+
+	PLANAR_YUV_FMT(YVU422,
+		0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+		C1_B_Cb, C2_R_Cr, C0_G_Y,
+		false, DPU_CHROMA_H2V1, 1, DPU_FORMAT_FLAG_YUV,
+		DPU_FETCH_LINEAR, 3),
+
+	PLANAR_YUV_FMT(YUV444,
+		0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+		C2_R_Cr, C1_B_Cb, C0_G_Y,
+		false, DPU_CHROMA_RGB, 1, DPU_FORMAT_FLAG_YUV,
+		DPU_FETCH_LINEAR, 3),
+
+	PLANAR_YUV_FMT(YVU444,
+		0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+		C1_B_Cb, C2_R_Cr, C0_G_Y,
+		false, DPU_CHROMA_RGB, 1, DPU_FORMAT_FLAG_YUV,
+		DPU_FETCH_LINEAR, 3),
 };
 
 /*
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index ccbee0f40ad7..949c86a44ec7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -195,6 +195,10 @@  static const uint32_t plane_formats_yuv[] = {
 	DRM_FORMAT_YVYU,
 	DRM_FORMAT_YUV420,
 	DRM_FORMAT_YVU420,
+	DRM_FORMAT_YUV422,
+	DRM_FORMAT_YVU422,
+	DRM_FORMAT_YUV444,
+	DRM_FORMAT_YVU444,
 };
 
 static const u32 rotation_v2_formats[] = {