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"

-- 
Ｍark Yao