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

[Chris Wilson]

On Tue, Jun 23, 2015 at 11:18:05PM +0200, Daniel Vetter wrote:
> 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?

Given that it has been buggy forever, and removes some interloping code,
ack.

I'm just disappointed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre