From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CDC622165EA for ; Thu, 23 Apr 2026 19:22:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776972178; cv=none; b=H45g2afasy1XXe50NPkhpvM/AG88+YLGsy1ZvDfb8h3hIMtF4uiJ9qeOvQp5K4ZwBpI3pWIdsdJG/s9ELRwl1c+DpaHjh+cPS1gQZsRJariBQtwN3U84bFOA/Lekn88/hXTcOFsmE3WIoj/ityD9tCuQOcgs0J5o+KbE5bBf80M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776972178; c=relaxed/simple; bh=Ot53Oo/q2RNixhyZdV8ksB2omeZpXjfcOY2JKd0ifKI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Mbq0X3rNSJq4ceOkKSPtj5cCv1o3XkKat8Mc4zI2m8PzndgnoEMP9kHkG7Kbm6ZoFZYjh9Lhwa8bYcjP+U/azebr5J8Z69ube9UDdrZT+lwRMZTaq7jwqPX7wyPDPucKcx3gwNjkZ4MP9Ndmtg+oDn06xDuEj/jfBg5zs5WL/BQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QV5+94d5; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=GiHfITfF; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QV5+94d5"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="GiHfITfF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776972176; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wSQkzxpeA1S/sXqiIjkU5AWADgODzfZs9CPZ+3hRtvI=; b=QV5+94d57eaDtMZ9QkYciOwFzHf+OOXqNSqug2NiA+WLnFXzA1E69HqecP4diZ4gEBvGHo EBhN0G/6jI9Qcw7wtJUnaOYIcYnLV5OLrW4IJt/0H+YA5RQbWT2dyIR82wqWP96wu/+ocf lUjvzkDNTMvbFvK061VvEAdAP2M7AO0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-150-zTo2hXi5N5O2OH__lWVBZQ-1; Thu, 23 Apr 2026 15:22:53 -0400 X-MC-Unique: zTo2hXi5N5O2OH__lWVBZQ-1 X-Mimecast-MFC-AGG-ID: zTo2hXi5N5O2OH__lWVBZQ_1776972172 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-488c768a9a9so49159575e9.1 for ; Thu, 23 Apr 2026 12:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776972171; x=1777576971; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wSQkzxpeA1S/sXqiIjkU5AWADgODzfZs9CPZ+3hRtvI=; b=GiHfITfFuEW9sgFzqezCwYSCZyqzArEhjwb3vz3Jp3k7j3O7wasS89Mpvku9lAJDpY VV9iazkAZBgFD6ikVzA2eRi0gVvzcQQmGeT48gXPPqd7mZKCq/FKCZ+jSkLqlgZ8eK0S hRzTib37+l3YSFuU+kVvyih/hLZJkOsC2UDH7wmvsBK2i+9i4652EvDkIeTxNkwbR60E Y8fLxCaX+UK97riUvSkTHvEzSUZlfySDfx/xWKjiO3rFbWDroawwUJJTkes1LLhuiXdo rx+rpuGxy7hbldogSAvakQU0lDIkZ/58gOSpaJemwkLFzPH5cNjSYjSP8JMV0X1whAkV BPmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776972171; x=1777576971; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wSQkzxpeA1S/sXqiIjkU5AWADgODzfZs9CPZ+3hRtvI=; b=s0YtlghpmGv66uIvZoGTO6ciEjE6inQ+DW6wMpBILKXDJGWJICrjnhQ0DtDunA6kwU UpNrrx++c2opijqJ7WwDcjC9HWhQVnLlShvXmp0oSbGHkgVC63T/NkgjuNH0RM3Gjq2H 0JqkbxQfcbfuy+joXzOY2bgUaepMOATyQf9XL9HMk0xF3FNohIIOocRtbS8R6+LWtiWr F2h9Pjf+GUWmtDtjBabzY9b42PTBBTxXgt2KpSn8sEkllEgounZU5EJ7byrT+Q40gmLD yBynvQeooD8tragCPYv8Z/Z0qewXWt3bamCjBT+6AyQUmRLO+j2KjwbBIfgi9Wv+R6e7 XVug== X-Forwarded-Encrypted: i=1; AFNElJ9ZUqJ/1G5TmyL9DQnRnLdZAIvEaK9FDmUsl7zY89VnzopP+sR+3aKD1jSDK6syjMJrTEeHHidDAJ0FM0Q=@vger.kernel.org X-Gm-Message-State: AOJu0YwkjU9l/q/cKXapsQMBTTABhRfaobNFnfi8oM5qoekg1RD+leYO FsnYFAzDJyc3rRwdKDm/7Sk2p3F44pa5MSLd5IulhneQTr/wK5K4dU0K0Hs8NrYALI4hT/Rf8bV eNJ8zpOG+u2/lQx9t13z+qwX7I4/owwJQRo3npivJpmlxs+tKN1fqXw0AGN9Y/I3XT857sbP/hg == X-Gm-Gg: AeBDies512kxD/Ct3VpC27BdexvilStmhjuU40kzYNUPqt2qXFBBLCBqNkV5GL2p+ls kyB8Gx5BJGOBM/4Zz3qs9AumFv0IBNkXhaC2l7WrOs6vErBp919uwjF2J8BrJmB6VXzdpOAMlqL AN+ttaCzJ4fTWtXzKsvYJPw6pr1+kp5qWgxkDbvf1ga/56tNgiGILfLYs9AP2ah7TZuuDLn3Is+ unutxV/tv7Z3kOW/OkPpRBQ7NAgisRj6zoo4KOwqRhNdWnGuAZZqwH58T3mHfiHwmX8Jg5FYF5k NR6edyHtcEAP0O9iZkOLp+w4tfryVgHmXuZ95XhFYbA1PERKiY4mI0tHJBh76IugX3bn68NCK6L bWInAiooQbJbnhu893Bvx55kwn+oNDPvxY9Y43z9ijHBufsZDLROiZrvBmknY5pZ+TvW/Xulk X-Received: by 2002:a05:600c:8b84:b0:480:1c69:9d36 with SMTP id 5b1f17b1804b1-488fb76e4aamr444109095e9.17.1776972170718; Thu, 23 Apr 2026 12:22:50 -0700 (PDT) X-Received: by 2002:a05:600c:8b84:b0:480:1c69:9d36 with SMTP id 5b1f17b1804b1-488fb76e4aamr444108865e9.17.1776972170228; Thu, 23 Apr 2026 12:22:50 -0700 (PDT) Received: from ?IPV6:2a01:e0a:c:37e0:8998:e0cf:68cc:1b62? ([2a01:e0a:c:37e0:8998:e0cf:68cc:1b62]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4891b46cffasm359609565e9.13.2026.04.23.12.22.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Apr 2026 12:22:47 -0700 (PDT) Message-ID: <14aa4840-29c4-46df-b60d-8e1b92494ad2@redhat.com> Date: Thu, 23 Apr 2026 21:22:45 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: further issues with MGA G200 graphics chipset To: Jacob Keller , Thomas Zimmermann , "airlied@redhat.com" Cc: dri-devel@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , Pasi Vaananen References: <76aba88d-ec23-4b3c-ad91-83face0c3e94@intel.com> <6ec01703-31e0-4998-9508-a5a115ae7bc9@intel.com> Content-Language: en-US, fr From: Jocelyn Falempe In-Reply-To: <6ec01703-31e0-4998-9508-a5a115ae7bc9@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, >>>>>> 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