From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8E55CC3DA7D for ; Wed, 4 Jan 2023 02:15:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oK3qFty6Oiwatp7RhcXPWEeeHAdrcsz+VXJ7SUSPOQ0=; b=HWVqvhKPnBIJjq DNyQhhv4R2QVjIvEYCrqwrZsnLxX70BFvq8R8keGpC7WI5A6KhwkPFwV5JqfT/drgZo4oWz8cD1LR 3rGm969udKqqHxjSCABaDtcnHbUhf+BJTua6QMoy+ymUsblZQFeeHZNuE1oZ0XUn14XTVvk35BiRI 3CYQ3DI1VufUrAUnW6BV3Blk8P+K7Jz90hCZa+M61rxHSZADYOy8Qxd0CQ+1l+yNc+9/AJ5OJZzat S6jgdUs0izaHfsB582SnZ4GfIwexc62cwEC4xCXaVhym7zHuIx5hQB/0wuIR4cDvIT3eZM7+zLGln E6rcs0WYvQG/gF/7PUSg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pCtI5-006JxV-CW; Wed, 04 Jan 2023 02:14:05 +0000 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pCtFq-006JeY-6O for linux-arm-kernel@lists.infradead.org; Wed, 04 Jan 2023 02:11:48 +0000 Received: by mail-pj1-x1034.google.com with SMTP id c8-20020a17090a4d0800b00225c3614161so30482280pjg.5 for ; Tue, 03 Jan 2023 18:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=PXPntPoK587NA8l6EZllaiBISclp1QfdAS6bIiQy//0=; b=lg3dPf4YZ/7xjrMO2o8VKPQYFcAWW4ljuI3K0IbLukvmJMQ0QSTMhPu0aHDHoITJCi jJQNmqpj5UqPK8+5cvMyb/GXoN3mt+vZlY4HZsktLQ8QMjLPK8cnuPUYVPfGCQ+ZP3Hj Ua5cDTU3WibB3KiTu89JLIvVpSBi6Tck4vkGY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PXPntPoK587NA8l6EZllaiBISclp1QfdAS6bIiQy//0=; b=zUi8U1vb3IRy2fKym2yyDCr4PitreCoBbzl4rrPpnEgfgAdgbGWbR64COwgCjBq0Uk S9dDXoyb/9XtggT9DKnNksLT73CKp27w02eURgTDBkI8zqrFNnM/jNkUyhf710rViQ6I OBNUcYE9p2Xy2SbzBq3v0+S61r/OLPAM6xssyl62z5UeqMlEAyyatx+K4tDK0og1q8Xz 5k6GuaUdUM5U38OcWjVWxltkk7Ymyp0Lh4urFzsJV254F7BJOE4z4rpbS4r1hKHzlAM9 Dh3Vo7jXL9KfkoCLhHkqggR4DbAfPwszi3Wzijv69x06knXPo0ppS5WB+dc8myNVOcds A1Pw== X-Gm-Message-State: AFqh2krv8PtNLLj2MKXz0Z1BKYuh18Ii72GK36awQqOuMAZN38qk9qOn UH+hNGAq76LDwV+0wvY+sFnNSQ== X-Google-Smtp-Source: AMrXdXuRSA/U5c5b/VbhPcWobwWJtO8py1TdCRoOINe3siMy1kdquKOga/pJ6+5J1LmwLCbUHeUKZA== X-Received: by 2002:a17:902:ec89:b0:185:441f:7087 with SMTP id x9-20020a170902ec8900b00185441f7087mr66470037plg.12.1672798303792; Tue, 03 Jan 2023 18:11:43 -0800 (PST) Received: from google.com ([2620:15c:9d:2:d4fc:5992:1009:1647]) by smtp.gmail.com with ESMTPSA id q7-20020a170902a3c700b0018997f6fc88sm7796543plb.34.2023.01.03.18.11.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jan 2023 18:11:43 -0800 (PST) Date: Tue, 3 Jan 2023 18:11:40 -0800 From: Brian Norris To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: Mark Brown , Sean Paul , Neil Armstrong , Jernej Skrabec , kernelci-results@groups.io, bot@kernelci.org, Jonas Karlman , Douglas Anderson , dri-devel@lists.freedesktop.org, Robert Foss , Andrzej Hajda , gtucker@collabora.com, linux-arm-kernel@lists.infradead.org, Laurent Pinchart Subject: Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin Message-ID: References: <6398848e.170a0220.f8e8e.d44f@mx.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230103_181146_388957_7168026E X-CRM114-Status: GOOD ( 23.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Michel, Thanks for your thoughts. I'll give my attempt at weighing my and your options, with the caveat that I'm still not much of a DRM expert. On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel D=E4nzer wrote: > On 12/21/22 23:02, Brian Norris wrote: > > So how to fix this? > > = > > 1. ignore it; it's "just" a test failure, IIUC [1] Probably discarded, per Michel's notes. > > 2. change the test, to skip this test if the device has PSR Doesn't seem great, and not just because PSR is not directly detectable in user space. > > 3. leave vblank enabled even in the presence of PSR I'm leaning toward this. > > 4. otherwise modify the vblank ioctl interface, such that one can "wait" > > for a vblank that won't come (because the display is in self-refresh > > / there are no new frames or vblanks) That doesn't sound so great of an API, to essentially induce hangs, pending other activity. (Assuming I understand the DRM APIs here correctly.) > FWIW, a couple more alternatives: > = > 5. Go/stay out of PSR while vblank interrupts are enabled (probably want = to make sure vblankoffdelay is set up such that vblank interrupts are disab= led ASAP) That seems not extremely nice, to waste power. Based on the earlier downstream implementation (which left vblank interrupts enabled), I'd wager there's a much larger power win from PSR (on the display-transport and memory-bandwidth costs), relative to the power cost of vblank interrupts. Also, messing with vblankoffdelay sounds likely to trigger the races mentioned in the drm_vblank.c kerneldoc. > 6. Use fallback timers for vblank events while in PSR (there might be som= e infrastructure for this, since some drivers don't have real vblank interr= upts) There's drm_atomic_helper_fake_vblank(), but I don't think that's really hooked up to a timer. That's potentially promising though. > > [1] Or is it? I don't really know the DRM_IOCTL_WAIT_VBLANK ABI > > contract in the presence of PSR, but I believe the upstream PSR > > support has always worked this way. I could imagine > > DRM_IOCTL_WAIT_VBLANK users might not love seeing EINVAL here > > though. > = > Yeah, that's pretty likely to cause issues with existing real-world user = space. OK. Any hints as to what kind of user space uses this? A cursory look doesn't show that any of the ChromeOS user space uses it, which may be why it was overlooked in the initial PSR development and upstreaming. I'm in part simply curious, but I'm also wondering what the error-handling and reliability (e.g., what if vblanks don't come?) expectations might be in practice. All in all, it's seeming like maybe option 3 or 6 are best. I'd lean toward 3, assuming I can hack my way through "driver forgot to call drm_crtc_vblank_off()" and similar problems, in part because it's ground that has partially been tread before. I hope that doesn't complicate the DRM state machine even more though, now that I'll have to better coordinate the "enabled"/"self_refresh_active" states with "vblank enabled"... Thoughts still welcome of course. Brian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel