All of lore.kernel.org
 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: [Intel-gfx] [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info
Date: Fri, 15 Oct 2021 22:46:59 +0300	[thread overview]
Message-ID: <YWnas70UYAdjZFKo@intel.com> (raw)
In-Reply-To: <YWnXierh4TSXpDMc@intel.com>

On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > > According to the documentation, drm_add_edid_modes
> > > > "... Also fills out the &drm_display_info structure and ELD in @connector
> > > > with any information which can be derived from the edid."
> > > > 
> > > > drm_add_edid_modes accepts a struct edid *edid parameter which may have a
> > > > value or may be null. When it is not null, connector->display_info and
> > > > connector->eld are updated according to the edid. When edid=NULL, only
> > > > connector->eld is reset. Reset connector->display_info to be consistent
> > > > and accurate.
> > > > 
> > > > Signed-off-by: Claudio Suarez <cssk@net-c.es>
> > > > ---
> > > >  drivers/gpu/drm/drm_edid.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 6325877c5fd6..6cbe09b2357c 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -5358,10 +5358,12 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> > > >  
> > > >  	if (edid == NULL) {
> > > >  		clear_eld(connector);
> > > > +		drm_reset_display_info(connector);
> > > >  		return 0;
> > > >  	}
> > > >  	if (!drm_edid_is_valid(edid)) {
> > > >  		clear_eld(connector);
> > > > +		drm_reset_display_info(connector);
> > > 
> > > Looks easier if you pull both of those out from these branches and
> > > just call them unconditionally at the start.
> > 
> > After looking at the full code, I am not sure. This is the code:
> > ==================
> > int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> > {
> >         int num_modes = 0;
> >         u32 quirks;
> > 
> >         if (edid == NULL) {
> >                 clear_eld(connector);
> >                 drm_reset_display_info(connector); <--- added by me
> >                 return 0;
> >         }
> >         if (!drm_edid_is_valid(edid)) {
> >                 clear_eld(connector);
> >                 drm_reset_display_info(connector); <--- added by me
> >                 drm_warn(connector->dev, "%s: EDID invalid.\n",
> >                          connector->name);
> >                 return 0;
> >         }
> > 
> >         drm_edid_to_eld(connector, edid);
> > 
> >         quirks = drm_add_display_info(connector, edid);
> > 	etc...
> > =================
> > 
> > If we move those out of these branches and edid != NULL, we are executing an
> > unnecessary clear_eld(connector) and an unnecessary drm_reset_display_info(connector)
> > because the fields will be set in the next drm_edid_to_eld(connector, edid) and
> > drm_add_display_info(connector, edid)
> > 
> > Do we want this ?
> 
> Seems fine by me. And maybe we could nuke the second
> drm_reset_display_info() from deeper inside drm_add_display_info()?
> Not sure if drm_add_display_info() still has to be able to operate
> standalone or not.
> 
> Hmm. Another option is to just move all these NULL/invalid edid
> checks into drm_edid_to_eld() and drm_add_display_info().

But maybe that's not so easy. Would still need to bail out
from drm_add_edid_modes() I guess.

-- 
Ville Syrjälä
Intel

WARNING: multiple messages have this Message-ID (diff)
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 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info
Date: Fri, 15 Oct 2021 22:46:59 +0300	[thread overview]
Message-ID: <YWnas70UYAdjZFKo@intel.com> (raw)
In-Reply-To: <YWnXierh4TSXpDMc@intel.com>

On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > > According to the documentation, drm_add_edid_modes
> > > > "... Also fills out the &drm_display_info structure and ELD in @connector
> > > > with any information which can be derived from the edid."
> > > > 
> > > > drm_add_edid_modes accepts a struct edid *edid parameter which may have a
> > > > value or may be null. When it is not null, connector->display_info and
> > > > connector->eld are updated according to the edid. When edid=NULL, only
> > > > connector->eld is reset. Reset connector->display_info to be consistent
> > > > and accurate.
> > > > 
> > > > Signed-off-by: Claudio Suarez <cssk@net-c.es>
> > > > ---
> > > >  drivers/gpu/drm/drm_edid.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 6325877c5fd6..6cbe09b2357c 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -5358,10 +5358,12 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> > > >  
> > > >  	if (edid == NULL) {
> > > >  		clear_eld(connector);
> > > > +		drm_reset_display_info(connector);
> > > >  		return 0;
> > > >  	}
> > > >  	if (!drm_edid_is_valid(edid)) {
> > > >  		clear_eld(connector);
> > > > +		drm_reset_display_info(connector);
> > > 
> > > Looks easier if you pull both of those out from these branches and
> > > just call them unconditionally at the start.
> > 
> > After looking at the full code, I am not sure. This is the code:
> > ==================
> > int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> > {
> >         int num_modes = 0;
> >         u32 quirks;
> > 
> >         if (edid == NULL) {
> >                 clear_eld(connector);
> >                 drm_reset_display_info(connector); <--- added by me
> >                 return 0;
> >         }
> >         if (!drm_edid_is_valid(edid)) {
> >                 clear_eld(connector);
> >                 drm_reset_display_info(connector); <--- added by me
> >                 drm_warn(connector->dev, "%s: EDID invalid.\n",
> >                          connector->name);
> >                 return 0;
> >         }
> > 
> >         drm_edid_to_eld(connector, edid);
> > 
> >         quirks = drm_add_display_info(connector, edid);
> > 	etc...
> > =================
> > 
> > If we move those out of these branches and edid != NULL, we are executing an
> > unnecessary clear_eld(connector) and an unnecessary drm_reset_display_info(connector)
> > because the fields will be set in the next drm_edid_to_eld(connector, edid) and
> > drm_add_display_info(connector, edid)
> > 
> > Do we want this ?
> 
> Seems fine by me. And maybe we could nuke the second
> drm_reset_display_info() from deeper inside drm_add_display_info()?
> Not sure if drm_add_display_info() still has to be able to operate
> standalone or not.
> 
> Hmm. Another option is to just move all these NULL/invalid edid
> checks into drm_edid_to_eld() and drm_add_display_info().

But maybe that's not so easy. Would still need to bail out
from drm_add_edid_modes() I guess.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2021-10-15 19:47 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 11:36 [PATCH 00/15] replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi Claudio Suarez
2021-10-15 11:36 ` [Nouveau] " Claudio Suarez
2021-10-15 11:36 ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:36 ` [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info Claudio Suarez
2021-10-15 11:36   ` [Nouveau] " Claudio Suarez
2021-10-15 11:36   ` [Intel-gfx] " Claudio Suarez
2021-10-15 12:03   ` Ville Syrjälä
2021-10-15 12:03     ` [Intel-gfx] " Ville Syrjälä
2021-10-15 12:03     ` [Nouveau] " Ville Syrjälä
2021-10-15 19:24     ` Claudio Suarez
2021-10-15 19:24       ` [Intel-gfx] " Claudio Suarez
2021-10-15 19:24       ` [Nouveau] " Claudio Suarez
2021-10-15 19:33       ` Ville Syrjälä
2021-10-15 19:33         ` [Intel-gfx] " Ville Syrjälä
2021-10-15 19:33         ` [Nouveau] " Ville Syrjälä
2021-10-15 19:46         ` Ville Syrjälä [this message]
2021-10-15 19:46           ` [Nouveau] [Intel-gfx] " Ville Syrjälä
2021-10-16  8:25         ` [Freedreno] " Claudio Suarez
2021-10-16  8:25           ` [Intel-gfx] " Claudio Suarez
2021-10-16  8:25           ` [Nouveau] " Claudio Suarez
2021-10-16  8:58           ` Claudio Suarez
2021-10-16  8:58             ` [Intel-gfx] " Claudio Suarez
2021-10-16  8:58             ` [Nouveau] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 02/15] drm/amdgpu: use drm_* functions instead of duplicated code in amdgpu driver Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 15:14   ` Harry Wentland
2021-10-15 15:14     ` [Intel-gfx] " Harry Wentland
2021-10-15 15:14     ` [Nouveau] " Harry Wentland
2021-10-16 10:15     ` Claudio Suarez
2021-10-16 10:15       ` [Intel-gfx] " Claudio Suarez
2021-10-16 10:15       ` [Nouveau] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 03/15] drm/vc4: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 04/15] drm/radeon: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 05/15] drm/tegra: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 06/15] drm/gma500: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 07/15] drm/exynos: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 08/15] drm/msm: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 09/15] drm/sun4i: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 10/15] drm/sti: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 11/15] drm/zte: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 12/15] drm/rockchip: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 13/15] drm/bridge: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 14/15] drm/nouveau: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 11:37 ` [PATCH 15/15] drm/i915: " Claudio Suarez
2021-10-15 11:37   ` [Nouveau] " Claudio Suarez
2021-10-15 11:37   ` [Intel-gfx] " Claudio Suarez
2021-10-15 12:30   ` [Nouveau] " Ville Syrjälä
2021-10-15 12:30     ` Ville Syrjälä
2021-10-15 18:18     ` Claudio Suarez
2021-10-15 18:18       ` [Nouveau] " Claudio Suarez
2021-10-15 12:44   ` Jani Nikula
2021-10-15 12:44     ` [Intel-gfx] " Jani Nikula
2021-10-15 12:44     ` [Nouveau] " Jani Nikula
2021-10-15 12:58     ` [Intel-gfx] " Ville Syrjälä
2021-10-15 12:58       ` [Nouveau] " Ville Syrjälä
2021-10-15 15:18       ` Jani Nikula
2021-10-15 15:18         ` [Nouveau] " Jani Nikula
2021-10-15 18:44         ` Claudio Suarez
2021-10-15 18:44           ` [Nouveau] " Claudio Suarez
2021-10-15 14:24 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork

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=YWnas70UYAdjZFKo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.