On Tue, Jun 25, 2013 at 1:28 AM, Stuart Abercrombie <sabercrombie@xxxxxxxxxx> wrote: > This is with the patch. Hm, nothing really interesting bug I've finally gotten around to some doc reading and they seem to insist pretty hard that double wide mode on pipe A only works if we have pipe A linked up with cursor/plane A. But on gen3 mobile we switch pipes&planes and Stéphane said on irc that you've changed the logic in there a bit. Can you please check whether you're still using plane B for pipe A or if there's something broken? -Daniel > > > On Sun, Jun 23, 2013 at 11:59 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> >> On Sat, Jun 22, 2013 at 12:52 AM, Stuart Abercrombie >> <sabercrombie@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> >> >>> > > --- >> >>> > > 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@xxxxxxxxxxxxxxxxxxxxx >> >>> > 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 > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
