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

[Ville Syrjälä]

On Tue, Apr 08, 2014 at 02:17:10PM +0200, Thomas Richter wrote:
> 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.

I don't think we need another field anywhere. It's just one platform that
needs special treatment, so I'd rather just add one if statement somewhere
to clamp the computed value.

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

Well the DPLLs are somehow interconnected so it seesm we need to enable
both. And the same holds for the DVO 2x clock enable. Somehow the muxing
of that stuff depends on both DPLLs.

Also I discovered that if a plane is tied to a specific pipe, that pipe
needs to be enabled if we want to do anything to that plane. This holds
even if the plane is disabled. We can't even move the plane to the other
pipe until the current pipe gets enabled. The plane registers simply
refuse to accept new values. IIRC just enabling the DPLL wasn't enough
to fix this. This was the reason for the black screen issue when I
accidentally tried to swap the planes on 830.

So even if having both pipes enabled might not be strictly necessary in
all cases, it would make many things much simpler.

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

It's documented that we need to do this.

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

I took the values from the BIOS as well. IIRC they were a bit different
than the current values in i915. I don't have the real specs for the ns2501
either, so I didn't come up with any way to compute the register values
dynamically. I tried looking for some patterns in the values, but nothing
totally obvious stood out. But I did try to figure out a programming sequence
that matches the emgd blob's behaviour a bit more closely.

The blob seemed to use some hardcoded register values for all modes (it
even enabled the scaler in the native mode). IIRC the emgd values didn't
work as well as the BIOS values though. Presumably something there didn't
quite match the pipe configuration that the VBT provided modes imply.

One remaining issue I had was that the VBT defined two 800x600 modes
with different refresh rates (IIRC 60 and 56). I'm not aware of a way to
tell the BIOS to use the 56Hz mode, so I wasn't able to dump the
corresponding ns2501 register values, which resulted in a garbled display
whenever I tried to use that mode. An easy solution would be to just
filter that mode out.

But as the DPLL stuff and the pipe A quirk were still rather messed up,
I decided to let the matter rest for the time being. I guess I could try
to dig out whatever patches I had there and post them on the list, in
case you want to play with that stuff.

-- 
Ville Syrjälä
Intel OTC