Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1691234pxb; Thu, 7 Oct 2021 13:01:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYs22W4Y2TaeeeNqe51o7g/XMh71zGsS48oOBlSrZTC2kUg5z0KdTt66y//ZWrfp/TxY8a X-Received: by 2002:a65:62cb:: with SMTP id m11mr1227029pgv.425.1633636888508; Thu, 07 Oct 2021 13:01:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633636888; cv=none; d=google.com; s=arc-20160816; b=bg8sk8FCaj44zpHqRotn78Uq0311pgStj+dH01XzffU0NpVMWIz9spt37P307fUcsK +ORTW00XG47cXvBPzi0HQ8ZFdbz3pegG2BH4MVmRdUVY2mB+7LxZK78hHYygmaL1+OHn tYVjIVBnStwCrxtghbcHIMGz0kyCs9IyJvNGGFFQ+NkGKa1r6vzap+tlKGmcbJ7+imea IbmLqR+juNHIKn0eN8k7DuKgJ6T7kb/PZEnrgfwijQN9bYPzB7Vuq3RjINuJgaGNI/gB 5kwBzfkDUYrzuXBI7BCTLQWBiZfdM55+sbJDnumlbrY9CzQZ++PrhE1GjflIXvkR7+Qk 8ndw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=Z7pPxioYkvqtkcj6kzdylA56SKrdD8maYiES13Raowk=; b=qcy7F3uFifUNFlsluFGioDgniQKXl4POR9UYADlcxKrXad95a6IMIbl4d60ecJUWP5 /nA3xny53CXyeWPzHkH+8m7x1qEikX5sXbig9Rmk+Clb3HXNGyqKdEAjTaNBfqgk7deS ijA4zGrKFp1LUdBi6oI7hz4Th6u5amVFEn3CF0Lkyt/BhV8yJsZ6qgBc+G4LCYlT5LAi 3ZK5mAixzPfzJPyUpb6ePjmGchFjoy8jyAjUkT7EK/txjzuertetndk1raTRpHh4iJdL aaETquj/xizO165e1UHmVTxFKECML+pnH9nKINDB3RbOY60uAq3tCLoWmGsUeC4iVj7N kUZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@u92.eu header.s=fm3 header.b=ck0LrpGh; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=lMjm1Fzn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f24si378496pgl.25.2021.10.07.13.01.13; Thu, 07 Oct 2021 13:01:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@u92.eu header.s=fm3 header.b=ck0LrpGh; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=lMjm1Fzn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244002AbhJGTlC (ORCPT + 99 others); Thu, 7 Oct 2021 15:41:02 -0400 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]:40191 "EHLO wnew1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242204AbhJGTkw (ORCPT ); Thu, 7 Oct 2021 15:40:52 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.west.internal (Postfix) with ESMTP id 1946A2B009FD; Thu, 7 Oct 2021 15:38:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 07 Oct 2021 15:38:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=u92.eu; h=from :to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=fm3; bh=Z7pPxioYkvqtk cj6kzdylA56SKrdD8maYiES13Raowk=; b=ck0LrpGhPWbUzLzb2+bet1Gqbv/Hp SmKTVStKVusy6Pf6AVlMlahuroBeJbyvyxyA1udORaHIvkXGeR6YY3WtzlAFepna fCQadeA2boX9Y5dKIkXyxFMDAB7Fw1sS0o2bTQA+1PmHkclpDQT7Lz2PdHqFu+TV YtDmtlFoH2qQwhsy2eGCECU1voFPM1++O0DbnILnYEorfBcXWpj7tQJ6hVZCAmDd NV/XH+GCUCHkUF1lkyUTfsUhXaw9nB5VU16nuteCGc7cMOCIdm+aF1SNwuQPm5Bj 66n8jG+SsVaKw7Z/NjHjNkvdFw15YArPOlAAgVKslHjG7fGsEZstBrSwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=Z7pPxioYkvqtkcj6kzdylA56SKrdD8maYiES13Raowk=; b=lMjm1Fzn e2Bb2C5b6oiTWkkqXIDyCjYqlOaM9bOsrcinjDeB3E2056FcrScGcBJDN/lLNmdB f3Ynvj7GJP/myZU+lywH0k78Yi1/5rFb+Ym1SMtOpwY47H5Nxr1a7oS7Mxd8wEWv 08GKc0YrhTVNqXmQ/O0xg3i9ljq4gq9DqWkKKV1UOAg0Xbpr4qWjvV+3J7FsEWX6 ytUHMqdDpHe1E5VTG+vgDY2er1kUF4BWeRoqzrRzBVJyeuSB48y4cgwRM9REQVBv Oe48DBWVE0i5aTbDpM01b8nz0krQFpTi6OlS2yhHH/o2xtUjSX8mSGR4kX9jBlrL 8Cw7lL3KKBH9mw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudelkedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkffojghfggfgsedtke ertdertddtnecuhfhrohhmpefhvghrnhgrnhguohcutfgrmhhoshcuoehgrhgvvghnfhho ohesuhelvddrvghuqeenucggtffrrghtthgvrhhnpeekleekjedtheejheekfefggeevvd fgueegffeuveduhfehueegkeeijedvvdejfeenucevlhhushhtvghrufhiiigvpedunecu rfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvvghnfhhoohesuhelvddrvghu X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 7 Oct 2021 15:38:54 -0400 (EDT) From: Fernando Ramos To: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, sean@poorly.run, linux-doc@vger.kernel.org, amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, linux-tegra@vger.kernel.org Subject: [PATCH v3 13/20] drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() [part 2] Date: Thu, 7 Oct 2021 21:37:48 +0200 Message-Id: <20211007193755.29579-14-greenfoo@u92.eu> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20211007193755.29579-1-greenfoo@u92.eu> References: <20211007193755.29579-1-greenfoo@u92.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() NOTE: I separated this change from the rest of modifications to the i915 driver to point out something special explained next. The only difference between the old drm_modeset_{lock,unlock}_all() functions and the new DRM_MODESET_LOCK_ALL_{BEGIN,END}() macros is that the former use a global context stored in dev->mode_config.acquire_ctx while the latter depend on a user provided one (typically in the stack). This means that as long as no one accesses the global dev->mode_config.acquire_ctx context in the block that runs between lock/BEGIN and unlock/END, the code should be equivalent before and after my changes. The only place where I had to take special action to preserve this condition was here, where I need to modify the old call to intel_modeset_setup_hw_state() to use the new stack allocated context structure instead of the global one. Signed-off-by: Fernando Ramos --- drivers/gpu/drm/i915/display/intel_display.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index cb1142447186..670ce17789c6 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -11707,6 +11707,7 @@ int intel_modeset_init_noirq(struct drm_i915_private *i915) int intel_modeset_init_nogem(struct drm_i915_private *i915) { struct drm_device *dev = &i915->drm; + struct drm_modeset_acquire_ctx ctx; enum pipe pipe; struct intel_crtc *crtc; int ret; @@ -11758,10 +11759,10 @@ int intel_modeset_init_nogem(struct drm_i915_private *i915) intel_vga_disable(i915); intel_setup_outputs(i915); - drm_modeset_lock_all(dev); - intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx); + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret); + intel_modeset_setup_hw_state(dev, &ctx); intel_acpi_assign_connector_fwnodes(i915); - drm_modeset_unlock_all(dev); + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret); for_each_intel_crtc(dev, crtc) { struct intel_initial_plane_config plane_config = {}; -- 2.33.0