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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:   Tue, 21 Sep 2021 10:27:58 +0200
From:   Neil Armstrong <narmstrong@...libre.com>
To:     Yunlongli <liyunlonga@...ontech.com>, ple@...libre.com,
        a.hajda@...sung.com, robert.foss@...aro.org, airlied@...ux.ie,
        daniel@...ll.ch
Cc:     Laurent.pinchart@...asonboard.com, jonas@...boo.se,
        jernej.skrabec@...il.com, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm: bridge: it66121: Added it66121 chip external screen
 status judgment

Hi,

On 21/09/2021 09:54, Yunlongli wrote:
> In the actual tests,  the IT66121 chip sometimes misjudged whether
> it had an external screen, so, reference the it66121_user_guid.pdf
> about Audio/Video data is stable or not A typical initialization
> of HDMI link should be based on interrupt signal and appropriate
> register probing. Recommended flow is detailed in IT66121
> Programming Guide. Simply put, the microcontroller should monitor
> the HPD status first. Upon valid HPD event, move on to check
> RxSENDetect register to see if the receiver chip is ready for
> further handshaking. When RxSENDetect is asserted, start reading EDID
> data through DDC channels and carry on the rest of the handshaking
> subsequently.If the micro-controller makes no use of the interrupt
> signal as well as the above-mentioned status  registers, the link
> establishment might fail. Please do follow the suggested
> initialization flow recommended in IT66121 Programming Guide.
> So, I add the IT66121_SYS_STATUS_SENDECTECT register status detection.

Ok, the RxSENDetect is the "rx-sense" detection bit as described in the same doc:

Receiver detection circuit reports the presence or absence of an active termination at the TMDS Clock Channel (RxSENDetect)

The usage of the rx-sense signal in hpd_detect() is not clear because this would break detection of "Fake" EDID dongles or idle monitors.

The dw-hdmi handles the rx-sense, but only to power-on/off the HDMI TX, but only returns the HPD status to DRM without the RX SENSE state,
so it only saves power and doesn't change anything on DRM HPD detection.

So not sure if we should merge this as-is.

Neil

> 
> Signed-off-by: Yunlongli <liyunlonga@...ontech.com>
> ---
>  drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c
> index 2f2a09adb4bc..9ed4fa298d11 100644
> --- a/drivers/gpu/drm/bridge/ite-it66121.c
> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
> @@ -523,7 +523,7 @@ static bool it66121_is_hpd_detect(struct it66121_ctx *ctx)
>  	if (regmap_read(ctx->regmap, IT66121_SYS_STATUS_REG, &val))
>  		return false;
>  
> -	return val & IT66121_SYS_STATUS_HPDETECT;
> +	return ((val & IT66121_SYS_STATUS_HPDETECT) && (val & IT66121_SYS_STATUS_SENDECTECT));
>  }
>  
>  static int it66121_bridge_attach(struct drm_bridge *bridge,
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ