Re: More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter <daniel@ffwll.ch>]

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

> Last, a question: All I can get with the current intel driver is a
> "shared display" between the internal and external
> display. Is there any way (through xrandr) to get two different
> configurations such that the external monitor is
> using one configuration feed through pipe A, and the internal
> display is feed through pipe B with another configuration?

--above/below should achieve that, presuming there's not a different bug
somewhere that prevents this from working correctly.

> And finally: As the internal display is only a 6 bit display, is
> there a way to enable dithering on the 835GM to avoid the banding
> artifacts?

Iirc we always send 8bit data over the dvo bus, so any dithering should be
done in the dvo encoder. The built-in lvds encoder on i855gm and later has
it's own dithering settting, and otherwise I'm not aware of any that would
apply to gen2 graphics.

Also: If you're running sna, have you checked that you indeed run X at
32bit depth? The default since a while is 15 bits.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch