Re: further issues with MGA G200 graphics chipset

[David Airlie]

On Fri, Apr 24, 2026 at 5:42 AM Jacob Keller <jacob.e.keller@xxxxxxxxx> wrote:
>
> On 4/23/2026 12:22 PM, Jocelyn Falempe wrote:
> > 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.
> >
>
> Timing sensitive setups like mine must have system admins who know to
> manually disable mgag200 or disable polling. Many users won't be aware
> of this. If the polling were not intrusive, this would not be an issue.
> But....
>
> Faulty hardware (perhaps just a cheap pull down resistor on the VGA
> connection as Dave Airlie suggests) means that any such affected
> platform has a polling routine that causes significant issues on any
> timing sensitive applications.

We could write a patch to just say if we see 10 bogus EDID polls we
just give up and loudly say in the logs.

This might break some crash-cart plugins in some data centers though,
I don't think we have contracts in Matrox or the server vendors who
make the hw to say how they recommend finding this info.

It might be in ACPI or dmidecodes.

Dave.


>
> Right now, I am stuck in a situation which means that I have to fight to
> reach every customer who uses one of these platforms and confirm they
> either disable polling or ban the module so it won't even load.
>
> This is frustrating, as it is unlikely I'll reach everyone.
>
> I doubt that I'm the only one with users who are affected by mysterious
> performance or timing problems related to this. While its true that not
> *every* instance of the device is problematic (at least not now that we
> fixed the other issue with the udelay...), but many systems using the
> controller *are* negatively impacted even with the timing fix, as I have
> now seen...
>
> Unfortunately, I also have no better idea than a DMI quirk table to
> record known platforms that include the controller but don't have a
> physical VGA connection exposed.
>
> Thus, I'm wondering what else we can do? Using WQ_UNBOUND might help
> somewhat? I have no idea if its safe to sleep instead of spin while
> reading the i2c connections... As far as I can tell the non-atomic
> version has nothing that *strictly* prevents sleep.. but maybe i2c
> access has tighter timing requirements than what usleep_range can
> fulfill? I am not sure...
>
> I'd just really like to not have to worry about going to every single
> user and asking them to unload and ban a driver for these big server
> platforms...
>