nouveau.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Claudio Suarez <cssk@net-c.es>
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	linux-tegra@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Pan Xinhui" <Xinhui.Pan@amd.com>,
	"Emma Anholt" <emma@anholt.net>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Patrik Jakobsson" <patrik.r.jakobsson@gmail.com>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Rob Clark" <robdclark@gmail.com>, "Sean Paul" <sean@poorly.run>,
	linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Sandy Huang" <hjc@rock-chips.com>,
	heiko@sntech.de, "Neil Armstrong" <narmstrong@baylibre.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	nouveau@lists.freedesktop.org
Subject: Re: [Nouveau] [Intel-gfx] [PATCH v3 13/13] drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
Date: Fri, 22 Oct 2021 15:22:57 +0300	[thread overview]
Message-ID: <YXKtIUDk+f2Bnn++@intel.com> (raw)
In-Reply-To: <YXKoMEF/gU98cL9n@intel.com>

On Fri, Oct 22, 2021 at 03:01:52PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 22, 2021 at 12:25:33PM +0200, Claudio Suarez wrote:
> > On Thu, Oct 21, 2021 at 04:49:59PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote:
> > > > drm_get_edid() internally calls to drm_connector_update_edid_property()
> > > > and then drm_add_display_info(), which parses the EDID.
> > > > This happens in the function intel_hdmi_set_edid() and
> > > > intel_sdvo_tmds_sink_detect() (via intel_sdvo_get_edid()).
> > > > 
> > > > Once EDID is parsed, the monitor HDMI support information is available
> > > > through drm_display_info.is_hdmi. Retriving the same information with
> > > > drm_detect_hdmi_monitor() is less efficient. Change to
> > > > drm_display_info.is_hdmi
> > > 
> > > I meant we need to examine all call chains that can lead to
> > > .detect() to make sure all of them do in fact update the
> > > display_info beforehand.
> > 
> > Well, I studied it carefully and, yes, all call chains that can lead to
> > drm_display_info.is_hdmi / drm_detect_hdmi_monitor() update display_info
> > beforehand. In the case that this doesn't happen, the code is unchanged.
> > 
> > Do you want I explain the changes in the code here again ? Or do you want
> > to me change the commit message to be more clear ? In the first case, I can
> > write here a detailed explanation. In the second case I can make a longer commit
> > message.
> > 
> > Or both?
> 
> I want all those call chains explained in the commit message,
> otherwise I have no easy way to confirm whether the change
> is correct or not.

Hmm. OK, so I had a bit of a dig around and seems that what we do now
.detect()->drm_get_edid()->drm_connector_update_edid_property()->drm_add_display_info()

Now the question is when did that start happening? Looks like it was
commit 4b4df570b41d ("drm: Update edid-derived drm_display_info fields
at edid property set [v2]") that started to call drm_add_display_info()
from drm_connector_update_edid_property(), and then commit 5186421cbfe2
("drm: Introduce epoch counter to drm_connector") started to call
drm_connector_update_edid_property() from drm_get_edid(). Before both
of those commits were in place display_info would still contain
some stale garbage during .detect().

That is the story I think we want in these commit messages since it
a) explains why the old code was directly parsing the edid instead
b) why it's now safe to change this

PS. connector->force handling in drm_get_edid() looks a bit busted
since it doesn't call drm_connector_update_edid_property() at all
in some cases. I think there might be some path that leads there
anywya if/when we change connector->force, but we should fix
drm_get_edid() to do the right thing regarless.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2021-10-22 12:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-16 18:42 [Nouveau] [PATCH v2 00/13] replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 01/13] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info Claudio Suarez
2021-10-19 18:35   ` Ville Syrjälä
2021-10-19 22:40     ` Claudio Suarez
2021-10-19 22:49     ` [Nouveau] [PATCH v3 " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 02/13] drm/vc4: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 03/13] drm/radeon: " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 04/13] drm/tegra: " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 05/13] drm/gma500: " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 06/13] drm/exynos: " Claudio Suarez
2021-10-26 22:28   ` Inki Dae
2021-11-02 12:34     ` Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 07/13] drm/msm: " Claudio Suarez
2021-11-25 13:26   ` Dmitry Baryshkov
2021-10-16 18:42 ` [Nouveau] [PATCH v2 08/13] drm/sun4i: " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 09/13] drm/sti: " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 10/13] drm/rockchip: " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 11/13] drm/bridge: " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 12/13] drm/nouveau: " Claudio Suarez
2021-10-16 18:42 ` [Nouveau] [PATCH v2 13/13] drm/i915: " Claudio Suarez
2021-10-19 18:37   ` Ville Syrjälä
2021-10-19 22:51     ` [Nouveau] [PATCH v3 " Claudio Suarez
2021-10-21 13:49       ` Ville Syrjälä
2021-10-22 10:25         ` Claudio Suarez
2021-10-22 12:01           ` Ville Syrjälä
2021-10-22 12:22             ` Ville Syrjälä [this message]
2021-10-24 22:17               ` [Nouveau] [Intel-gfx] " Claudio Suarez
2021-11-02 12:56                 ` [Nouveau] " Claudio Suarez
2021-11-02 13:00                 ` [Nouveau] [PATCH v4 " Claudio Suarez

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=YXKtIUDk+f2Bnn++@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bskeggs@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=cssk@net-c.es \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=freedreno@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jingoohan1@gmail.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mripard@kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=patrik.r.jakobsson@gmail.com \
    --cc=robdclark@gmail.com \
    --cc=robert.foss@linaro.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=sean@poorly.run \
    --cc=thierry.reding@gmail.com \
    --cc=wens@csie.org \
    /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;
as well as URLs for NNTP newsgroup(s).