|
On 2016年08月11日 17:09, Mark yao wrote:
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.
if another hdmi irq can happen here, that can break the deadlock,
but I don't see any irq happen after this step.
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
--
Ｍark Yao
|
