public inbox for linux-rockchip@lists.infradead.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Romain Perier <romain.perier@collabora.com>
Cc: Archit Taneja <architt@codeaurora.org>,
	David Airlie <airlied@linux.ie>, Heiko Stuebner <heiko@sntech.de>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	Sjoerd Simons <sjoerd.simons@collabora.co.uk>,
	linux-arm-kernel@lists.infradead.org,
	Daniel Stone <daniels@collabora.com>
Subject: Re: [PATCH RESEND] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD
Date: Thu, 9 Mar 2017 14:48:37 +0000	[thread overview]
Message-ID: <20170309144837.GK21222@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20170308081524.7672-1-romain.perier@collabora.com>

On Wed, Mar 08, 2017 at 09:15:24AM +0100, Romain Perier wrote:
> - dw_hdmi_update_power() will be called. As hdmi->force will be equal to
> DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. This
> field has not been updated by the irq handler, so it will be false and
> DRM_FORCE_ON won't be put to hdmi->force.

Right, and wrong.

Your initial part is correct, but the latter sentence is incorrect -
we only ever update hdmi->force according to the user's force requests,
never as a result of the current state of the driver.

hdmi->force exists to allow the user to say "I want to force this connector
to always report disconnected or connected" to work around stupid monitors
that pulse everything from HPD to RXSENSE when in standby mode.

> This commit fixes the issue by removing the check for "!hdmi->disabled".
> As already explained, even if the PHY is partially disabled, information
> coming from HDMI Transmitter about HPD should be saved for a later use.

Your fix looks fine to me, as both dw_hdmi_update_power() and
dw_hdmi_update_phy_mask() effectively ignore attempts to update the
state while hdmi->disabled is true.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

      parent reply	other threads:[~2017-03-09 14:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-08  8:15 [PATCH RESEND] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD Romain Perier
     [not found] ` <20170308081524.7672-1-romain.perier-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2017-03-09 14:28   ` Jose Abreu
2017-03-09 15:37     ` Romain Perier
2017-03-09 14:48 ` Russell King - ARM Linux [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170309144837.GK21222@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=airlied@linux.ie \
    --cc=architt@codeaurora.org \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=romain.perier@collabora.com \
    --cc=sjoerd.simons@collabora.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox