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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 019D2C433E0 for ; Thu, 14 May 2020 07:08:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D79AE206D8 for ; Thu, 14 May 2020 07:08:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="RagWkUEE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725878AbgENHIh (ORCPT ); Thu, 14 May 2020 03:08:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725866AbgENHIh (ORCPT ); Thu, 14 May 2020 03:08:37 -0400 Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBF94C061A0C for ; Thu, 14 May 2020 00:08:36 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id x7so22813637oic.3 for ; Thu, 14 May 2020 00:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=biA9r0T5Sv8YCx33FWjEpY/1dzcGIkDdNQS4u+MoouI=; b=RagWkUEEVxT3M0/6JygfpeHFqxjNSK9bLGwanXl+yLlMcDld9yavXpnYjhC9HsYTyt IpbbT6bHMaMd2f9vY6YNn+nUwDS2OMydKVzTrB2VzDs5z9m/uiV2W+qu69XkVhRE9U/D JCKPy6/hBAHyVbbUSJo1VFF3mcNxHW3TBhsy4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=biA9r0T5Sv8YCx33FWjEpY/1dzcGIkDdNQS4u+MoouI=; b=QlWfor33DMQlWvhJBN8kFv8EWFGCYSTnV5wPahRhs/G7KSs+x1ILJoFBP8aNgnQCY0 oO30zv4mLD6p4GmlcLvsV1BRYt/NvPcup12kZEbw2UkGKBTXGr21qTYSBJlXYwk4Ehv3 fAniUUSbcEUdOYi3UXpkH4rmWcWkrHRXX+ck+l3912GcM8fUJtQH6Sa/X9S1DhLGtFu7 RtRjvmdAL38up9G4AVIYK5Ub9u98e+KHaydcrDgtO54VDnypnUlYdfQuD6gkcABl85L8 weRVYg/WmxKXoMClVIcUXL0ZoSR4prtxcCIjPJirFe+tGfuy7NzBKuFPb6zCtGf68Gi6 AnMw== X-Gm-Message-State: AGi0PubQ7Q0mdO+ji+DmHBRDlp9NACpUb5l0u//Heq4qEaQoKBa6vncU cJYZO/sTY5bRBjjbhdwh9SbDb92eJy02I+ISru3wx28N X-Google-Smtp-Source: APiQypKJ6btuyR96uWgPEvWVBRFi5eTdiYG7q16E+P138IuV2y8xg7pd1Cxf/tBRYAklxwLz52LrYL47V81D1ObHYgU= X-Received: by 2002:aca:3b41:: with SMTP id i62mr11137374oia.101.1589440116176; Thu, 14 May 2020 00:08:36 -0700 (PDT) MIME-Version: 1.0 References: <20200408162403.3616785-1-daniel.vetter@ffwll.ch> In-Reply-To: From: Daniel Vetter Date: Thu, 14 May 2020 09:08:24 +0200 Message-ID: Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets To: Daniel Stone Cc: DRI Development , Intel Graphics Development , Pekka Paalanen , stable , Daniel Stone , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, May 14, 2020 at 8:42 AM Daniel Stone wrote: > > On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote: > > Resending because last attempt failed CI and meanwhile the results are > > lost :-/ > > Did anything happen with this? Nope. There's an igt now that fails with this, and I'm not sure whether changing the igt is the right idea or not. I'm kinda now thinking about changing this to instead document under which exact situations you can get a spurious EBUSY, and enforcing that in the code with some checks. Essentially only possible if you do a ALLOW_MODESET | NONBLOCKING on the other crtc. And then tell userspace you get to eat that. We've been shipping with this for so long by now that's defacto the uapi anyway :-/ Thoughts? Too horrible? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch 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 X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1155FC433E1 for ; Thu, 14 May 2020 07:08:39 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E189E206B6 for ; Thu, 14 May 2020 07:08:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="RagWkUEE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E189E206B6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2EC926EABB; Thu, 14 May 2020 07:08:38 +0000 (UTC) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id DD8566EAB9 for ; Thu, 14 May 2020 07:08:36 +0000 (UTC) Received: by mail-oi1-x244.google.com with SMTP id 19so23717770oiy.8 for ; Thu, 14 May 2020 00:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=biA9r0T5Sv8YCx33FWjEpY/1dzcGIkDdNQS4u+MoouI=; b=RagWkUEEVxT3M0/6JygfpeHFqxjNSK9bLGwanXl+yLlMcDld9yavXpnYjhC9HsYTyt IpbbT6bHMaMd2f9vY6YNn+nUwDS2OMydKVzTrB2VzDs5z9m/uiV2W+qu69XkVhRE9U/D JCKPy6/hBAHyVbbUSJo1VFF3mcNxHW3TBhsy4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=biA9r0T5Sv8YCx33FWjEpY/1dzcGIkDdNQS4u+MoouI=; b=WOdOhoPTn/vNO0W27ajohzs7AARkjIdzTMbqs+eH1nW+NU6D//MisFYGjEcDoOb/d8 k8FtPvd/l74LHTHfOi4IYEL1csg9Yl4DsJoFlSSZWw3kqhJvGeRpseflFroupM3x+9Ze 7tDTNHMt10E9FUWJOM2yDUPjdKWOYda0+OLjgPoc1Ps+CalF/VeCc5BzoXEsj+pvOx/V c8rGifarTeTyzqc/eKVMlPfJe8W/8apelfkjhy3X2ZZ9EcoQBhwJUJu5DUYKx8vNX2U3 P/S6yOCGI/iMnTPUxwO7AOngYnVzBT/SQA8XM4kOfOG1hn4TE584P+GGfTg+UvPfM6NN A1/g== X-Gm-Message-State: AGi0PuZykm8wnWQNGniAVBQ4Sns1QRMcUHj23+A9jqyOKv6uyd5YyGuK slN/eiiFj9fjUZy/i4lamRWXp1jW4vyUNacWjTI6tw== X-Google-Smtp-Source: APiQypKJ6btuyR96uWgPEvWVBRFi5eTdiYG7q16E+P138IuV2y8xg7pd1Cxf/tBRYAklxwLz52LrYL47V81D1ObHYgU= X-Received: by 2002:aca:3b41:: with SMTP id i62mr11137374oia.101.1589440116176; Thu, 14 May 2020 00:08:36 -0700 (PDT) MIME-Version: 1.0 References: <20200408162403.3616785-1-daniel.vetter@ffwll.ch> In-Reply-To: From: Daniel Vetter Date: Thu, 14 May 2020 09:08:24 +0200 Message-ID: Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets To: Daniel Stone X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Stone , Intel Graphics Development , stable , DRI Development , Daniel Vetter , Pekka Paalanen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, May 14, 2020 at 8:42 AM Daniel Stone wrote: > > On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote: > > Resending because last attempt failed CI and meanwhile the results are > > lost :-/ > > Did anything happen with this? Nope. There's an igt now that fails with this, and I'm not sure whether changing the igt is the right idea or not. I'm kinda now thinking about changing this to instead document under which exact situations you can get a spurious EBUSY, and enforcing that in the code with some checks. Essentially only possible if you do a ALLOW_MODESET | NONBLOCKING on the other crtc. And then tell userspace you get to eat that. We've been shipping with this for so long by now that's defacto the uapi anyway :-/ Thoughts? Too horrible? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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 X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD246C433DF for ; Thu, 14 May 2020 07:08:37 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A0A10206B6 for ; Thu, 14 May 2020 07:08:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="RagWkUEE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A0A10206B6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 431916EAB9; Thu, 14 May 2020 07:08:37 +0000 (UTC) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id DE1B36EABB for ; Thu, 14 May 2020 07:08:36 +0000 (UTC) Received: by mail-oi1-x244.google.com with SMTP id o24so23739073oic.0 for ; Thu, 14 May 2020 00:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=biA9r0T5Sv8YCx33FWjEpY/1dzcGIkDdNQS4u+MoouI=; b=RagWkUEEVxT3M0/6JygfpeHFqxjNSK9bLGwanXl+yLlMcDld9yavXpnYjhC9HsYTyt IpbbT6bHMaMd2f9vY6YNn+nUwDS2OMydKVzTrB2VzDs5z9m/uiV2W+qu69XkVhRE9U/D JCKPy6/hBAHyVbbUSJo1VFF3mcNxHW3TBhsy4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=biA9r0T5Sv8YCx33FWjEpY/1dzcGIkDdNQS4u+MoouI=; b=GyuBRVFLZHpl3M1sU5mMBKehUHu+EHqcZR2S/qTJo8k8GboKN9LH0mQ4wxjezaXjdI 5WZkJvDgCK+unD6KFtu2U6BW9id2F0obQMbz21L7VmpY6y8A3x2Uv3ar74Hjgngf/IU4 i834lAbnxkmpRmekw+dZZxGCNWnvMezjrQnt6fuz/yAqazQ/gowp/AosH9FD319pXkX/ L7kQbHdQLfYf1C6ZO7vnBZt/P7lsvubB7eBIqXwsTUS8En4+Z9ugNIaVcRWrCf3/JaAx h16+JLPJa2UJR9MEVk3JTL27/n9dFa3klebXJ0kUCsLpSX6I/02q8+pNey/jP5fmb9MY M6hQ== X-Gm-Message-State: AGi0PuZ7xndwMrtqzZ/vd8KbRoosTx1KzW3FlfHEJ1i8fvnJB/TUXoxo AFoRrJwesZKjMmK6toPCewlqOxscvUOO6QjRMQHAFA== X-Google-Smtp-Source: APiQypKJ6btuyR96uWgPEvWVBRFi5eTdiYG7q16E+P138IuV2y8xg7pd1Cxf/tBRYAklxwLz52LrYL47V81D1ObHYgU= X-Received: by 2002:aca:3b41:: with SMTP id i62mr11137374oia.101.1589440116176; Thu, 14 May 2020 00:08:36 -0700 (PDT) MIME-Version: 1.0 References: <20200408162403.3616785-1-daniel.vetter@ffwll.ch> In-Reply-To: From: Daniel Vetter Date: Thu, 14 May 2020 09:08:24 +0200 Message-ID: To: Daniel Stone Subject: Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Stone , Intel Graphics Development , stable , DRI Development , Daniel Vetter , Pekka Paalanen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, May 14, 2020 at 8:42 AM Daniel Stone wrote: > > On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote: > > Resending because last attempt failed CI and meanwhile the results are > > lost :-/ > > Did anything happen with this? Nope. There's an igt now that fails with this, and I'm not sure whether changing the igt is the right idea or not. I'm kinda now thinking about changing this to instead document under which exact situations you can get a spurious EBUSY, and enforcing that in the code with some checks. Essentially only possible if you do a ALLOW_MODESET | NONBLOCKING on the other crtc. And then tell userspace you get to eat that. We've been shipping with this for so long by now that's defacto the uapi anyway :-/ Thoughts? Too horrible? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx