From patchwork Mon Mar 2 15:35:20 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 5914561 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 7B3D8BF440 for ; Mon, 2 Mar 2015 15:35:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 98E1520218 for ; Mon, 2 Mar 2015 15:35:37 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id CF297201F2 for ; Mon, 2 Mar 2015 15:35:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A441F6E480; Mon, 2 Mar 2015 07:35:31 -0800 (PST) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by gabe.freedesktop.org (Postfix) with ESMTP id C52296E47C for ; Mon, 2 Mar 2015 07:35:29 -0800 (PST) Received: by wevk48 with SMTP id k48so34082069wev.3 for ; Mon, 02 Mar 2015 07:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id; bh=Ork6G15x5Zzvr2H+IqMMp+8Pdss8S5OuL7pLQPOAKTM=; b=VVFiN4ycYqGyYHtr+8wVoQQ9n2r5g3qHDfAVG6cFS40lcgNpwbDPApmnHDOEqMWO25 mStaMf3RYmOITPdK8V3iPsrcFYZYgLU2hHOrbAhHhLWMMEGwYz+ePenkpWmHszbQ8B6s Co4PMF5nF1kxim/z8kiW31WUXNRdqQZP+WP5g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Ork6G15x5Zzvr2H+IqMMp+8Pdss8S5OuL7pLQPOAKTM=; b=Iu7lw/J/euQyisdvUxxKDD9S+ifil+UvlQK1mCrP9+1V9uUjegvfQl6vlssyzylSdS zLzAlr7Pz8bEXfKdhySC7Tki0nHllUfRVHXGMf04gr29tyjjUtq+NUTw+xc43ltsryoP PKOBG7U82Hn5HYjj/T4d/aenWosoRVB0uvUtxmBRvt7d3Br7fACGD/XfUs0IZMigt/lU czAL7vgCFaaK9saVSEQUOufFKDlznKtfdPhz3Vpzo0OMChm8NmT5wzj92055NQ2u3vhA e10Qrnv0m6CrHZDFqAXDZqx5Aal/EkOs+dUCbbyAyywqW4v9CGlJmsEC5T14Me3Xrhes RwJQ== X-Gm-Message-State: ALoCoQlo6HNcY5En/PZPu+bjKuSD7/RRmB4Bhy+b/G4EJEQwcIMytVucnjv9M3CZlugJoFLxnGEq X-Received: by 10.180.81.7 with SMTP id v7mr37257341wix.27.1425310528833; Mon, 02 Mar 2015 07:35:28 -0800 (PST) Received: from gina.ffwll.local (212-51-149-109.fiber7.init7.net. [212.51.149.109]) by mx.google.com with ESMTPSA id gz3sm16556029wib.1.2015.03.02.07.35.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 07:35:27 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development Subject: [PATCH] Revert "drm/i915: Switch planes from transitional helpers to full atomic helpers" Date: Mon, 2 Mar 2015 16:35:20 +0100 Message-Id: <1425310520-3421-1-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.8.4.rc3 Cc: Paul Bolle , Daniel Vetter , LKML , DRI Development , Daniel Vetter , Linus Torvalds X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This reverts commit 3f678c96abb43a977d2ea41aefccdc49e8a3e896. We've been a bit too optimistic with this one here :( The trouble is that internally we're still using these plane update/disable hooks. Which was totally ok pre-atomic since the drm core did all the book-keeping updating and these just mostly updated hw state. But with atomic there's lots more going on, and it causes heaps of trouble with the load detect code. This one specifically cause a deadlock since both the load detect code and the nested plane atomic helper functions tried to grab the same locks. It only blows up because of the evil tricks though we play with the implicit ww acquire context. Applying this revert unearths the NULL deref on already freed framebuffer objects reported as a regression in 4.0 by various people. Fixing this will be fairly invasive, hence revert even for the 4.1-next queue. Cc: Matt Roper Cc: Linus Torvalds Cc: Paul Bolle Signed-off-by: Daniel Vetter --- Just to make it really clear: This is 4.1-next material. It's simply the explanation for why we didn't notice the oops ourselves. The 4.0 oops itself looks like some glue lacking in the load detect code, still working on that one. -Daniel --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3156d77b2215..cc3305e30c1b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12179,8 +12179,8 @@ void intel_plane_destroy(struct drm_plane *plane) } const struct drm_plane_funcs intel_plane_funcs = { - .update_plane = drm_atomic_helper_update_plane, - .disable_plane = drm_atomic_helper_disable_plane, + .update_plane = drm_plane_helper_update, + .disable_plane = drm_plane_helper_disable, .destroy = intel_plane_destroy, .set_property = drm_atomic_helper_plane_set_property, .atomic_get_property = intel_plane_atomic_get_property,