All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Thomas Richter <thor@math.tu-berlin.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: Bug/Patch : resolved i830 black screen
Date: Tue, 7 Jan 2014 15:53:12 +0200	[thread overview]
Message-ID: <20140107135312.GB4800@intel.com> (raw)
In-Reply-To: <52C9D322.7020304@math.tu-berlin.de>

On Sun, Jan 05, 2014 at 10:48:18PM +0100, Thomas Richter wrote:
> Dear intel-experts,
> 
> a while ago I reported that the latest kernel from intel-drm-nightly 
> broke operations on i830 completely. In the meantime,
> I found the reason. The trouble is in intel_crtcl_init():
> 
> static void intel_crtc_init(struct drm_device *dev, int pipe)
> {
> 
>      ....
> 
>      /*
>       * On gen2/3 only plane A can do fbc, but the panel fitter and lvds 
> port
>       * is hooked to plane B. Hence we want plane A feeding pipe B.
>       */
>      intel_crtc->pipe = pipe;
>      intel_crtc->plane = pipe;
>      if (IS_MOBILE(dev) && IS_GEN3(dev)) {
>          DRM_DEBUG_KMS("swapping pipes & planes for FBC\n");
>          intel_crtc->plane = !pipe;
>      }
> 
> The new code has here the condition "IS_MOBILE(dev) && 
> INTEL_INFO(dev)->gen < 4", which however, gives a nonworking
> display on my Fujitsu-Siemens. Apparently, this swap is not correct. It 
> might do the right thing on gen3 (I do not have a
> gen3-based system so I cannot verify), but it does not work on GEN2. The 
> check (as above) conditioned on IS_GEN3() only
> restores a working display on this system.

I got my hands on a 830M laptop as well and found the same thing. The
real issue seems to be that that pipe B must be also be enabled when
moving plane B from pipe B to A, even if the plane is already disabled.
As a quick fix I have a patch to limit the plane swapping to FBC
capabable platforms (which 830M is not). I'll post that ASAP.

> 
> Two additional observations:
> 
> 1) Panning did not work on i830 due to an incorrect watermark setting. 
> The watermark register must be at least 6 *on this specific machine*. On 
> the R31, it had to be at least four.

I noticed we're slightly miscalculating the plane A FIFO size, but I'm
not sure that can explain the panning issues. I'll have to test it on
my 830M machine at some point.

> 
> 2) I do not seem to need the PIPE_A workaround on this Fujitsu laptop. 
> It also boots with disabling the quirk. I have not tested suspend to 
> ram, but it did not work before, and it likely does not work now. 
> Probably the pipe A quirk is only required for suspend to ram?

Acocrding to folk lore DPLL B is somehow slaved to DPLL A, so if you
want to use pipe B you need DPLL A still running. I've not found any
note about this in the docs though. There are a few other DPLL related
problems noted in the docs however, and I'm not sure we handle all of
them properly.

> 
> Even without the pipe A quirk, the bios seems to keep pipe A busy. At 
> least this is what I get from xrandr:
> 
> Screen 0: minimum 320 x 200, current 2048 x 1536, maximum 2048 x 2048
> VGA1 unknown connection (normal left inverted right x axis y axis)
>     1360x768       59.8
>     1152x864       60.0
>     1024x768       60.0
>     800x600        60.3
>     640x480        59.9
> DVI1 connected 2048x1536+0+0 (normal left inverted right x axis y axis) 
> 0mm x 0mm panning 2048x1536+0+0
>     1024x768       60.0*
>     800x600        60.3     56.2
>     640x480        59.9
> 
> Greetings and Happy New Year,
> 
> Thomas
> 
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

      reply	other threads:[~2014-01-07 13:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-05 21:48 Bug/Patch : resolved i830 black screen Thomas Richter
2014-01-07 13:53 ` Ville Syrjälä [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140107135312.GB4800@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=thor@math.tu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.