From patchwork Fri Aug 12 20:48:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 9277911 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 44C4D60231 for ; Fri, 12 Aug 2016 20:49:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 36D6A28AEE for ; Fri, 12 Aug 2016 20:49:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2BAC928AF2; Fri, 12 Aug 2016 20:49:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id C8DB428AEE for ; Fri, 12 Aug 2016 20:49:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 90E056EC30; Fri, 12 Aug 2016 20:49:15 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0EE0B6EC2C for ; Fri, 12 Aug 2016 20:49:12 +0000 (UTC) Received: by mail-wm0-x241.google.com with SMTP id i5so5039589wmg.2 for ; Fri, 12 Aug 2016 13:49:11 -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=sUOaYMV280dID3Gyfs3Vco3lTI2/Aj+MJq/XMgQzj2o=; b=NFI7MJ4/6pzD4FKUFWHazsD3hRBqs7mi25k4Vp47ombnIRmBQhX+vTxJqghx8Mo9Je ZjP6V9zcbad+GTQ6+dDE5T54lFOQdPZLv7WM1BQnuR5ZcKXXH1EBH7BtHOQF4os7GZFi vKNTo0LxOBk5b9mfi3wXbwDG68VFJN/aOVsgQ= 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:in-reply-to :references; bh=sUOaYMV280dID3Gyfs3Vco3lTI2/Aj+MJq/XMgQzj2o=; b=DL9806Go6aOMizhfPy2X2vMykv3a7KGTptIwxAg3YW/Tc3y2uYlYfQ/lHtE9GYZRdw Dxx1v0zwPDeVw+Md6JaImYOR4Q2IIvHhgxV7+F2Cx5PnbsS7DdFF6RIVr+TNxxCxitzV uHRa/5KwciKntsYx1WiV1bjvy/Ogln09vN3G0SSa/buB+QhhX8kF418IRMz0o6k0U+Yy x9rbbLX4QaPjQQFVxxL+QazjHwYFhvzo9OqAMr5eR73GUWsaZWG/oi9XcELdbew0odNG HYQn742Y37zA4h7YIr+krKjFy3zXnwi/rB+zzIqo4CGyJBAamTtDKL/O/enLLZv1hoTp NZeQ== X-Gm-Message-State: AEkoout2qiq1duAWuwMUAkAWRW5e71ya1HwMHdkdHSCeMmQ0WAdcgwQ4d+IrogreSr6IJQ== X-Received: by 10.28.104.137 with SMTP id d131mr808121wmc.7.1471034950643; Fri, 12 Aug 2016 13:49:10 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:56b5:0:ac27:b86c:7764:9429]) by smtp.gmail.com with ESMTPSA id s184sm4101485wmb.11.2016.08.12.13.49.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 13:49:09 -0700 (PDT) From: Daniel Vetter To: DRI Development Subject: [PATCH 05/21] drm/doc: Reorg for drm-kms.rst Date: Fri, 12 Aug 2016 22:48:41 +0200 Message-Id: <1471034937-651-5-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.8.1 In-Reply-To: <1471034937-651-1-git-send-email-daniel.vetter@ffwll.ch> References: <1471034937-651-1-git-send-email-daniel.vetter@ffwll.ch> Cc: Daniel Vetter , Daniel Vetter 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-Virus-Scanned: ClamAV using ClamSMTP - Again adjust headings a bit, and don't mix up the initialization sections with other stuff. - Remove the doc for output polling, that vfunc is now properly documented in the vfunc reference sections. - Move the grab-bag with all the core stuff (i.e. drm_crtc.[hc]) to the front for a more prominent place. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 50 ++++++++++++++++--------------------------- 1 file changed, 19 insertions(+), 31 deletions(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 8dfa4b214b96..c92afa82b130 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -2,9 +2,6 @@ Kernel Mode Setting (KMS) ========================= -Mode Setting -============ - Drivers must initialize the mode setting core by calling :c:func:`drm_mode_config_init()` on the DRM device. The function initializes the :c:type:`struct drm_device ` @@ -18,17 +15,20 @@ be setup by initializing the following fields. - struct drm_mode_config_funcs \*funcs; Mode setting functions. -Display Modes Function Reference --------------------------------- +KMS Data Structures +=================== -.. kernel-doc:: include/drm/drm_modes.h +.. kernel-doc:: include/drm/drm_crtc.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_modes.c +KMS API Functions +================= + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c :export: Atomic Mode Setting Function Reference --------------------------------------- +====================================== .. kernel-doc:: drivers/gpu/drm/drm_atomic.c :export: @@ -37,7 +37,7 @@ Atomic Mode Setting Function Reference :internal: Frame Buffer Abstraction ------------------------- +======================== Frame buffers are abstract memory objects that provide a source of pixels to scanout to a CRTC. Applications explicitly request the @@ -65,13 +65,13 @@ drivers can manually clean up a framebuffer at module unload time with :c:func:`drm_framebuffer_unregister_private()`. DRM Format Handling -------------------- +=================== .. kernel-doc:: drivers/gpu/drm/drm_fourcc.c :export: Dumb Buffer Objects -------------------- +=================== The KMS API doesn't standardize backing storage object creation and leaves it to driver-specific ioctls. Furthermore actually creating a @@ -114,14 +114,14 @@ Note that dumb objects may not be used for gpu acceleration, as has been attempted on some ARM embedded platforms. Such drivers really must have a hardware-specific ioctl to allocate suitable buffer objects. -Output Polling --------------- +Display Modes Function Reference +================================ + +.. kernel-doc:: include/drm/drm_modes.h + :internal: -void (\*output_poll_changed)(struct drm_device \*dev); -This operation notifies the driver that the status of one or more -connectors has changed. Drivers that use the fb helper can just call the -:c:func:`drm_fb_helper_hotplug_event()` function to handle this -operation. +.. kernel-doc:: drivers/gpu/drm/drm_modes.c + :export: KMS Initialization and Cleanup ============================== @@ -463,20 +463,8 @@ created for fetching EDID data and performing monitor detection. Once the process is complete, the new connector is registered with sysfs to make its properties available to applications. -KMS API Functions ------------------ - -.. kernel-doc:: drivers/gpu/drm/drm_crtc.c - :export: - -KMS Data Structures -------------------- - -.. kernel-doc:: include/drm/drm_crtc.h - :internal: - KMS Locking ------------ +=========== .. kernel-doc:: drivers/gpu/drm/drm_modeset_lock.c :doc: kms locking