Re: further issues with MGA G200 graphics chipset

[Jacob Keller <jacob.e.keller@intel.com>]

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.

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...