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. > > > > > 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? -- Ville Syrjälä Intel
