[PATCH v5 0/7] drm/mgag200: Implement VBLANK support

[Thomas Zimmermann]

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)