Re: [PATCH 4/9] drm/i915: Nuke lvds downclock support

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 4/9] drm/i915: Nuke lvds downclock support
Date: Tue, 23 Jun 2015 23:18:05 +0200	[thread overview]
Message-ID: <20150623211805.GO25769@phenom.ffwll.local> (raw)
In-Reply-To: <20150618093036.GC24012@nuc-i3427.alporthouse.com>

On Thu, Jun 18, 2015 at 10:30:36AM +0100, Chris Wilson wrote:
> On Thu, Jun 18, 2015 at 11:23:17AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 18, 2015 at 10:00:51AM +0100, Chris Wilson wrote:
> > > On Thu, Jun 18, 2015 at 10:30:23AM +0200, Daniel Vetter wrote:
> > > > With the new DRRS code it kinda sticks out, and we never managed to
> > > > get this to work well enough without causing issues. Time to wave
> > > > goodbye.
> > > > 
> > > > I've decided to keep the logic for programming the reduced clocks
> > > > intact, but everything else is gone. If anyone ever wants to resurrect
> > > > this we need to redo it all anyway on top of the frontbuffer tracking.
> > > 
> > > Can you nuke just the intel_mark_busy side? Keeping the mode finder
> > > intact would be useful as the intrepid reader need only then implement
> > > the intel_frontbuffer callbacks and have the harder part of matching
> > > appropriate modes and switching routines ready to plug in. (Those latter
> > > ones I expect to be tweaked over time, and so the reader's first step of
> > > reverting this commit would conflict in such a way as to dissuade them.)
> > 
> > Well I was also somewhat annoyed by the dev_priv->lvds_* stuff and figured
> > getting rid of that is good - it really should be stored somewhere in
> > intel_lvds or in the pipe_config. Also given that no one ever really
> > bothered to fix this up since gen5 (where the bit to change frequency
> > moved around iirc) I don't think anyone will ever resurrect this. Hence
> > the much more eager delete.
> 
> *shrug* we know that people do try to use it, I was just thinking of a
> way that we could make it easier for them to refresh the code. (Ideally,
> I would prefer that they wouldn't have to and the new framework provided
> the impetus needed to solidify LVDS reclocking. All that was lacking was
> the vblank task to do the reclocking on the refresh to hide any flicker
> on transition. That and so few manufacturers supplied dual-mode panels.)

Not sure users trying to use it is a good argument - they enthusiastically
try it on gen5+ too (where we don't frob the right pipe bits to make the
frequency switch) and on machines without lvds panels. I expect a dummy
i915.save_me_some_power option would get enabled too ;-)

Btw for the vblank work I think the crucial bit is that we want seamless
DRRS (which edp drrs checks in the vbt) and lvds drrs never did check
that. At least that might explain why it flickered often badly.

Given that ack or nack?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx