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 marex@denx.de Cc: Alexander Stein alexander.stein@ew.tq-group.com Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Lucas Stach l.stach@pengutronix.de Cc: Peng Fan peng.fan@nxp.com Cc: Robby Cai robby.cai@nxp.com Cc: Sam Ravnborg sam@ravnborg.org Cc: Stefan Agner stefan@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_flushV3: - Invert DE polarity to match MX8MPRM datasheet
- Enable CSC in RGB to YUV mode for MEDIA_BUS_FMT_UYVY8_1X16V4: - 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