[Intel-gfx] Fujitsu S6010 still woes (partially)

[Thomas Richter]

Am 08.04.2014 13:37, schrieb Ville Syrjälä:
> On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote:
>
> 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.

I know.... )-:

> 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.

Something strange must happen on panning, probably because the chip has 
to pre-fetch some memory because the display is no longer properly 
aligned to cache lines. If there's not enough headroom in its input 
buffer, it seems to "hick up".

> 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.

IIRC, 6 also works as "high-mark", but 8 is on the safe side. Anyhow, it 
corrects the issue reliably and it is easy to add, just another field in 
the watermark setting.

>> 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.

Strange. Actually, I just removed it, and the system worked just fine. 
Of course I do not know the i830 as good as you do, but what happens if 
pipe A is disabled and pipe B isn't?

> 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.

Ok.

> 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.

I'm not so sure on this one, I rather believe it is an issue with the 
order of operations. Trouble is that during resume from suspend I 
*believe* the logic currently first tries to find the DVO, then fails 
because the pipe isn't configured. It is part of a chicken and egg 
problem. Unfortunately, I cannot follow exactly how the resume triggers 
the functions in the i915 modeset. If there's anything where I could 
help, please let me know.

> 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.

The R31 does not have the issues of the S6010, though, but it's a 
different display connection in first place (no ns2501 in the system). 
IIRC, but I can check in a minute, suspend from disk works on the 
system, suspend from RAM does not, but I'm not as sure as for the S6010 
that it is really the i915 code that has an issue. For the S6010, 
everything *except* i915 resumes just fine from the suspend.

> 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.

That's probably called for, yes. From the values written into the DVO, 
one can *almost* guess what they should be (hblank/vblank timing), and 
the current hard setting to disable the scaling for 1024x768 is probably 
also not ideal. Back then, I took this from the video bios.

Greetings,
	Thomas