From patchwork Tue May 13 15:30:50 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thierry Reding X-Patchwork-Id: 348401 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 8AADA1400D4 for ; Wed, 14 May 2014 01:33:43 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753409AbaEMPdm (ORCPT ); Tue, 13 May 2014 11:33:42 -0400 Received: from mail-ee0-f48.google.com ([74.125.83.48]:40291 "EHLO mail-ee0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754535AbaEMPdG (ORCPT ); Tue, 13 May 2014 11:33:06 -0400 Received: by mail-ee0-f48.google.com with SMTP id e49so538601eek.35 for ; Tue, 13 May 2014 08:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=TQ3ezS6V6s5lhI8dcUDIRAYe7DnOgHsZYqOnpztvk/0=; b=uRO0NwxkBRNbAJdB/9JtB+HAykBXEoxhrWKGE6cPBs6tTtzCLQjNH08PsrN4mkkzD/ f+5V+fuCf0qDQEzsEapt9J15ob4fZSwJmpuPjKf+HX1EqUvcpFUvckvzSuF1vlPcvVWm qeCsutzA/fjazZkPfbMKhJH/Cnj9Q8vrP1zJZOxGD4vlMTsus3uOoieYoKrZmbPxS2EG BicaxVokQSjwvuVJJ4jnkvVIedD5i4L1edvBa6tt6srXRAUvcVRZXBB93zWOGRIDW/lV aa28yjZRgsd2wBLXyUU7vUbk83Zjj5rChqo44muoyoE5liMvFpKRY+/UnspjOQz4BqGf 6IMw== X-Received: by 10.14.225.73 with SMTP id y49mr42223677eep.43.1399995184090; Tue, 13 May 2014 08:33:04 -0700 (PDT) Received: from localhost (port-31899.pppoe.wtnet.de. [46.59.175.115]) by mx.google.com with ESMTPSA id m44sm40954443eeh.14.2014.05.13.08.33.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 May 2014 08:33:03 -0700 (PDT) From: Thierry Reding To: Greg Kroah-Hartman , Russell King , dri-devel@lists.freedesktop.org Cc: Daniel Vetter , Rob Clark , David Herrmann , Philipp Zabel , Sascha Hauer , linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 7/7] drm: Document how to register devices without struct drm_bus Date: Tue, 13 May 2014 17:30:50 +0200 Message-Id: <1399995050-28435-8-git-send-email-thierry.reding@gmail.com> X-Mailer: git-send-email 1.9.2 In-Reply-To: <1399995050-28435-1-git-send-email-thierry.reding@gmail.com> References: <1399995050-28435-1-git-send-email-thierry.reding@gmail.com> Sender: linux-tegra-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org From: Thierry Reding With the recent addition of the drm_set_unique() function, devices can now be registered without requiring a drm_bus. Add a brief description to the DRM docbook to show how that can be achieved. Signed-off-by: Thierry Reding --- Documentation/DocBook/drm.tmpl | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index f26a8e4fbe47..f48227caf41a 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -142,6 +142,12 @@ to register it with the DRM subsystem. + Newer drivers that no longer require a drm_bus + structure can alternatively use the low-level device initialization and + registration functions such as drm_dev_alloc() and + drm_dev_register() directly. + + The drm_driver structure contains static information that describes the driver and features it supports, and pointers to methods that the DRM core will call to implement the DRM API. @@ -290,6 +296,29 @@ char *date; !Fdrivers/gpu/drm/drm_pci.c drm_pci_init drm_pci_exit !Fdrivers/gpu/drm/drm_usb.c drm_usb_init drm_usb_exit !Fdrivers/gpu/drm/drm_platform.c drm_platform_init + + New drivers that no longer rely on the services provided by the + drm_bus structure can call the low-level + device registration functions directly. The + drm_dev_alloc() function can be used to allocate + and initialize a new drm_device structure. + Drivers will typically want to perform some additional setup on this + structure, such as allocating driver-specific data and storing a + pointer to it in the DRM device's dev_private + field. Drivers should also set the device's unique name using the + drm_set_unique() function. After it has been set up + a device can be registered with the DRM subsystem by calling + drm_dev_register(). This will cause the device to + be exposed to userspace and will call the driver's + .load() implementation. When a device is + removed, the DRM device can safely be unregistered and freed using a + call to drm_put_dev(). + +!Fdrivers/gpu/drm/drm_stub.c drm_dev_alloc +!Fdrivers/gpu/drm/drm_stub.c drm_set_unique +!Fdrivers/gpu/drm/drm_stub.c drm_dev_register +!Fdrivers/gpu/drm/drm_stub.c drm_put_dev + Driver Load