Re: further issues with MGA G200 graphics chipset

[Jocelyn Falempe <jfalempe@redhat.com>]

On 23/04/2026 18:35, Jacob Keller wrote:
 > On 4/23/2026 12:44 AM, Thomas Zimmermann wrote:
 >> Hi
 >>
 >> Am 23.04.26 um 01:55 schrieb Jacob Keller:
 >>> Hello,
 >>><snip>>>> I'm also curious if its possible to stop polling for so 
long with udelay
 >>> in the i2c logic somehow? I am not very familiar with i2c, but it is
 >>> frustrating that this driver is causing yet another stall that is
 >>> impacting timing sensitive data. Even if in this case its due to a
 >>> faulty cable.. it is frustrating that such result causes the PTP
 >>> failures. Would switching to WQ_UNBOUND be helpful here at all?
 >>
 >> Try Dave's suggestion to avoid polling.  The driver won't be able to
 >> detect changes to the connector status, though.
 >>
 >
 > That's fine. I don't think we're even using the device. It looks like it
 > might only be in use for BMC, and the VGA connection isn't actually
 > physically available, so there are no changes to detect.
 >
 > Is this polling really only to detect when VGA is enabled? Would it make
 > sense to only poll on platforms which actually *have* that VGA 
connection?
 >
Polling was introduced with https://patchwork.freedesktop.org/series/131977/

The driver needs to know if a VGA monitor is connected or not, to 
provide the right available resolutions to the userspace.
Otherwise you can set a high resolution that works from the BMC, but 
then connecting a VGA monitor will not work, as the driver won't notice 
that something has been connected.

The mgag200 doesn't have an IRQ or a register to check if something is 
connected on the VGA port, so the driver uses the i2c and tries to read 
the EDID.

Unfortunately, there is no way to know reliably if a VGA connector is 
present. It's possible to disable polling on some machines using DMI 
quirks, but I don't think this approach will scale.

 >
 > I'd like a solution where we don't have to go to each individual
 > customer and have them ban the mgag200 driver or set some kernel
 > parameter like drm_kms_helper.poll=0 to prevent issues. If the VGA
 > connector isn't even available to *be* plugged in, then it doesn't make
 > sense to constantly poll to check if it was...
 >
 > Many system admins likely aren't even aware of the devices existence,
 > and it ends up causing stall issues like this, which for timing
 > sensitive tasks results in service disruption.
 >
 > It is unpleasant that the mere *existence* of the device+driver causes
 > such problems.
 >
 >> Best regards
 >> Thomas
 >>
 >>>
 >>> Thanks,
 >>> Jake
 >>
 >

Best regards,

-- 

Jocelyn