Re: Fujitsu S6010 still woes (partially)

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote:
> Hi Daniel, dear intel-experts,
> 
> again I had the chance to test the latest intel-drm-nightly of the
> 3.14.0 kernel on the Siemens S6010 with its dreadful nso2501 DVO.
> Unfortunately, there are still a couple of issues here, and I also want
> to report on some progress and some workarounds.
> 
> 1) Panning on the i830 still flickers, reproducible both on the Fujitsu
> S6010 and the IBM R31. The problem is all again the same, namely that
> the watermark is set too low (or too high, if you like). The
> intel_calculate_wm() function in intel_pm.c returns a watermark level of
> 0 for the nominal display configuration (1024x768), which is just too
> high. The maximum allowable watermark should be 8. I already submitted a
> patch for this problem, though unfortunately, it had not been accepted.
> Folks, could we *please* fix this issue? It is really trivial, and it
> really causes crashes if a video overlay is on the panning screen -
> thus, this is more than just a cosmetic fix.

I saw the watermark issue on my S6010 too. I have no good explanation
for it since low value in the register means the watermark is actually
high. So it's a mystery why setting the watermark too high can cause
problems. On 85x it works just fine, but then again a lot of stuff
that's questionable in 830 seems to be fixed in 85x.

I was thinking it might be some burst size thing, but the magic threshold
doesn't correspond to any burst size that I'm aware of.  Also IIRC the
magic number isn't exactly 8 always, sometimes lower values work too. I
tried to stare at this issue a bit at some point but couldn't discern any
sensible pattern in which values worked and which didn't.

> 2) Pipe_A quirk: Actually, this is not required or needed on the S6010
> nor on the R31. In fact, it breaks more than it fixes. The problem is
> that the pipe A quirk causes the boot console to be misaligned with the
> screen, or to be completely blank. This is undesirable if you boot into
> maintenance mode (i.e. without an X interface). Just disabling the quirk
> avoids this problem in a wonderful way.

Well I think the quirk is needed, but it's implemented poorly. I think
what we need to do is actually keep both pipes on whenever at least
one pipe needs to be enabled. My idea for doing this in a reasonably
clean way is to add fake connectors/encoders that are invisible to
userspace, and use them with the atomic modeset support to fire up both
pipes whenever either pipe needs to be on. But obviously this needs to
wait until we get the atomic modeset stuff done.

We also fail to configure the DVO 2x clock bit correctly. I think
that bit needs to be enabled for both DPLLs whenever it's needed by
either pipe. Before we get the atomic modeset stuff done, it might be
enough to just always set the bit in both DPLLs regardless of the
output type.

Oh and I think we're currently using the wrong DVO port for ns2501,
on s6010 at least. It might explain some of your issues. I had a
patch for that sitting somewhere but I gues I never posted it. I'm
not sure if the R31 uses the same port or not.

I also had a slight rewrite of the ns2501 code in the works, but I
need to find a weekend when I'm a bit bored to finish that off.

<snip the rest>

-- 
Ville Syrjälä
Intel OTC