[PATCH v2 09/11] drm/exynos/hdmi: quirk for support mode timings conversion

Andrzej Hajda a.hajda at samsung.com
Wed Oct 18 09:36:43 UTC 2017


On 18.10.2017 04:31, Inki Dae wrote:
>
> 2017년 10월 17일 17:04에 Andrzej Hajda 이(가) 쓴 글:
>> On 17.10.2017 09:38, Inki Dae wrote:
>>> 2017년 09월 29일 19:05에 Andrzej Hajda 이(가) 쓴 글:
>>>> MIXER in SoCs prior to Exynos5420 supports only 4 video modes:
>>>> 720x480, 720x576, 1280x720, 1920x1080. Support for other modes
>>>> can be enabled by manipulating timings of HDMI. To do it
>>>> adjusted_mode should contain actual mode set on crtc.
>>>> With this patch it is possible to enable 1024x768 and 1280x1024
>>>> modes in MIXER.
>>>>
>>>> Suggested-by: Daniel Drake <drake at endlessm.com>
>>>> Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
>>>> Reviewed-by: Tobias Jakobi <tjakobi at math.uni-bielefeld.de>
>>>> ---
>>>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +++++++++++++--
>>>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>>> index 7225b6521148..4b081f6cfdcb 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>>> @@ -1239,6 +1239,17 @@ static void hdmi_v13_mode_apply(struct hdmi_context *hdata)
>>>>  static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
>>>>  {
>>>>  	struct drm_display_mode *m = &hdata->encoder.crtc->state->mode;
>>>> +	struct drm_display_mode *am = &hdata->encoder.crtc->state->adjusted_mode;
>>>> +	int hquirk = 0;
>>>> +
>>>> +	/*
>>>> +	 * In case video mode coming from CRTC differs from requested one HDMI
>>>> +	 * sometimes is able to almost properly perform conversion - only
>>>> +	 * first line is distorted.
>>>> +	 */
>>>> +	if ((m->vdisplay != am->vdisplay) &&
>>>> +	    (m->hdisplay == 1280 || m->hdisplay == 1024))
>>>> +		hquirk = 258;
>>> Andrzej,
>>>
>>> The distorted value couldn't be described logically? Just I wonder why the difference happens.
>> Without low level documentation of the IP one could only guess what
>> happens there.
>> In case of 1024x768 one can reason as follows:
>> - mixer sends image in format 1280x720, so it sends 1280 - 1024 = 256
>> pixels too much, so if we trim it in HDMI by 256 it should display it
>> correctly,
>> - but another quirk few lines later suppress 2 pixels from
>> hsync_(start,end), so to balance it we should add these pixels here, so
>> finally we have 256 + 2 = 258.
>>
>> This explanation seems quite reasonable, except it does not work for
>> 1280x1024 mode.
> We aren't sure 100% but above comment would be helpful to other developers. So could you leave the comment?

I have made a mistake, in case of requested 1024x768 mode mixer sends
image in 1920x1080 format.
So the whole reasoning does not make sense.

Regards
Andrzej

>
> Thanks,
> Inki Dae
>
>> Regards
>> Andrzej
>>
>>> Thanks,
>>> Inki Dae
>>>
>>>>  
>>>>  	hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
>>>>  	hdmi_reg_writev(hdata, HDMI_V_LINE_0, 2, m->vtotal);
>>>> @@ -1332,8 +1343,8 @@ static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
>>>>  	hdmi_reg_writev(hdata, HDMI_V_SYNC_LINE_AFT_PXL_6_0, 2, 0xffff);
>>>>  
>>>>  	hdmi_reg_writev(hdata, HDMI_TG_H_FSZ_L, 2, m->htotal);
>>>> -	hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay);
>>>> -	hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay);
>>>> +	hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay - hquirk);
>>>> +	hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay + hquirk);
>>>>  	hdmi_reg_writev(hdata, HDMI_TG_V_FSZ_L, 2, m->vtotal);
>>>>  	if (hdata->drv_data == &exynos5433_hdmi_driver_data)
>>>>  		hdmi_reg_writeb(hdata, HDMI_TG_DECON_EN, 1);
>>>>
>>
>>
>



More information about the dri-devel mailing list