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

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Tue, Aug 06, 2019 at 03:02:31PM +0300, Jani Nikula wrote:
> On Thu, 18 Jul 2019, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> > 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?
> 
> Let's say we only supported user specified display disable via:
> 
> # modprobe i915
> # modprobe -r i915
> # modprobe i915 disable_display=1
> 
> i.e. by having i915 take over and disable everything first. Would that
> be enough?
> 
> Alternatively, could we do display disable by first probing almost
> everything as we would with disable_display=0, then throwing
> -EPROBE_DEFER and having the error handling code clean up the hardware
> after us. The subsequent probe retry would then proceed assuming no
> display hardware.
> 
> Thoughts?

It makes sense for me. Would we need to detach disable_display from
num_pipes for that?

Anyways, taking another quick look to the only case we modify num_pipes
out of platform definition I don't see now how it would suddenly
become 0:

 if (enabled_mask == 0
 ...
                else
                        info->num_pipes = hweight8(enabled_mask);

so maybe just go with my previous version is safe after all?!

But indeed making it more solid is a good plan.

> 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx