<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 25, 2015 at 4:58 AM Jani Nikula <<a href="mailto:jani.nikula@linux.intel.com">jani.nikula@linux.intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 18 Jun 2015, Jani Nikula <<a href="mailto:jani.nikula@linux.intel.com" target="_blank">jani.nikula@linux.intel.com</a>> wrote:<br>
> On Thu, 18 Jun 2015, Jani Nikula <<a href="mailto:jani.nikula@linux.intel.com" target="_blank">jani.nikula@linux.intel.com</a>> wrote:<br>
>> On Thu, 18 Jun 2015, Ander Conselvan De Oliveira <<a href="mailto:conselvan2@gmail.com" target="_blank">conselvan2@gmail.com</a>> wrote:<br>
>>> On Fri, 2015-06-05 at 12:11 +0300, Ville Syrjälä wrote:<br>
>>>> On Fri, Jun 05, 2015 at 11:51:42AM +0300, Jani Nikula wrote:<br>
>>>> > On Thu, 04 Jun 2015, Rodrigo Vivi <<a href="mailto:rodrigo.vivi@gmail.com" target="_blank">rodrigo.vivi@gmail.com</a>> wrote:<br>
>>>> > > I just noticed that I had forgotten to reply-all...<br>
>>>> > ><br>
>>>> > > Jani, would you consider merge this fix with the explanation above<br>
>>>> > > related to Ville's question?<br>
>>>> > ><br>
>>>> > > or do you want/need any action here?<br>
>>>> ><br>
>>>> > Ville's question, I'd like Ville's ack on it.<br>
>>>><br>
>>>> It's good enough for me. This part of the driver is a quite a mess<br>
>>>> anyway currently, so doesn't matter too much what we stick in there.<br>
>>><br>
>>> Ping. Seems like this still isn't merged. Does it need more work or did<br>
>>> it just fall through the cracks?<br>
>><br>
>> It fell between the cracks. I know the world isn't black and white, but<br>
>> it doesn't help the maintainers when review is some shade of grey.<br>
>><br>
>> I've pushed this to drm-intel-next-fixes for now, but it has missed the<br>
>> train for both the v4.1 release and the main drm-next feature pull<br>
>> request for the v4.2 merge window. I expect this to land upstream in<br>
>> v4.2-rc2, unless there's an additional drm-next pull request during the<br>
>> merge window. I've added cc: stable.<br>
>><br>
>> Thanks for the patch, and I guess the review was, uh, "good enough for<br>
>> me" now... :p<br>
><br>
> Argh, I'll take that back. This conflicts with dinq, and while doing so<br>
> also confuses git rerere enough to uncover a previous much bigger<br>
> conflict that I have no intention of resolving again before the<br>
> weekend. I'll return to it next week. Sorry.<br>
<br>
And keeps conflicting too badly for me to figure out what needs to be<br>
done. Is this still needed in dinq?<br></blockquote><div><br></div><div>To be honest, on drm-intel-nightly: 2015y-06m-17d-12h-44m-01s</div><div>with ips enabled I'm not facing the bad flicker anymore.</div><div><br></div><div>However since we still have the following 2 lines on update_primary_plane_function:</div><div><br></div><div>if (!visible || !fb) {</div><div><span class="Apple-tab-span" style="white-space:pre">             </span>I915_WRITE(reg, 0);</div><div><br></div><div>I believe we need this protection. Let me refactor it..</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
BR,<br>
Jani.<br>
<br>
<br>
><br>
> BR,<br>
> Jani.<br>
><br>
><br>
><br>
>><br>
>> BR,<br>
>> Jani.<br>
>><br>
>><br>
>>><br>
>>> Thanks,<br>
>>> Ander<br>
>>><br>
>>>><br>
>>>> ><br>
>>>> > BR,<br>
>>>> > Jani.<br>
>>>> ><br>
>>>> ><br>
>>>> > ><br>
>>>> > > Thanks,<br>
>>>> > > Rodrigo.<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > ---------- Forwarded message ----------<br>
>>>> > > From: Rodrigo Vivi <<a href="mailto:rodrigo.vivi@gmail.com" target="_blank">rodrigo.vivi@gmail.com</a>><br>
>>>> > > Date: Fri, May 29, 2015 at 9:45 AM<br>
>>>> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix IPS related flicker<br>
>>>> > > To: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > On Fri, May 29, 2015 at 1:47 AM, Ville Syrjälä<br>
>>>> > > <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>> wrote:<br>
>>>> > >> On Thu, May 28, 2015 at 11:07:11AM -0700, Rodrigo Vivi wrote:<br>
>>>> > >>> We cannot let IPS enabled with no plane on the pipe:<br>
>>>> > >>><br>
>>>> > >>> BSpec: "IPS cannot be enabled until after at least one plane has<br>
>>>> > >>> been enabled for at least one vertical blank." and "IPS must be<br>
>>>> > >>> disabled while there is still at least one plane enabled on the<br>
>>>> > >>> same pipe as IPS." This restriction apply to HSW and BDW.<br>
>>>> > >>><br>
>>>> > >>> However a shortcut path on update primary plane function<br>
>>>> > >>> to make primary plane invisible by setting DSPCTRL to 0<br>
>>>> > >>> was leting IPS enabled while there was no<br>
>>>> > >>> other plane enabled on the pipe causing flickerings that we were<br>
>>>> > >>> believing that it was caused by that other restriction where<br>
>>>> > >>> ips cannot be used when pixel rate is greater than 95% of cdclok.<br>
>>>> > >>><br>
>>>> > >>> v2: Don't mess with Atomic path as pointed out by Ville.<br>
>>>> > >>><br>
>>>> > >>> Reference: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=85583" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=85583</a><br>
>>>> > >>> Cc: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>><br>
>>>> > >>> Cc: Paulo Zanoni <<a href="mailto:paulo.r.zanoni@intel.com" target="_blank">paulo.r.zanoni@intel.com</a>><br>
>>>> > >>> Signed-off-by: Rodrigo Vivi <<a href="mailto:rodrigo.vivi@intel.com" target="_blank">rodrigo.vivi@intel.com</a>><br>
>>>> > >>> ---<br>
>>>> > >>>  drivers/gpu/drm/i915/intel_display.c | 13 +++++++++++++<br>
>>>> > >>>  drivers/gpu/drm/i915/intel_drv.h     |  1 +<br>
>>>> > >>>  2 files changed, 14 insertions(+)<br>
>>>> > >>><br>
>>>> > >>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c<br>
>>>> > >>> index 4e3f302..5a6b17b 100644<br>
>>>> > >>> --- a/drivers/gpu/drm/i915/intel_display.c<br>
>>>> > >>> +++ b/drivers/gpu/drm/i915/intel_display.c<br>
>>>> > >>> @@ -13309,6 +13309,16 @@ intel_check_primary_plane(struct drm_plane *plane,<br>
>>>> > >>>                               intel_crtc->atomic.wait_vblank = true;<br>
>>>> > >>>               }<br>
>>>> > >>><br>
>>>> > >>> +             /*<br>
>>>> > >>> +              * FIXME: Actually if we will still have any other plane enabled<br>
>>>> > >>> +              * on the pipe we could let IPS enabled still, but for<br>
>>>> > >>> +              * now lets consider that when we make primary invisible<br>
>>>> > >>> +              * by setting DSPCNTR to 0 on update_primary_plane function<br>
>>>> > >>> +              * IPS needs to be disable.<br>
>>>> > >>> +              */<br>
>>>> > >>> +             if (!state->visible || !fb)<br>
>>>> > >>> +                     intel_crtc->atomic.disable_ips = true;<br>
>>>> > >>> +<br>
>>>> > >><br>
>>>> > >> How could it be visible without an fb?<br>
>>>> > ><br>
>>>> > > I don't like this !fb here as well, but I just tried to keep exactly<br>
>>>> > > same if statement that makes I915_WRITE(DSPCNTRL, 0) on update primary<br>
>>>> > > plane func...<br>
>>>> > ><br>
>>>> > >><br>
>>>> > >>>               intel_crtc->atomic.fb_bits |=<br>
>>>> > >>>                       INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);<br>
>>>> > >>><br>
>>>> > >>> @@ -13406,6 +13416,9 @@ static void intel_begin_crtc_commit(struct drm_crtc *crtc)<br>
>>>> > >>>       if (intel_crtc->atomic.disable_fbc)<br>
>>>> > >>>               intel_fbc_disable(dev);<br>
>>>> > >>><br>
>>>> > >>> +     if (intel_crtc->atomic.disable_ips)<br>
>>>> > >>> +             hsw_disable_ips(intel_crtc);<br>
>>>> > >>> +<br>
>>>> > >>>       if (intel_crtc->atomic.pre_disable_primary)<br>
>>>> > >>>               intel_pre_disable_primary(crtc);<br>
>>>> > >><br>
>>>> > >> intel_pre_disable_primary() would already disable IPS. Except no one<br>
>>>> > >> sets .pre_disable_primary=true. OTOH that thing mostly seems to do<br>
>>>> > >> stuff that has nothing to do with the primary plane (cxsr disable,<br>
>>>> > >> fifo underrun reporting disable on gen2), so I don't think we want<br>
>>>> > >> to use that.<br>
>>>> > >><br>
>>>> > >> In any case we should really have the IPS state as part of the crtc<br>
>>>> > >> state. These global disable_foo things should just be killed IMO.<br>
>>>> > >> Hmm, except to do this properly we'd then need to track the hw IPS<br>
>>>> > >> state separately somewhere.<br>
>>>> > ><br>
>>>> > > agree.<br>
>>>> > ><br>
>>>> > >><br>
>>>> > >> I guess we can just go with this for now. At least it's not really<br>
>>>> > >> making things worse, so (maybe with the !fb check dropped):<br>
>>>> > >> Reviewed-by: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>><br>
>>>> > ><br>
>>>> > > Thanks<br>
>>>> > ><br>
>>>> > >><br>
>>>> > >>><br>
>>>> > >>> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h<br>
>>>> > >>> index 2afb31a..1059283 100644<br>
>>>> > >>> --- a/drivers/gpu/drm/i915/intel_drv.h<br>
>>>> > >>> +++ b/drivers/gpu/drm/i915/intel_drv.h<br>
>>>> > >>> @@ -485,6 +485,7 @@ struct intel_crtc_atomic_commit {<br>
>>>> > >>>       /* Sleepable operations to perform before commit */<br>
>>>> > >>>       bool wait_for_flips;<br>
>>>> > >>>       bool disable_fbc;<br>
>>>> > >>> +     bool disable_ips;<br>
>>>> > >>>       bool pre_disable_primary;<br>
>>>> > >>>       bool update_wm;<br>
>>>> > >>>       unsigned disabled_planes;<br>
>>>> > >>> --<br>
>>>> > >>> 2.1.0<br>
>>>> > >><br>
>>>> > >> --<br>
>>>> > >> Ville Syrjälä<br>
>>>> > >> Intel OTC<br>
>>>> > >> _______________________________________________<br>
>>>> > >> Intel-gfx mailing list<br>
>>>> > >> <a href="mailto:Intel-gfx@lists.freedesktop.org" target="_blank">Intel-gfx@lists.freedesktop.org</a><br>
>>>> > >> <a href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a><br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > --<br>
>>>> > > Rodrigo Vivi<br>
>>>> > > Blog: <a href="http://blog.vivi.eng.br" rel="noreferrer" target="_blank">http://blog.vivi.eng.br</a><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > --<br>
>>>> > > Rodrigo Vivi<br>
>>>> > > Blog: <a href="http://blog.vivi.eng.br" rel="noreferrer" target="_blank">http://blog.vivi.eng.br</a><br>
>>>> ><br>
>>>> > --<br>
>>>> > Jani Nikula, Intel Open Source Technology Center<br>
>>>> > _______________________________________________<br>
>>>> > Intel-gfx mailing list<br>
>>>> > <a href="mailto:Intel-gfx@lists.freedesktop.org" target="_blank">Intel-gfx@lists.freedesktop.org</a><br>
>>>> > <a href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a><br>
>>>><br>
>>><br>
>>><br>
>><br>
>> --<br>
>> Jani Nikula, Intel Open Source Technology Center<br>
><br>
> --<br>
> Jani Nikula, Intel Open Source Technology Center<br>
<br>
--<br>
Jani Nikula, Intel Open Source Technology Center<br>
_______________________________________________<br>
Intel-gfx mailing list<br>
<a href="mailto:Intel-gfx@lists.freedesktop.org" target="_blank">Intel-gfx@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a><br>
</blockquote></div></div>