[Freedreno] [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info

Claudio Suarez cssk at net-c.es
Sat Oct 16 08:25:03 UTC 2021


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 at 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().

I was thinking about this. We can use a boolean variable:
===============
        bool edid_is_invalid;

	edid_is_invalid = !drm_edid_is_valid(edid);

        if (edid == NULL || edid_is_invalid) {
                clear_eld(connector);
                drm_reset_display_info(connector);
                if (edid_is_invalid)
                         drm_warn(connector->dev, "%s: EDID invalid.\n",
                                  connector->name);
                return 0;
        }

        drm_edid_to_eld(connector, edid);
...
===============
Internally, drm_edid_is_valid() handles NULL pointers properly.
It is a quite elegant solution with a small change in the original
design, and it improves this part in the way you pointed out.

Best regards,
Claudio Suarez





More information about the amd-gfx mailing list