[Intel-gfx] [PATCH] Lower threshold for pixel doubling.

[Stuart Abercrombie]

Is there some reason why this is a difficult change to evaluate?


On Mon, Jul 8, 2013 at 11:52 AM, Stuart Abercrombie <sabercrombie at google.com
> wrote:

> So, what's the conclusion?
>
>
> On Mon, Jun 24, 2013 at 4:28 PM, Stuart Abercrombie <
> sabercrombie at google.com> wrote:
>
>> This is with the patch.
>>
>>
>> On Sun, Jun 23, 2013 at 11:59 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>>
>>> On Sat, Jun 22, 2013 at 12:52 AM, Stuart Abercrombie
>>> <sabercrombie at google.com> wrote:
>>> > Maybe I missed something, but I didn't see a response to this.  Can we
>>> get
>>> > this fix in?
>>>
>>> Sorry for the delay, I've lost track of this. Can you please boot with
>>> drm.debug=0xe and attach the full dmesg (with or without your patch)?
>>> -Daniel
>>>
>>> >
>>> >
>>> > On Wed, May 29, 2013 at 9:22 AM, Stuart Abercrombie
>>> > <sabercrombie at google.com> wrote:
>>> >>
>>> >> Without this change I saw PIPE_FIFO_UNDERRUN_STATUS set in PIPEASTAT,
>>> >> which I took to indicate an underrun problem.
>>> >>
>>> >> Here's what I found with other modes on this monitor:
>>> >>
>>> >> 1920x1200 works with pixel doubling enabled. Pixel clock 193.2 MHz.
>>> >> 2048x1152 works with pixel doubling enabled. Pixel clock 198.0 MHz.
>>> >> 1600x1200 works with pixel doubling disabled. Pixel clock 162.0 MHz.
>>> >> 2048x1280 fails with pixel doubling disabled. PIxel clock 174.2 MHz..
>>> >>
>>> >> Based on this, it seems the threshold needs to be be between 162.0MHz
>>> and
>>> >> 174.2MHz, whereas currently it's at 180MHz.  The change puts it at
>>> 170MHz.
>>> >>
>>> >> Stuart
>>> >>
>>> >>
>>> >> On Wed, May 29, 2013 at 8:22 AM, Daniel Vetter <daniel at ffwll.ch>
>>> wrote:
>>> >>>
>>> >>> On Tue, May 28, 2013 at 10:39:07AM -0700, Stuart Abercrombie wrote:
>>> >>> > Any comments?
>>> >>> >
>>> >>> > Without this, plugging one of the older Chromebook models into a
>>> Dell
>>> >>> > U3011
>>> >>> > monitor produces a garbled display at the default 2048x1280
>>> resolution.
>>> >>> >
>>> >>> > The original threshold was apparently fairly arbitrary:
>>> >>> >
>>> >>> >
>>> >>> >
>>> http://cgit.freedesktop.org/~anholt/xf86-video-intel/commit/?id=8fcf9a81179ee8577ddab5e904c58fbfd14cf59c
>>> >>>
>>> >>> Do you see any pipe underruns without this patch? There are some
>>> not-yet
>>> >>> implemented tricks we should be pulling around re-splitting DSP_ARB
>>> fifo
>>> >>> entries, which tend to totally kill high-res modes.
>>> >>> -Daniel
>>> >>>
>>> >>> > .
>>> >>> >
>>> >>> > Stuart
>>> >>> >
>>> >>> >
>>> >>> > On Mon, May 20, 2013 at 11:15 AM, Stuart Abercrombie <
>>> >>> > sabercrombie at chromium.org> wrote:
>>> >>> >
>>> >>> > > 90% of core speed (=180MHz dot clock) is too high for 2048x1280
>>> to
>>> >>> > > get
>>> >>> > > pixel doubling on Pineview, which it needs to avoid underruns, so
>>> >>> > > lower this to 85%.
>>> >>> > >
>>> >>> > > Signed-off-by: Stuart Abercrombie <sabercrombie at chromium.org>
>>> >>> > > ---
>>> >>> > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>>> >>> > >  1 file changed, 2 insertions(+), 2 deletions(-)
>>> >>> > >
>>> >>> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> >>> > > b/drivers/gpu/drm/i915/intel_display.c
>>> >>> > > index efe8299..9c924e9 100644
>>> >>> > > --- a/drivers/gpu/drm/i915/intel_display.c
>>> >>> > > +++ b/drivers/gpu/drm/i915/intel_display.c
>>> >>> > > @@ -4564,14 +4564,14 @@ static void i9xx_set_pipeconf(struct
>>> >>> > > intel_crtc
>>> >>> > > *intel_crtc)
>>> >>> > >         pipeconf = I915_READ(PIPECONF(intel_crtc->pipe));
>>> >>> > >
>>> >>> > >         if (intel_crtc->pipe == 0 && INTEL_INFO(dev)->gen < 4) {
>>> >>> > > -               /* Enable pixel doubling when the dot clock is >
>>> 90%
>>> >>> > > of
>>> >>> > > the (display)
>>> >>> > > +               /* Enable pixel doubling when the dot clock is >
>>> 85%
>>> >>> > > of
>>> >>> > > the (display)
>>> >>> > >                  * core speed.
>>> >>> > >                  *
>>> >>> > >                  * XXX: No double-wide on 915GM pipe B. Is that
>>> the
>>> >>> > > only
>>> >>> > > reason for the
>>> >>> > >                  * pipe == 0 check?
>>> >>> > >                  */
>>> >>> > >                 if (intel_crtc->config.requested_mode.clock >
>>> >>> > > -
>>> dev_priv->display.get_display_clock_speed(dev) *
>>> >>> > > 9 /
>>> >>> > > 10)
>>> >>> > > +
>>> dev_priv->display.get_display_clock_speed(dev) *
>>> >>> > > 17 /
>>> >>> > > 20)
>>> >>> > >                         pipeconf |= PIPECONF_DOUBLE_WIDE;
>>> >>> > >                 else
>>> >>> > >                         pipeconf &= ~PIPECONF_DOUBLE_WIDE;
>>> >>> > > --
>>> >>> > > 1.8.2.1
>>> >>> > >
>>> >>> > >
>>> >>>
>>> >>> > _______________________________________________
>>> >>> > Intel-gfx mailing list
>>> >>> > Intel-gfx at lists.freedesktop.org
>>> >>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Daniel Vetter
>>> >>> Software Engineer, Intel Corporation
>>> >>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20130712/62f29634/attachment.html>