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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
