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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
