On 4/7/22 10:48, Lucas Stach wrote:
[...]
+static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
+{
+ struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
+ u32 ctrl = 0;
+
+ if (m->flags & DRM_MODE_FLAG_PHSYNC)
+ ctrl |= CTRL_INV_HS;
+ if (m->flags & DRM_MODE_FLAG_PVSYNC)
+ ctrl |= CTRL_INV_VS;
+ /* Make sure Data Enable is high active by default */
+ if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
+ ctrl |= CTRL_INV_DE;
The above three controls seems to have the wrong polarity. Bit set
means low active according to the register documentation and the PVI in
the HDMI path, which has configurable input signal polarity, seems to
agree with that.
I seem to recall seeing something about DE polarity being inverted in
odd way in the NXP downstream driver, and differently for each LCDIF
instance. Isn't that what you're seeing with HDMI ?
Yes, there seems to be some funky business going on here. I guess for
the MIPI DSI path it's the same as on the i.MX8MM where the DSI core
always expects the sync to be low active IIRC. In the HDMI path there
is a block called PVI, which can be configured on what sync polarity to
expect on the input. My experiments show that if I program the PVI for
high active sync signals, the CTRL_INV_* bits must not be set in the
LCDIF for the PVI to pick up the signal, which is consistent with the
documentation of those bits in the LCDIF register map.
In terms of DE invert, the downstream driver indicates it is needed for
both HDMI and DSI and not for LDB, and I already tested the later two
(DSI and LDB). Maybe the HDMI bridge driver needs DE polarity inverted
in one of the atomic callbacks ?
