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=-3.9 required=3.0 tests=BAYES_00,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 10D0EC4363D for ; Tue, 22 Sep 2020 14:04:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8FEDC20936 for ; Tue, 22 Sep 2020 14:04:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="VuFbLfEk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726507AbgIVOEi (ORCPT ); Tue, 22 Sep 2020 10:04:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726473AbgIVOEh (ORCPT ); Tue, 22 Sep 2020 10:04:37 -0400 Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80096C061755 for ; Tue, 22 Sep 2020 07:04:37 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id m13so11223660otl.9 for ; Tue, 22 Sep 2020 07:04:37 -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=4wgsKb3OxXUR5z4H154VpwPi1Z3KYkIOiID7wIY/k60=; b=VuFbLfEkHjH/cqWfMgjOT1SBBW/VmcOZqmgV9/23MU+ZebYLhjw6ZxNSK7QeDY1nps vFdkzJgmBfJmbbz1bLI8yzePYGFfIX0SU9TTcX2dIsY4uN+cS4vZ1qWiH69Veq+qgLeY Lib7wisL9um7XAFnG2j4K0NDro2WwTdN3zD5g= 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=4wgsKb3OxXUR5z4H154VpwPi1Z3KYkIOiID7wIY/k60=; b=anMZ5ry3fYVQyEAgfc45thgTX36gzoKhKs6cE/rOu3gwUb9eM7UMC+XyKTq3stpnuU XZzGK40EPFchXxPiM9bTAjm9fLDiMkkbBiKD290TKw5UlWWRniu3g8nVxdqHMoOuJN0m SIbOlBzleNorOxwMn3P3VagSA0KIIbM4W5P9SlqrHjfZHOBaY1bFBMq9C+mqegE5oBwY NZggxV1EjakY3pXzumfHaUfAACv62GEGwLsZSKT8nSpRbYazLpV4ZDFlQ2b1pIiG5x78 CsTCFTHI5qOi+0vihCoyLtnCJzNx/nX2rsKikoeylEJjkdn0MVYzGUyrtxNPchWYX1WJ EcIw== X-Gm-Message-State: AOAM532GCCej67JwjhTsLH/N2RwDaJdr8FCDlKKLQB7isxihjKzgKuq4 9/I6EV5a0X0+JMaoQyJgOAuPf2Dd3Dsh5WggNhp89x/5z1nxpg== X-Google-Smtp-Source: ABdhPJyBv0gaPZG8IMejxtaWlLqVobObYy9jnCpfJVkRMSl5clWfYxjah6xzCFeAm32mJoMmmJgojTQBRrTDfhZWFQ4= X-Received: by 2002:a05:6830:1e56:: with SMTP id e22mr2796996otj.303.1600783476894; Tue, 22 Sep 2020 07:04:36 -0700 (PDT) MIME-Version: 1.0 References: <20180705101043.4883-1-daniel.vetter@ffwll.ch> <20180705102121.5091-1-daniel.vetter@ffwll.ch> <20200922133636.GA2369@xpredator> In-Reply-To: <20200922133636.GA2369@xpredator> From: Daniel Vetter Date: Tue, 22 Sep 2020 16:04:26 +0200 Message-ID: Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets To: Marius Vlad Cc: Daniel Stone , Pekka Paalanen , Intel Graphics Development , stable , DRI Development , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > On Fri, Jan 31, 2020 at 07:34:00AM +0000, Daniel Stone wrote: > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote: > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > reconfiguring global resources). > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > which can lead to spurious EBUSY calls, both: > > > - when that other CRTC is currently busy doing a page_flip the > > > ALLOW_MODESET commit can fail with an EBUSY > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > of the additional commit inserted by the kernel without userspace's > > > knowledge > > > > > > For blocking commits this isn't a problem, because everyone else will > > > just block until all the CRTC are reconfigured. Only thing userspace > > > can notice is the dropped frames without any reason for why frames got > > > dropped. > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > plug this problem by demoting nonblocking commits which might cause > > > issues by including CRTCs not in the original request to blocking > > > commits. > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > I've noticed this isn't integrated/added. Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > Noticed this is fixing (also) DPMS when multiple outputs are in use. > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing > the warning quite often. This would be a driver bug I think. That really shouldn't happen for normal page flips. -Daniel > > > > Thanks for writing this up Daniel, and for reminding me about it some > > time later as well ... > > > > Reviewed-by: Daniel Stone > > > > Cheers, > > Daniel > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation 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=-3.5 required=3.0 tests=BAYES_00,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 442B2C4363D for ; Tue, 22 Sep 2020 14:06:50 +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 5F13920936 for ; Tue, 22 Sep 2020 14:06:49 +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="VuFbLfEk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F13920936 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 11932890BD; Tue, 22 Sep 2020 14:06:45 +0000 (UTC) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by gabe.freedesktop.org (Postfix) with ESMTPS id 997F96E87D for ; Tue, 22 Sep 2020 14:04:37 +0000 (UTC) Received: by mail-ot1-x342.google.com with SMTP id o6so15720848ota.2 for ; Tue, 22 Sep 2020 07:04:37 -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=4wgsKb3OxXUR5z4H154VpwPi1Z3KYkIOiID7wIY/k60=; b=VuFbLfEkHjH/cqWfMgjOT1SBBW/VmcOZqmgV9/23MU+ZebYLhjw6ZxNSK7QeDY1nps vFdkzJgmBfJmbbz1bLI8yzePYGFfIX0SU9TTcX2dIsY4uN+cS4vZ1qWiH69Veq+qgLeY Lib7wisL9um7XAFnG2j4K0NDro2WwTdN3zD5g= 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=4wgsKb3OxXUR5z4H154VpwPi1Z3KYkIOiID7wIY/k60=; b=LSbjn/vc5ToAyKQJxR7PN2HE2ZKGigXS4ngv5wEoGnBG4nOuU2g7VcR3eqXDIg7rkq iKBJ76epA/rFP2y8TVbL9gUQISzcOd3F9mdL2R0zxEj3Kj0g6LFHRUARDqhPLy5ui13F 4gQGdoU7LfcIh3yhY2ZnAvexCPR9F1mxE6PCLDBiLMG91AtfcXirLPQcGtoOVu4RbS6R LrPOHQ1ZWmGYBhRoHUwMCJ2AE8vaj2qiDuNSe7x4ywiZfE2PufIOGkJzmOlgSdM3s7p4 cd5m6ayjEhaUWJkC3L92VhlEycB0jkhMEUhdDawiEDReJXrXKGvLzMNA5YzSOZupJ3WD MREQ== X-Gm-Message-State: AOAM530do0vnbPfWBbJw0W0O71j9PL0JAALjX/aHiEhvlV/RRiMcbVGL X1g4+O2a+afoK2UK2bYWyncnHCbgD8qai04PJa6ewA== X-Google-Smtp-Source: ABdhPJyBv0gaPZG8IMejxtaWlLqVobObYy9jnCpfJVkRMSl5clWfYxjah6xzCFeAm32mJoMmmJgojTQBRrTDfhZWFQ4= X-Received: by 2002:a05:6830:1e56:: with SMTP id e22mr2796996otj.303.1600783476894; Tue, 22 Sep 2020 07:04:36 -0700 (PDT) MIME-Version: 1.0 References: <20180705101043.4883-1-daniel.vetter@ffwll.ch> <20180705102121.5091-1-daniel.vetter@ffwll.ch> <20200922133636.GA2369@xpredator> In-Reply-To: <20200922133636.GA2369@xpredator> From: Daniel Vetter Date: Tue, 22 Sep 2020 16:04:26 +0200 Message-ID: Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets To: Marius Vlad 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: Intel Graphics Development , DRI Development , stable , 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 Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > On Fri, Jan 31, 2020 at 07:34:00AM +0000, Daniel Stone wrote: > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote: > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > reconfiguring global resources). > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > which can lead to spurious EBUSY calls, both: > > > - when that other CRTC is currently busy doing a page_flip the > > > ALLOW_MODESET commit can fail with an EBUSY > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > of the additional commit inserted by the kernel without userspace's > > > knowledge > > > > > > For blocking commits this isn't a problem, because everyone else will > > > just block until all the CRTC are reconfigured. Only thing userspace > > > can notice is the dropped frames without any reason for why frames got > > > dropped. > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > plug this problem by demoting nonblocking commits which might cause > > > issues by including CRTCs not in the original request to blocking > > > commits. > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > I've noticed this isn't integrated/added. Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > Noticed this is fixing (also) DPMS when multiple outputs are in use. > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing > the warning quite often. This would be a driver bug I think. That really shouldn't happen for normal page flips. -Daniel > > > > Thanks for writing this up Daniel, and for reminding me about it some > > time later as well ... > > > > Reviewed-by: Daniel Stone > > > > Cheers, > > Daniel > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation 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=-3.5 required=3.0 tests=BAYES_00,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 3BF08C4363D for ; Tue, 22 Sep 2020 14:07:52 +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 D31BE20936 for ; Tue, 22 Sep 2020 14:07:51 +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="VuFbLfEk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D31BE20936 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 B797E893C0; Tue, 22 Sep 2020 14:07:50 +0000 (UTC) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by gabe.freedesktop.org (Postfix) with ESMTPS id 990EE6E87C for ; Tue, 22 Sep 2020 14:04:37 +0000 (UTC) Received: by mail-ot1-x343.google.com with SMTP id 60so15716526otw.3 for ; Tue, 22 Sep 2020 07:04:37 -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=4wgsKb3OxXUR5z4H154VpwPi1Z3KYkIOiID7wIY/k60=; b=VuFbLfEkHjH/cqWfMgjOT1SBBW/VmcOZqmgV9/23MU+ZebYLhjw6ZxNSK7QeDY1nps vFdkzJgmBfJmbbz1bLI8yzePYGFfIX0SU9TTcX2dIsY4uN+cS4vZ1qWiH69Veq+qgLeY Lib7wisL9um7XAFnG2j4K0NDro2WwTdN3zD5g= 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=4wgsKb3OxXUR5z4H154VpwPi1Z3KYkIOiID7wIY/k60=; b=m5MScvpYES1M9KHCQvhBMv/hQS3QglHqEsHb6GZR8F2gNiKe0hOTsrtLPsp8Dy+fxA VANp70wDsTGrqAvBprCekL+Y/CBLjEzE6FlcZayi12m46R0KovZpvB0ksOr0+bIrmOZ6 wYcydwBNrUifnM4V8wTiOa+P932wXksY2aQytbLQ69ZjcXEfS6AFg3c9iBu5D5R4Qp0K w4snwRJpUz0oDnKeNfFVu/HtmeUoVHIIxQLj+JLnewTvyAIKl0Wogg3zBegDfnFKmIcD FKQVPMWJxcyLXcudoBHJzouhf964Ptcp/HyZUg3dVXAvMl4gnnjwPqb/+opo0wZWOYCa k42g== X-Gm-Message-State: AOAM533gXYpWTyDtDjZo1cYFVJn3pg++r6J3xeSDTdmJE5qxCJhU7miS cbzKfFBKgK8Xz8JTLk7scj53fImVS6hmzG4Ggtpv/Q== X-Google-Smtp-Source: ABdhPJyBv0gaPZG8IMejxtaWlLqVobObYy9jnCpfJVkRMSl5clWfYxjah6xzCFeAm32mJoMmmJgojTQBRrTDfhZWFQ4= X-Received: by 2002:a05:6830:1e56:: with SMTP id e22mr2796996otj.303.1600783476894; Tue, 22 Sep 2020 07:04:36 -0700 (PDT) MIME-Version: 1.0 References: <20180705101043.4883-1-daniel.vetter@ffwll.ch> <20180705102121.5091-1-daniel.vetter@ffwll.ch> <20200922133636.GA2369@xpredator> In-Reply-To: <20200922133636.GA2369@xpredator> From: Daniel Vetter Date: Tue, 22 Sep 2020 16:04:26 +0200 Message-ID: To: Marius Vlad 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: Intel Graphics Development , DRI Development , stable , 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 Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > On Fri, Jan 31, 2020 at 07:34:00AM +0000, Daniel Stone wrote: > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote: > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > reconfiguring global resources). > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > which can lead to spurious EBUSY calls, both: > > > - when that other CRTC is currently busy doing a page_flip the > > > ALLOW_MODESET commit can fail with an EBUSY > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > of the additional commit inserted by the kernel without userspace's > > > knowledge > > > > > > For blocking commits this isn't a problem, because everyone else will > > > just block until all the CRTC are reconfigured. Only thing userspace > > > can notice is the dropped frames without any reason for why frames got > > > dropped. > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > plug this problem by demoting nonblocking commits which might cause > > > issues by including CRTCs not in the original request to blocking > > > commits. > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > I've noticed this isn't integrated/added. Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > Noticed this is fixing (also) DPMS when multiple outputs are in use. > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing > the warning quite often. This would be a driver bug I think. That really shouldn't happen for normal page flips. -Daniel > > > > Thanks for writing this up Daniel, and for reminding me about it some > > time later as well ... > > > > Reviewed-by: Daniel Stone > > > > Cheers, > > Daniel > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx