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.129.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 92E853090E1 for ; Thu, 29 Jan 2026 18:47:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769712431; cv=none; b=MQqrYW4xiR6RFspy5le0A1YY45G/MPt7LAM8OpIUg87uZckHwVeIfJKgJRJQB7rCbYoMdCbIakBLAjDLYkJKPoeV9xRAQs0CKXbdZb8ulnS2tf3ab1i15vtrwnWLGBVOxMYcmAziT5eJIM8UGquz1vS3OmiPRWtfv9r/ZJWwbsE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769712431; c=relaxed/simple; bh=zwCpm9Zfi/rbukqXF+DTC/LB1K9zumi5IVKOILSSAp0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kGhJZ3P7wSk//ZGdXvzdAfi5H5GXiIWNLpEQq1cYLiuYVe00pEe+5amsJ/OdpeR+dydTWq+ZhO8+0NGDu5SA7JaQGVWR2Qmj9z9+pZi9F1fshAT++xkZ7fOybLi4oe3PoaFmgYn8CI740JUaI28j67aHlaxl/LRBd+rWCbGU0+k= 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=YA5k02fS; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=TxxFiA+a; arc=none smtp.client-ip=170.10.129.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="YA5k02fS"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="TxxFiA+a" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769712428; 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=h4+j/1ESYhDBOc0/ySW5KbZLWXBWumy70U4Psq4VqS4=; b=YA5k02fSMnvCQztfWV5SJmC+ZrxAZNupxOiBYsL4HoZ++LtzCAVz7P/6+XcsAA3UEFOmkJ k6K8PPi8ju0C/KESb0JH3AoT0JKWj7cQOlxeY1TftPCqqy1+YecJlin2aMVYPA4An/799f VG6FwscCeP6tLmDoFdXj+K2B7+7S8Dc= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-647-okRTb9NxOZii8l-b5IhRqQ-1; Thu, 29 Jan 2026 13:47:07 -0500 X-MC-Unique: okRTb9NxOZii8l-b5IhRqQ-1 X-Mimecast-MFC-AGG-ID: okRTb9NxOZii8l-b5IhRqQ_1769712426 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-480717a8ef9so10172665e9.1 for ; Thu, 29 Jan 2026 10:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769712424; x=1770317224; 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=h4+j/1ESYhDBOc0/ySW5KbZLWXBWumy70U4Psq4VqS4=; b=TxxFiA+akqMi6U4EtDaU880Kte42O63AyQNoPVD170m0j8PrL2Y4tdtxA4QiMfxTWz it7dP+qMuRTFTrATtcOzE0cl7rLXjKxPGEJaZEnuh+8s11HHOHbpQyvqi0lWikN/jE8y Mk0Lwl94viFVcnCVZQiwhUyoOlx0NQ0f+BD8wMMR9xn9zlmbzZxG43KAxZbjHhX4RXw7 Msek+Czues+CKsT1AwbNxIzQzdDb/2vWh3mpWHhQoG4/ToRCBFeug/lQWlgqDQM9uvMd 4ceHmSE62EZtUGNco3nMPQMKaAO8YUxshU+bw+QyJr17cp0TSf6OktHSKYNRBRqG6Ek5 yh2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769712424; x=1770317224; 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=h4+j/1ESYhDBOc0/ySW5KbZLWXBWumy70U4Psq4VqS4=; b=jTpMeoxcbNtel5wV6FZ024IVeR4jpAKJv/+LPBNJQbHTgMSGS8H5AFmMIM7xWmP6Eh 2bVoNRMe4kNW8Q5prGBGyApY5LZuUERJxtv5knYMPmiDRaX8LqiV7qAhAhp1qxMRAWhQ VlqPYYbYkqIiBxIK4am7iv8KLzwYoDws8MjT3tspc/uLfGrv+3I7e6EMsnblXDWsayUZ 4K4L+lW+pW3ZPYoBuVFoKILeF6uu7tXtFhXhac8bTZMAYOB3blD3UGBdZD6OHKUDQxb5 QWBKckYCQNrHYZk0OOOwgpCqB7IP3ASjIvPO0cDQfWWrg7T9L11EV0rV3cV8UeIkVYtw sIPw== X-Forwarded-Encrypted: i=1; AJvYcCVy5El5jiZ/YnpmcYszEj1dBifmqLvEaCN9KWwYZ/5pNBYGJRXYWw38utGSj4f9Ei2r5YgdE5O5VOnEyeE=@vger.kernel.org X-Gm-Message-State: AOJu0YwFw7wTajl7b/KjbTMLvav5Y210wN4Rss5diKfHfAjxOv1LIdax XP9Eb6s86lxst0CvzsFGUaF8Lu8LiL2AsvVu53AI4xjc7vE97Iq6f/aG6QwQsNFH03Z7nFqSIgg qK6erHPZIUQTqCgkQX5DM9wyhPce2FrvGSGgGUa2pLt4bS+ZOxb7SeoKV2dgIJhK1/cyrneInTw == X-Gm-Gg: AZuq6aK5jYqfQ/h7S+dOKgGSkV69aHRTTkQsj+ggRfHQqTSSOiamlWXoJulfCkGYA5K L/X5QU4o43p3lnOGlN6jTDQyem9vK2sLMLQAXu/MwaYtjFc8RCaZsXmwckkP5unTV53I7jbcvHf 8zO2RW8/Ung/KU/W5dF2CDkMvD8xOa+kCHY/gIk4PWzRWihp+rzTm2ytmwQr4OdMc15GAkxQM8a SJnCyXgrVq8VMMUfyn7HzFhpLiZv/G5RQhll3scKEGBFJIKPmO+aRZAnmTvbyN9+UYqRjoHQwUh x9uN5CbBFz/F7bdfeCsVt7qu7MDFVWh5ISW/LwerBJZISUMqC/LIc50NxqvzVErMWblAwJQK9vq OUcUp90p3/AcMbJ4St367ynbh20IihR+6IQ2WMtAVxANROlk2tg== X-Received: by 2002:a05:600c:1e24:b0:477:a289:d854 with SMTP id 5b1f17b1804b1-482db44866fmr2367745e9.5.1769712423615; Thu, 29 Jan 2026 10:47:03 -0800 (PST) X-Received: by 2002:a05:600c:1e24:b0:477:a289:d854 with SMTP id 5b1f17b1804b1-482db44866fmr2367295e9.5.1769712423207; Thu, 29 Jan 2026 10:47:03 -0800 (PST) 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-481a5e1842asm2907485e9.16.2026.01.29.10.47.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 10:47:02 -0800 (PST) Message-ID: <27af79a8-ee84-4845-a737-82d3883536e7@redhat.com> Date: Thu, 29 Jan 2026 19:47:00 +0100 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: [PATCH] drm/mgag200: sleep instead of busy wait for BMC To: Jacob Keller , Thomas Zimmermann , Dave Airlie , Maarten Lankhorst , Maxime Ripard , Simona Vetter Cc: Pasi Vaananen , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260128-jk-mgag200-fix-bad-udelay-v1-1-db02e04c343d@intel.com> <338ff7cf-1c7d-48da-b1b8-37aac440fed0@suse.de> <88f33e4e-5d0e-4520-a399-5be2901a3281@intel.com> Content-Language: en-US, fr From: Jocelyn Falempe In-Reply-To: <88f33e4e-5d0e-4520-a399-5be2901a3281@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 29/01/2026 18:35, Jacob Keller wrote: > On 1/29/2026 12:15 AM, Thomas Zimmermann wrote: >>> diff --git a/drivers/gpu/drm/mgag200/mgag200_bmc.c b/drivers/gpu/drm/ >>> mgag200/mgag200_bmc.c >>> index a689c71ff165..599b710bab9b 100644 >>> --- a/drivers/gpu/drm/mgag200/mgag200_bmc.c >>> +++ b/drivers/gpu/drm/mgag200/mgag200_bmc.c >>> @@ -1,6 +1,7 @@ >>>   // SPDX-License-Identifier: GPL-2.0-only >>>   #include >>> +#include >>>   #include >>>   #include >>> @@ -12,7 +13,7 @@ >>>   void mgag200_bmc_stop_scanout(struct mga_device *mdev) >>>   { >>>       u8 tmp; >>> -    int iter_max; >>> +    int ret; >>>       /* >>>        * 1 - The first step is to inform the BMC of an upcoming mode >>> @@ -44,28 +45,20 @@ void mgag200_bmc_stop_scanout(struct mga_device >>> *mdev) >>>        * 3a- The third step is to verify if there is an active scan. >>>        * We are waiting for a 0 on remhsyncsts ). >>>        */ >> >> Either these comments or the original test seems incorrect. >> >> The test below is supposed to detect whether the BMC is scanning out >> from the framebuffer. While it reads a horizontal scanline the bit >> should be 0. That's what the test is for, but it gets the condition >> wrong. >> >>> -    iter_max = 300; >>> -    while (!(tmp & 0x1) && iter_max) { >>> -        WREG8(DAC_INDEX, MGA1064_SPAREREG); >>> -        tmp = RREG8(DAC_DATA); >>> -        udelay(1000); >>> -        iter_max--; >>> -    } >>> +    ret = read_poll_timeout(RREG_DAC, tmp, !(tmp & 0x1), >>> +                1000, 300000, false, >>> +                MGA1064_SPAREREG); >> >> The original while loop ran as long as "!(tmp & 0x1)".  And now the >> test stops if "!(tmp & 0x1)" AFAICT.  This (accidentally?) fixes the >> test and makes the comment correct. >> >> >>> +    if (ret == -ETIMEDOUT) >>> +        return; >>>       /* >>>        * 3b- This step occurs only if the remove is actually >> >> Since you're at it, maybe fix this comment to say >> >> '... only if the remote BMC is ...' >> >>>        * scanning. We are waiting for the end of the frame which is >>>        * a 1 on remvsyncsts (XSPAREREG<1>) >>>        */ >>> -    if (iter_max) { >>> -        iter_max = 300; >>> -        while ((tmp & 0x2) && iter_max) { >>> -            WREG8(DAC_INDEX, MGA1064_SPAREREG); >>> -            tmp = RREG8(DAC_DATA); >>> -            udelay(1000); >>> -            iter_max--; >>> -        } >>> -    } >>> +    (void)read_poll_timeout(RREG_DAC, tmp, (tmp & 0x2), >>> +                1000, 300000, false, >>> +                MGA1064_SPAREREG); >> >> Again, the comment and original code disagree and the original test >> condition appears to be inverted. It whats to test of the BMC has >> finished scanning out the final frame. The bit should turn 1. Instead >> it tests if the bit is already 1, which is likely true. Hence that's >> probably where your 300 msec delays comes from. >> >> Best regards >> Thomas >> > @Dave or @Jocelyn, any chance one of you could help me figure out > whether Thomas is correct here? It does seem likely that the conditions > were originally inverted and thus forcing a wait for 300msec every time > regardless. That does match my experience... But I don't have (and web > searches failed to find) any relevant datasheets... I will give it a try tomorrow, on my test machine, and check what this register value is in this case. Regarding documentation, I've only seen the original documentation for the Matrox AGP card from 1999, but I never seen one with the BMC registers. From what I understand this code is only there to wait enough time. As mgag200_bmc_stop_scanout() is only called on hotplug, we could even replace that part with a msleep(300); -- Jocelyn > > I guess I can switch the conditions back such that we match the original > code and sleep.. but it does seem likely that we really don't need to > wait for the 300msec, but actually just that the scanout is done and the > conditions were wrong.. > > Obviously we need a v2 with either the conditions matched to the > original code or I'll need to re-write the commit message. > > Thanks, > Jake >