nouveau.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Claudio Suarez <cssk@net-c.es>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
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: Mon, 25 Oct 2021 00:17:37 +0200	[thread overview]
Message-ID: <YXXbgWNHts9CMJXD@gineta.localdomain> (raw)
In-Reply-To: <YXKtIUDk+f2Bnn++@intel.com>

On Fri, Oct 22, 2021 at 03:22:57PM +0300, Ville Syrjälä wrote:
> 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()

Yes. I said before that I felt something was wrong when I read the
documentation and then the code. To be more explicit now, I expected that
drm_connector_update_edid_property() will be done in the
fill_modes/get_modes phase instead of when reading the edid.
The documentation suggests that but the code reads the edid in the
detect phase.
Now, since drm_connector_update_edid_property() is called in the detect
phase, it is not necessary to keep the edid data in the private connector
struct. It is in struct drm_connector from the beginning.
But this is topic for another patch.

> 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

------------------commit-message?--------------------

drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi

Commit a92d083d08b0 created the new flag is_hdmi in drm_display_info
which is set when sink compliant with CEA-861 (EDID) shall be treated
as an HDMI sink.

From that day, this value can be used in some cases instead of
calling drm_detect_hdmi_monitor() and a second parse is avoided
because drm_detect_hdmi_monitor() parses. A TODO task was
registered in Documentation/gpu/todo.rst to perform that task in
the future.

The flag drm_display_info.is_hdmi is set in the function
drm_add_display_info(), which is called from
drm_connector_update_edid_property(). Since commit 5186421cbfe2,
drm_get_edid() calls drm_connector_update_edid_property() when
reading the edid data from an i2c adapter. Therefore, in these
cases drm_display_info.is_hdmi is updated to its correct
value when returning from drm_get_edid().

Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
in the cases when drm_detect_hdmi_monitor() is called after a
read from an i2c adapter using drm_get_edid() in the i915 driver.
-----------------------------------------------

> 
> 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.

In those cases, the edid isn't read and NULL is returned by drm_get_edid().
No problem because display_info.is_hdmi is inside an if (edid != NULL).

BTW, struct intel_connector is allocated with kzalloc, so the initial
value of is_hdmi is zero. The connector isn't HDMI by default.

BR.
Claudio Suarez.



  reply	other threads:[~2021-10-25  6: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             ` [Nouveau] [Intel-gfx] " Ville Syrjälä
2021-10-24 22:17               ` Claudio Suarez [this message]
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=YXXbgWNHts9CMJXD@gineta.localdomain \
    --to=cssk@net-c.es \
    --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=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=ville.syrjala@linux.intel.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).