[Intel-gfx] [PATCH 4/9] drm/i915: Nuke lvds downclock support

[Chris Wilson]

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.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre