linux-kernel - Re: [PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 28 Sep 2016 19:53:16 -0700
From:   Eric Anholt <eric@...olt.net>
To:     Mark yao <mark.yao@...k-chips.com>, dri-devel@...ts.freedesktop.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

Mark yao <mark.yao@...k-chips.com> writes:

> On 2016年09月29日 10:20, Eric Anholt wrote:
>> We just needed to initialize a few more fields.
>>
>> Signed-off-by: Eric Anholt <eric@...olt.net>
>> ---
>>   drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++++++++++++++---
>>   drivers/gpu/drm/vc4/vc4_hdmi.c | 12 ++++++++----
>>   drivers/gpu/drm/vc4/vc4_regs.h |  3 +++
>>   3 files changed, 25 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
>> index 8fc2b731b59a..d575f8aa3273 100644
>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
>> @@ -428,13 +428,24 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
>>   			   VC4_SET_FIELD(mode->vsync_start - mode->vdisplay,
>>   					 PV_VERTB_VFP) |
>>   			   VC4_SET_FIELD(vactive, PV_VERTB_VACTIVE));
>> +
>> +		/* We set up first field even mode for HDMI.  VEC's
>> +		 * NTSC mode would want first field odd instead, once
>> +		 * we support it (to do so, set ODD_FIRST and put the
>> +		 * delay in VSYNCD_EVEN instead).
>> +		 */
>> +		CRTC_WRITE(PV_V_CONTROL,
>> +			   PV_VCONTROL_CONTINUOUS |
>> +			   PV_VCONTROL_INTERLACE |
>> +			   VC4_SET_FIELD(mode->htotal / 2,
>> +					 PV_VCONTROL_ODD_DELAY));
>> +		CRTC_WRITE(PV_VSYNCD_EVEN, 0);
>> +	} else {
>> +		CRTC_WRITE(PV_V_CONTROL, PV_VCONTROL_CONTINUOUS);
>>   	}
>>   
>>   	CRTC_WRITE(PV_HACT_ACT, mode->hdisplay);
>>   
>> -	CRTC_WRITE(PV_V_CONTROL,
>> -		   PV_VCONTROL_CONTINUOUS |
>> -		   (interlace ? PV_VCONTROL_INTERLACE : 0));
>>   
>>   	CRTC_WRITE(PV_CONTROL,
>>   		   VC4_SET_FIELD(format, PV_CONTROL_FORMAT) |
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 5770d6704f4b..6095e48fcf46 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -246,7 +246,7 @@ static struct drm_connector *vc4_hdmi_connector_init(struct drm_device *dev,
>>   	connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
>>   			     DRM_CONNECTOR_POLL_DISCONNECT);
>>   
>> -	connector->interlace_allowed = 0;
>> +	connector->interlace_allowed = true;
>>   	connector->doublescan_allowed = 0;
>>   
>>   	drm_mode_connector_attach_encoder(connector, encoder);
>> @@ -278,8 +278,8 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder *encoder,
>>   	bool debug_dump_regs = false;
>>   	bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
>>   	bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
>> -	u32 vactive = (mode->vdisplay >>
>> -		       ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0));
>> +	bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
>> +	u32 vactive = mode->vdisplay >> interlaced;
>
> How about use mode->crtc_vdisplay:
>
> see this:
> drm_mode_set_crtcinfo()
>
>      if (p->flags & DRM_MODE_FLAG_INTERLACE) {
>          if (adjust_flags & CRTC_INTERLACE_HALVE_V) {
>              p->crtc_vdisplay /= 2;
>              p->crtc_vsync_start /= 2;
>              p->crtc_vsync_end /= 2;
>              p->crtc_vtotal /= 2;
>          }
>      }

That would require setting up the adjust_flags, and I thought in the DRM
we were trying to move away from using it.  Also it would be pretty
strange to use just this one field from crtc_*.


Download attachment "signature.asc" of type "application/pgp-signature" (801 bytes)