[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:58:10 UTC 2021
On Sat, Oct 16, 2021 at 10:25:03AM +0200, Claudio Suarez wrote:
> 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.
I'll send a patch with this idea and we can talk about the new code.
Thanks!
Best regards,
Claudio Suarez.
More information about the dri-devel
mailing list