On 2016年08月11日 16:32, Russell King -
ARM Linux wrote:
On Thu, Aug 11, 2016 at 03:54:03PM +0800, Mark Yao wrote:hdmi->disabled maybe not match to the real hardware status. ->dw_hdmi_bridge_enable() hdmi->disabled = false; -->dw_hdmi_update_power() if (hdmi->rxsense) force = DRM_FORCE_ON; else force = DRM_FORCE_OFF; hdmi->rxsense maybe false on bridge enable path, then hdmi->disabled is false, but actually hardware is power off, they are not match.... which is correct. If rxsense is false, it means there is nothing plugged in, so we don't power the hardware up until something _is_ plugged in. When something is plugged in, we get the HPD and RXSENSE events, which will cause dw_hdmi_update_power() to be called. hdmi->disabled is merely a bit mask of things that would cause us to want to avoid powering the hardware up when rxsense becomes true. At one moment, if hdmi->rxsense = false, hdmi->disabled = true, and the hdmi is unplug then we plug hdmi: 1, dw_hdmi_irq --> because disabled is true, so can't not run into the patch to enable hdmi->rxsense 2, uevent plugin 3, get_connector_detect: hdmi->disabled is true, so just report status connected 4, dw_hdmi_bridge_enable --> set hdmi->disabled = false, but because hdmi->rxsense is false, so force is power off. then the userspace thinks the hdmi is power on, but in fact it's power off. 5, unplug hdmi hdmi hardware rxsense status is false, also can't recovery to true. all the status back to step 1. So the bug is when hdmi->rxsense run into false, hardly to recovery. hdmi->rxsense = true request dw_hdmi_bridge_enable dw_hdmi_bridge_enable request "hdmi->rxsense == true" -- Mark Yao |
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel