From patchwork Thu Aug 8 13:41:15 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 2841140 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 8C5819F295 for ; Thu, 8 Aug 2013 13:53:21 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5DC8B204AD for ; Thu, 8 Aug 2013 13:53:20 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 077F8204AA for ; Thu, 8 Aug 2013 13:53:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D0095E71ED for ; Thu, 8 Aug 2013 06:53:16 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by gabe.freedesktop.org (Postfix) with ESMTP id D3FA2E67E9 for ; Thu, 8 Aug 2013 06:41:40 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id z15so1438298ead.5 for ; Thu, 08 Aug 2013 06:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=aNo4oxQJd4Z+vh5To992yT+vmbFKXT3B5Ug5xiTZmZg=; b=KLHP8WHFMa7Kn3/V1rzipyImLW97fXG2jJZQQfKgp0Nk+Ofw1x6LsdbdU2rd7wIUqb LmGMsJGIWhdFommHbslfDVjpDfm2rmm+beSfybkUbU41fZDAJyVKUFT1YqLgiIlPKbQQ sh9MDCDX6bkP4fE7SmxPTbhy06+b3sdCACGOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=aNo4oxQJd4Z+vh5To992yT+vmbFKXT3B5Ug5xiTZmZg=; b=oPcRcOqPhrrwqPNLYpHmHdkaFk0Eh4bVavv1nVYPs/dHtLIQ4Bf8YLjXYrB8z8rl5a e+l9hBIGOLo59kJqiyv3Sszij4Jj6EB5TJJG6lTW8+N5I74NCEgMy5kSpqcd5sMiCD9o m4vc0QRdbstMsooM+abJTj/CRV7uaBRnERDFXMATwO1RNpwhKQnLm0nT8pIL9kzzAf8S q5NBEOqHDALX12LXxmrNIRIfYkHS5HXMoMcx4Umnk4iq9T/0F28jCGbIEp0nNiJFs8Fd 8edi2saIfRlr3kpcc/TfFhBLUG/4bkY2gSbQvq09JZg/cABxZMioQBZs8xnJeDbkdXgj ANmQ== X-Gm-Message-State: ALoCoQmANcjISWgFRqLOTbMm0AZFmiyyVrVKuNK1lg6d7ldIuOw/NqlU0ytEXmT3TuDjaUehH3tt X-Received: by 10.14.115.133 with SMTP id e5mr8389752eeh.27.1375969300101; Thu, 08 Aug 2013 06:41:40 -0700 (PDT) Received: from phenom.ffwll.local (178-83-130-250.dynamic.hispeed.ch. [178.83.130.250]) by mx.google.com with ESMTPSA id bn13sm19282226eeb.11.2013.08.08.06.41.38 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 06:41:39 -0700 (PDT) From: Daniel Vetter To: DRI Development Subject: [PATCH 05/25] drm: don't call ->firstopen for KMS drivers Date: Thu, 8 Aug 2013 15:41:15 +0200 Message-Id: <1375969295-18929-6-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.8.3.2 In-Reply-To: <1375969295-18929-1-git-send-email-daniel.vetter@ffwll.ch> References: <1375969295-18929-1-git-send-email-daniel.vetter@ffwll.ch> Cc: Daniel Vetter , Laurent Pinchart X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org Errors-To: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,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 It has way too much potential for driver writers to do stupid things like delayed hw setup because the load sequence is somehow racy (e.g. the imx driver in staging). So don't call it for modesetting drivers, which reduces the complexity of the drm core -> driver interface a notch. v2: Don't forget to update DocBook. v3: Go with Laurent's slightly more elaborate proposal for the DocBook update. Add a few words on top of his diff to elaborate a bit on what KMS drivers should and shouldn't do in lastclose. There was already a paragraph present talking about restoring properties, I've simply extended that one. Cc: Laurent Pinchart Acked-by: Laurent Pinchart Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 27 ++++++++++++++++----------- drivers/gpu/drm/drm_fops.c | 3 ++- 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 87e22ec..c62d2d4 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2428,18 +2428,18 @@ void (*postclose) (struct drm_device *, struct drm_file *); The firstopen method is called by the DRM core - when an application opens a device that has no other opened file handle. - Similarly the lastclose method is called when - the last application holding a file handle opened on the device closes - it. Both methods are mostly used for UMS (User Mode Setting) drivers to - acquire and release device resources which should be done in the - load and unload - methods for KMS drivers. + for legacy UMS (User Mode Setting) drivers only when an application + opens a device that has no other opened file handle. UMS drivers can + implement it to acquire device resources. KMS drivers can't use the + method and must acquire resources in the load + method instead. - Note that the lastclose method is also called - at module unload time or, for hot-pluggable devices, when the device is - unplugged. The firstopen and + Similarly the lastclose method is called when + the last application holding a file handle opened on the device closes + it, for both UMS and KMS drivers. Additionally, the method is also + called at module unload time or, for hot-pluggable devices, when the + device is unplugged. The firstopen and lastclose calls can thus be unbalanced. @@ -2468,7 +2468,12 @@ void (*postclose) (struct drm_device *, struct drm_file *); The lastclose method should restore CRTC and plane properties to default value, so that a subsequent open of the - device will not inherit state from the previous user. + device will not inherit state from the previous user. It can also be + used to execute delayed power switching state changes, e.g. in + conjunction with the vga-switcheroo infrastructure. Beyond that KMS + drivers should not do any further cleanup. Only legacy UMS drivers might + need to clean up device state so that the vga console or an independent + fbdev driver could take over. diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 72acae9..10bf4f6 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev) int i; int ret; - if (dev->driver->firstopen) { + if (dev->driver->firstopen && + !drm_core_check_feature(dev, DRIVER_MODESET)) { ret = dev->driver->firstopen(dev); if (ret != 0) return ret;