[PATCH v2 4/4] drm: lcdif: Add support for YUV planes

[Laurent Pinchart]

Hi Liu,

On Thu, Sep 29, 2022 at 05:53:37PM +0800, Liu Ying wrote:
> On Wed, 2022-09-28 at 03:58 +0300, Laurent Pinchart wrote:
> > From: Kieran Bingham <kieran.bingham at ideasonboard.com>
> > 
> > The LCDIF includes a color space converter that supports YUV input. Use
> > it to support YUV planes, either through the converter if the output
> > format is RGB, or in conversion bypass mode otherwise.
> > 
> > Signed-off-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > ---
> > Changes since v1:
> > 
> > - Support all YCbCr encodings and quantization ranges
> > - Drop incorrect comment
> > ---
> >  drivers/gpu/drm/mxsfb/lcdif_kms.c  | 183 +++++++++++++++++++++++++----
> >  drivers/gpu/drm/mxsfb/lcdif_regs.h |   5 +-
> >  2 files changed, 164 insertions(+), 24 deletions(-)
> 
> I have a chance to test this series and find that my
> 'koe,tx26d202vm0bwa' 1920x1200 LVDS panel connected with i.MX8mp EVK
> can only show the test pattern at the top half of the display with YUV
> fb. Looks like something with wrong stride. XR24 fb is ok, but RG16 fb
> has similar issue. Anything I missed?
> 
> The command I'm using to test YUV fb:
> modetest -M imx-lcdif -P 31 at 35:1920x1200 at YUYV 

Thanks for the bug report. The problem didn't occur with kmstest nor the
libcamera 'cam' test application, but I have been able to reproduce it
with modetest. The modetest application uses the legacy mode setting API
by default, so it exercises code paths in the driver in different ways,
uncovering a few preexisting issues.

The problem is caused by the fact that the functions called from the
.atomic_enable() handler access the frame buffer from the plane state
and configure the hardware using that information. Depending on how the
device is configured, the display can be enabled with one frame buffer,
and then immediately switch to a different frame buffer that has a
different format and/or pitch.

Properties of the frame buffer should only be accessed from the plane
.atomic_update() operation. Fixing this requires quite a bit of
refactoring of the driver, which I won't have time to work on at the
moment. Marek, would you have some time to look at this ? As the issue
isn't introduced by this series but preexists (you should be able to
reproduce it by selecting the XR15 format instead of XR24 for instance),
can YUV support be merged already (after I send v3) ?

-- 
Regards,

Laurent Pinchart