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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 6 Oct 2015 15:03:20 -0300 From: Fabio Estevam <festevam@...il.com> To: Russell King <rmk+kernel@....linux.org.uk> Cc: linux-rockchip@...ts.infradead.org, DRI mailing list <dri-devel@...ts.freedesktop.org>, linux-kernel <linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Fabio Estevam <fabio.estevam@...escale.com>, Yakir Yang <ykk@...k-chips.com>, Andy Yan <andy.yan@...k-chips.com> Subject: Re: [PATCH 12/12] drm: bridge/dw_hdmi: improve HDMI enable/disable handling On Sat, Aug 8, 2015 at 1:04 PM, Russell King <rmk+kernel@....linux.org.uk> wrote: > HDMI sinks are permitted to de-assert and re-assert the HPD signal to > indicate that their EDID has been updated, which may not involve a > change of video information. > > An example of where such a situation can arise is when an AV receiver > is connected between the source and the display device. Events which > can cause the HPD to be deasserted include: > > * turning on or switching to standby the AV receiver. > * turning on or switching to standby the display device. > > Each of these can change the entire EDID data, or just a part of the > EDID data - it's up to the connected HDMI sink to do what they desire > here. For example > > - with the AV receiver and display device both in standby, a source > connected to the AV receiver may provide its own EDID to the source. > - turning on the display device causes the display device's EDID to be > made available in an unmodified form to the source. > - subsequently turning on the AV receiver then provides a modified > version of the display device's EDID. > > Moreover, HPD doesn't tell us whether something is actually listening > on the HDMI TDMS signals. The phy gives us a set of RXSENSE indications > which tell us whether there is a sink connected to the TMDS signals. > > Currently, we use the HPD signal to enable or disable the HDMI block, > which is questionable when HPD is used in this manner. Using the > RXSENSE would be more appropriate, but there is some bad behaviour > which needs to be coped with. The iMX6 implementation lets the TMDS > signals float when the phy is "powered down", which cause spurious > interrupts. Rather than just using RXSENSE, use RXSENSE and HPD > becoming both active to signal the presence of a device, but loss > of RXSENSE to indicate that the device has been unplugged. > > The side effect of this change is that a sink deasserting the HPD > signal to cause a re-read of the EDID data will not cause the bridge > to immediately disable the video signal. > > Signed-off-by: Russell King <rmk+kernel@....linux.org.uk> Reviewed-by: Fabio Estevam <fabio.estevam@...escale.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists