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 1744BC4708E for ; Fri, 6 Jan 2023 01:01:22 +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=DwGpbISIJCSR7ZmlRfD7T/S1NU9NToXOsAvWTa16zY4=; b=IxjN7qRk6rdHAY AJGkcEa23FMSoWehSpm41r+hmhfqnugPQbY9Fz/jLqHx35s4YJV+n1e7UTu9D+1U5yCNIDkkwu//V kRUp6bX+/JfJMi/LnzuwiCByuJAei0VxcrSPXHw5CNBuBeidLlqRfp3RwJbUT6z2qOPnf84Rga4F9 UpfVgmBGIW0ibT3a6iikAtjolX8R5X/Jj+gCPd6fYCv/D6qOZpvGQqxlDbrLMVpTs/JkRLegM7UmH eGbLUNh98WGFPR7tjfjQgnlmayc7z+DO18NLROoF9ILuhf64p9RRWv9sardIq6DH6tcprnEAW8wu3 ioBTV+hGo4r5vefl2Sig==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pDb5V-00GfaZ-U2; Fri, 06 Jan 2023 01:00:02 +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 1pDb5R-00GfYV-PP for linux-arm-kernel@lists.infradead.org; Fri, 06 Jan 2023 00:59:59 +0000 Received: by mail-pj1-x1034.google.com with SMTP id w4-20020a17090ac98400b002186f5d7a4cso3775893pjt.0 for ; Thu, 05 Jan 2023 16:59:55 -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=vnoPpXjP1zQGbMmmew/4jTnfiZUKCPX+oITXMMquXbU=; b=WZexEQBQXq1NLHzHrMw8jHw7T/CLPQrdVrBqA4GjnX6U5NwCeeMFs1SIkvUYAKGS98 N3VlZvHib+j7hdImeXbyC4sKcYX84zjllRjOpyoQwjEmv4E0E1BSu5Vd0z7cV3GZ+bSq b/cA0CQgPqPzlS5WiDV3DpAosZSW5A7qeddjY= 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=vnoPpXjP1zQGbMmmew/4jTnfiZUKCPX+oITXMMquXbU=; b=AIxX00iO7bJrhehYYDyP8lD07qpeOcgmt2U4cMs1Ai9vSfifmXMh1dwu9JMr3NRV09 LcDAOSflmufV+zQTgy+AgpMoxofBjC21h97bvgArYBezMFUCyrI+EcBtKxxP2ej9VSSM IPkVWhmUOyxIO/aL3vrFKm4d2fuhAwLvPQMjlvTqb81tgdYvHXdi7MQSi0pJwWjPWJqj +iiz67Ar6+sTNfricxtFHUCaB9US4un+TD+YhYtET1/IpUyMiAi455cOO2vqXEZGDLEb ovhGjumNGfAWtmHpHcChytXslP6iL318sdJDvgYcx8CMAhgCWMT54ZKL0TF2L4QSQqcb /akw== X-Gm-Message-State: AFqh2kqDoT/yqvja/W2y8o/hcJocHZ7pW05WZesmuzWKaPxA1IumleSU s0HM88o5mmvaO9NhX6Re5C7aDQ== X-Google-Smtp-Source: AMrXdXsN6USxhK6rk2gp7+m1QZyksDu7dOnHJN8UlVr6dv8CGvEwsP8D9AZXiVvD505OO+lN9+RtyA== X-Received: by 2002:a05:6a21:1708:b0:af:b770:bce5 with SMTP id nv8-20020a056a21170800b000afb770bce5mr65543337pzb.53.1672966795423; Thu, 05 Jan 2023 16:59:55 -0800 (PST) Received: from google.com ([2620:15c:9d:2:5567:fb20:aa4f:352]) by smtp.gmail.com with ESMTPSA id q7-20020a63e207000000b004a0127e8ca5sm10329844pgh.86.2023.01.05.16.59.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jan 2023 16:59:54 -0800 (PST) Date: Thu, 5 Jan 2023 16:59:51 -0800 From: Brian Norris To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: Neil Armstrong , kernelci-results@groups.io, bot@kernelci.org, Jonas Karlman , Robert Foss , Douglas Anderson , Jernej Skrabec , Mark Brown , Sean Paul , dri-devel@lists.freedesktop.org, 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> <9ff68af1-63f6-1a95-6380-d0d8503fe511@mailbox.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9ff68af1-63f6-1a95-6380-d0d8503fe511@mailbox.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230105_165957_898534_292E1EEF X-CRM114-Status: GOOD ( 29.42 ) 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 On Wed, Jan 04, 2023 at 10:11:46AM +0100, Michel D=E4nzer wrote: > On 1/4/23 03:11, Brian Norris wrote: > > On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel D=E4nzer wrote: > >> On 12/21/22 23:02, Brian Norris wrote: > > = > >>> 3. leave vblank enabled even in the presence of PSR > > = > > I'm leaning toward this. > = > If this means vblank interrupts will arrive as expected even while in PSR= , that may be the ideal solution indeed. Yes. And I think I have a working patchset for this now. It passes all the igt-gpu-tools/kms_vblank tests for me now, and I don't think it causes any other issues. I'll send it out shortly, after a bit more testing. Side note: I believe this vblank-disabled issue actually came in as an upstream regression at commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"); before that, we were doing this very differently, and didn't touch vblank at all for PSR, similar to the "downstream" stuff I mentioned earlier. > >> 5. Go/stay out of PSR while vblank interrupts are enabled (probably wa= nt to make sure vblankoffdelay is set up such that vblank interrupts are di= sabled 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. > = > Not sure how likely that is, quite a few drivers are setting dev->vblank_= disable_immediate =3D true. > = > With that, vblank interrupts should generally be enabled only while there= are screen updates as well[0], in which case PSR shouldn't be possible any= way. > = > [0] There may be user space which uses the vblank ioctls even while there= are no screen updates though, which would prevent PSR in this case. OK. I'm just reading docs here; definitely not an expert. > >>> [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 us= er space. > > = > > OK. Any hints as to what kind of user space uses this? > = > I don't have any specific example, just thinking about how user space cou= ld respond to the vblank ioctls returning an error, and it would seem to be= generally either of: > = > * Just run non-throttled, which might negate any energy savings from PSR > * Fail to work altogether > = > = > > 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. > = > If vblank events never come, user space might freeze. Thanks. If my patchset works out like I expect, this should no longer be noticeable to user space, so I don't really have to test out your educated guesses :) Thanks for the idea-bouncing. Brian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel