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@xxxxxxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxxxxxx> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > --- > > 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@35:1920x1200@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
