Hi
Am 04.10.24 um 13:19 schrieb Ville Syrjälä:
On Fri, Oct 04, 2024 at 01:03:21PM +0200, Thomas Zimmermann wrote:
Hi
thanks for your help.
Am 04.10.24 um 12:01 schrieb Ville Syrjälä:
On Fri, Oct 04, 2024 at 11:17:02AM +0200, Thomas Zimmermann wrote:
Hi
Am 02.10.24 um 18:15 schrieb Luck, Tony:
Thanks for the bug report. Can you provide the output of 'sudo lspci
-vvv' for the graphics device?
Thomas,
Sure. Here's the output (run on the v6.11.0 kernel)
Thanks. It doesn't look much different from other systems. IRQ is also
assigned.
Attached is a patch that fixes a possible off-by-one error in the
register settings. This would affect the bug you're reporting. If
possible, please apply the patch to your 6.12-rc1, test and report the
result.
Didn't one of these weird variants have some bug where the
CRTC startadd was not working? Is this one of those?
Yeah, but it seems unrelated.
That to me sounds like maybe linecomp has internally been
tied to be always active somehow. Perhaps that would
also prevent it from generating the interrupt...
Linecomp is usually set to vtotal and that disables the irq. When set to
vblank_start/vdisplay_end, it acts like a vblank IRQ. But the other
matrox drivers I saw (fbdev, Xorg-video-matrox) set the value -1, while
mgag200 doesn't. So there really is an off-by-one error.
For the purposes of the interrupt it shouldn't matter
at all what the linecomp value is, as long as it's
between 0 and vtotal. The patch seemed to just care
about vblkstr which doesn't seem relevant to me.
vblkstr is "vblank start" and equal to vdisplay_end. Then linecomp =
vblkstr; happens at some later point in the function.
I've run into several mysterious vblank timeouts while making this
patchset and they all seemed to be related to the exact values in these
registers. So I'm not sure if linecomp really fires an interrupt if it
happens too late after vdisplay_end/vblank_start. The official
documentation is a bit confusing IIRC. So my first step here is to make
mgag200 behave like other existing drivers and see if that fixes the
issue. Hence the off-by-one fix.
Anyways, sounds like someone should just double check whether
the status bit ever get asserted or not. If yes, then the
problem must be with interrupt delivery, otherwise the
problem is that the internal interrupt is never even
generated. In the latter case you could try using the
vsync interrupt instead.
I didn't want to go into full debugging while there's a low-hanging fix
to try first. I'll probably take that patch anyway even if it doesn't
fix the reported bug.
Wrt. vsync: isn't that way to late for vblank events? Does DRM give any
timing guarantees? (It doesn't AFAIK.) Or does it just mean that a
vblank has happened at some point in the past?
It doesn't really matter when the interrupt gets signalled
as long as it's after vblank start. And since the hardware
doesn't even have double buffered register and IIRC doesn't
really care when you reprogram eg. the start address it should
matter even less. Not that it looks like you even try to
do any atomic updates from the vblank handler, so I guess
you just want this for throttling purposes?
I see. VSYNC would likely work for that. Throttling is the main purpose.
Best regards
Thomas
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
