Am Dienstag, 24. Mai 2022, 09:29:43 CEST schrieb Marek Vasut:
> On 5/24/22 09:09, Alexander Stein wrote:
> > Hi Marek,
>
> Hi,
>
> > Am Donnerstag, 19. Mai 2022, 13:48:49 CEST schrieb Marek Vasut:
> >> Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
> >> completely different from the LCDIFv3 found in i.MX23 in that it has
> >> a completely scrambled register layout compared to all previous LCDIF
> >> variants. The new LCDIFv3 also supports 36bit address space.
> >>
> >> Add a separate driver which is really a fork of MXSFB driver with the
> >> i.MX8MP LCDIF variant handling filled in.
> >>
> >> Signed-off-by: Marek Vasut <ma...@denx.de>
> >> Cc: Alexander Stein <alexander.st...@ew.tq-group.com>
> >> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> >> Cc: Lucas Stach <l.st...@pengutronix.de>
> >> Cc: Peng Fan <peng....@nxp.com>
> >> Cc: Robby Cai <robby....@nxp.com>
> >> Cc: Sam Ravnborg <s...@ravnborg.org>
> >> Cc: Stefan Agner <ste...@agner.ch>
> >> ---
> >> V2: - Drop the pitch check from lcdif_fb_create()
> >>
> >> - Drop connector caching
> >> - Wait for shadow load bit to be cleared in IRQ handler
> >> - Make all clock mandatory and grab them all by name
> >> - Wait for EN to be cleared in lcdif_disable_controller
> >> - Rename to imx-lcdif
> >> - Move shadow load to atomic_flush
> >>
> >> V3: - Invert DE polarity to match MX8MPRM datasheet
> >>
> >> - Enable CSC in RGB to YUV mode for MEDIA_BUS_FMT_UYVY8_1X16
> >>
> >> V4: - Drop lcdif_overlay_plane_formats, it is unused
> >
> > Thanks for the update. With your change in V3 my HDMI output works now
> > without that hack mentioned. weston screen as well as 'fb-test -p 5'
> > output seems sensible.
> > Unfortunately this isn't the case for LVDS output on LCDIF2. I somehow
> > managed to get the DT nodes for LCDIF and LDB done. Also the necessary
> > addition to imx8m-blk-ctl. So eventually I can see some output. But the
> > screen is cutoff on the right side of about 15-20% and the screen is
> > flickering slighty. This is especially visible in 'fb-test -p 5'. The red
> > bars are only visible to less than 1/3 and the text as well as the
> > diagonal lines are flickering. Colors are correct though.
> > For the record: I am using a 'tianma,tm070jvhg33' panel.
>
> Does LDB start working if you apply:
>
> static const struct drm_bridge_funcs funcs = {
> .attach = fsl_ldb_attach,
> - .atomic_check = fsl_ldb_atomic_check,
> .atomic_enable = fsl_ldb_atomic_enable,
> .atomic_disable = fsl_ldb_atomic_disable,
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
>
> to
>
> drivers/gpu/drm/bridge/fsl-ldb.c
Thanks for the suggestion, but this doesn't change anything. For some reason
bridge_state->output_bus_cfg.flags is 0, rendering this function as a no-op
anyway. Why do we need to invert the DE signal polarity anyway?
I have a hunch this isn't related to data enable, I suspect this would lead to
completly borked colors. But as this is correct, I think something about HSYNC
is borked. VSYNC seems to be correct as the top and bottom lines are fine as
expected.
Best regards,
Alexander
