[Intel-gfx] More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Sun, Nov 03, 2013 at 06:12:08PM +0100, Daniel Vetter wrote:
> On Sun, Nov 03, 2013 at 05:55:37PM +0100, Thomas Richter wrote:
> > Hi Daniel, dear intel experts,
> > 
> > again trying to get the old Fujitsu laptop to work. The problem with
> > the latest drm-nightly built is that
> > the system again locks up - if the bios is configured to show an
> > image only on the internal display and
> > nothing on the external VGA. If the bios is configured to "shared
> > video", booting works fine.
> > 
> > This seems to be related to the problem that, apparently, the bios
> > seems to prefer to connect the internal
> > display to pipe B and not pipe A, and hence during bootstrap just
> > configuring the dpll for pipe A is not enough.
> > 
> > That being said, the following modifications for ns2501 will fix this:
> > 
> > struct ns2501_priv need to get a new field int pll_b. In
> > enable_dvo(), the setting for the dpll_b needs to be
> > saved, too, and installed, too:
> >     I915_WRITE(_DPLL_A, 0xd0820000);
> >     I915_WRITE(_DPLL_B, 0xd0820000);
> > 
> > It is absolutely unnecessary to overwrite the DVOC register, this is
> > configured fine. In "restore_dvo()", the dpll_b
> > configuration needs to be restored as well. The DVOC register need
> > not to be touched. In fact, the current
> > enable_dvo() has a bug in so far as it saves the wrong register.
> > 
> > However, what is more stunning is how this bug is triggered.
> > Actually, intel_display.c computes the dpll register
> > value correctly (as it seems), but __intel_set_mode() (around line
> > 9356) is a bit strange:
> > 
> > First, it disables the crtcs, then sets the mode, and the enables
> > the crtcs. Unfortunately, this cannot work with
> > with the ns2501 since a disabled PLL will block any communication
> > with with the DVO. I tried to move the "enable"
> > call above the intel_crtc_mode_set(), but this did not work either.
> > I do not know enough about the inner workings
> > of intel_display.c to fix this properly, but the problem seems to be
> > exactly that: An incorrectly configured DPLL
> > disables the communication with the DVO, hence the need for the workaround.
> 
> Have you tried my patch to reorder the dvo sequence a bit? That /should/
> get all these things right:
> 
> http://www.spinics.net/lists/intel-gfx/msg34349.html

There's also a follow-up patch for you to test:

http://www.spinics.net/lists/intel-gfx/msg34350.html

That would prove that the first patch does indeed work. Note that patch 1
in this series is already merged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch