| 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 |
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,
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,
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
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
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.
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. > >
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 --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[] = {
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,