[PATCH 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant

[Marek Vasut]

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 ?