[Intel-gfx] [PATCH] drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY

Rodrigo Vivi rodrigo.vivi at intel.com
Thu Jul 18 21:38:11 UTC 2019


On Thu, Jul 18, 2019 at 10:25:51PM +0100, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2019-07-18 22:14:45)
> > On Thu, Jul 18, 2019 at 09:58:16PM +0100, Chris Wilson wrote:
> > > Quoting Rodrigo Vivi (2019-07-18 21:49:12)
> > > > +void intel_display_power_resume_early(struct drm_i915_private *i915)
> > > > +{
> > > > +       if (!HAS_DISPLAY(i915))
> > > > +               return;
> > > > +
> > > > +       if (INTEL_GEN(i915) >= 11 || IS_GEN9_LP(i915)) {
> > > > +               gen9_sanitize_dc_state(i915);
> > > 
> > > Are you sure that whatever state you are resuming from agrees with your
> > > notion of !display? The sanitize routines are supposed to be about
> > > cleaning up after third parties who don't play by the same rules.
> > 
> > I don't expect any function setting any kind of dc states when we don't
> > have display. Besides the path that sets DC_STATE_EN is and neeeds to
> > be sanitized is also covered by this patch and this shouldn't happen.
> > 
> > Or am I missing something else?
> 
> It's not about us, it's about whatever else runs in between. And
> remember !HAS_DISPLAY() is also a user setting, not merely a reflection
> of probed hw.

ouch, we need to get rid of those runtime writes to info struct :/

I wonder if it worth to add a intel_display_sanitize to be called
when toggling info-num_pipes to 0 along with that DRM_ERROR...

or just call it before !HAS_DISPLAY with a XXX comment...

other ideas?

> -Chris


More information about the Intel-gfx mailing list