From patchwork Wed Mar 22 08:36:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 9638257 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 81181602CB for ; Wed, 22 Mar 2017 08:37:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 759472029B for ; Wed, 22 Mar 2017 08:37:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6A9F424603; Wed, 22 Mar 2017 08:37:10 +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=unavailable 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 F1AD42029B for ; Wed, 22 Mar 2017 08:37:09 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E15FD6E80F; Wed, 22 Mar 2017 08:36:37 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id A3AB16E805 for ; Wed, 22 Mar 2017 08:36:30 +0000 (UTC) Received: by mail-wm0-x243.google.com with SMTP id u132so7586253wmg.1 for ; Wed, 22 Mar 2017 01:36:30 -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=cxMegdDbC5GdlZjAGBipswyi2SEJV83iiwmH0yynI1s=; b=Gs7k0zrEBt3a36TWTRPtJQITs2OXzbt5UZGvByT3z+nc8vp2FnVqUDmIL/NOymrQDm 0UO1/Xww5kA83DxpA8XpsY1fAhIJTEMQ2LlYDbWtCtHKZEFB8wOu1uVf7dHuo5quY0J1 YVuPoW/9vdXYK1rYcP23o/Ls5Iknw3WprgvCI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=cxMegdDbC5GdlZjAGBipswyi2SEJV83iiwmH0yynI1s=; b=gfY3Fmx996CEc6FI73fma+Fip8xgjEnyg7qls7CIciurMDEKLZJn/zuNzmEkFgPvFH Jh1odavS2VCIicXCdNAMeBHU05/rb5bg9gAkIgGUjsoA4e3nTSXoe/ToHPY8Ehbn893F 7vrScRCPrY6wArsEgTa9skjZk0Ljv2FgEA6JAtAAuhT9p1FbMxw3dG50k7nalS/NM2Sz ajTIuo+Uuti8UOx2gCfbx9DbgPFEMz7+/r/8XcPK/KPCRzQazFk74ofK7GMckQlkj5Y4 P23F7cUfUyMmSlDmbmCI0Mh6lMIBvZAQ4CwDMABwZ7iQhMGk+dDi+On6A7Nj53fzey9T cmjg== X-Gm-Message-State: AFeK/H3b+xGVSvyud9GtlXcUo/5LqcRs1PPLZ51UivBwJo9lxBr7YEqR8P/2aAeCUZ9/vw== X-Received: by 10.28.132.20 with SMTP id g20mr6735108wmd.68.1490171788956; Wed, 22 Mar 2017 01:36:28 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:56c9:0:decc:6e78:7e96:b452]) by smtp.gmail.com with ESMTPSA id g45sm927438wrd.11.2017.03.22.01.36.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 01:36:28 -0700 (PDT) From: Daniel Vetter To: Intel Graphics Development Date: Wed, 22 Mar 2017 09:36:06 +0100 Message-Id: <20170322083617.13361-6-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170322083617.13361-1-daniel.vetter@ffwll.ch> References: <20170322083617.13361-1-daniel.vetter@ffwll.ch> Cc: Daniel Vetter , DRI Development Subject: [Intel-gfx] [PATCH 05/16] drm: update todo.rst X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP Just drive-by, but we have gsoc running so better to update it now. Great news is that two entries can be removed because essentially all done. Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst | 51 ++++------------------------------------------ 1 file changed, 4 insertions(+), 47 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 9ecd2ebb8dd8..7dc6de07a3bc 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -16,7 +16,7 @@ De-midlayer drivers With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required to have a ``drm_bus`` structure set up. Drivers can directly set up the ``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` -and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` / +and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` / ``->unload`` callbacks and open-code the load/unload sequence properly, using the new two-stage ``drm_device`` setup/teardown. @@ -151,7 +151,7 @@ fine-grained per-buffer object and per-context lockings scheme. Currently the following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and ``udl``. -Contact: Daniel Vetter +Contact: Daniel Vetter, respective driver maintainers Switch to drm_connector_list_iter for any connector_list walking ---------------------------------------------------------------- @@ -193,6 +193,8 @@ plan is to switch to per-file driver API headers, which will also structure the kerneldoc better. This should also allow more fine-grained ``#include`` directives. +In the end no .c file should need to include ``drmP.h`` anymore. + Contact: Daniel Vetter Add missing kerneldoc for exported functions @@ -208,31 +210,6 @@ See https://dri.freedesktop.org/docs/drm/ for what's there already. Contact: Daniel Vetter -Hide legacy cruft better ------------------------- - -Way back DRM supported only drivers which shadow-attached to PCI devices with -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge -of the entire device, you can spot them with the DRIVER_MODESET flag. - -Unfortunately there's still large piles of legacy code around which needs to -be hidden so that driver writers don't accidentally end up using it. And to -prevent security issues in those legacy IOCTLs from being exploited on modern -drivers. This has multiple possible subtasks: - -* Make sure legacy IOCTLs can't be used on modern drivers. -* Extract support code for legacy features into a ``drm-legacy.ko`` kernel - module and compile it only when one of the legacy drivers is enabled. -* Extract legacy functions into their own headers and remove it that from the - monolithic ``drmP.h`` header. -* Remove any lingering cruft from the OS abstraction layer from modern - drivers. - -This is mostly done, the only thing left is to split up ``drm_irq.c`` into -legacy cruft and the parts needed by modern KMS drivers. - -Contact: Daniel Vetter - Make panic handling work ------------------------ @@ -338,23 +315,3 @@ Driver Specific Outside DRM =========== - -Better kerneldoc ----------------- - -This is pretty much done, but there's some advanced topics: - -Come up with a way to hyperlink to struct members. Currently you can hyperlink -to the struct using ``#struct_name``, but not to a member within. Would need -buy-in from kerneldoc maintainers, and the big question is how to make it work -without totally unsightly -``drm_foo_bar_really_long_structure->even_longer_memeber`` all over the text -which breaks text flow. - -Figure out how to integrate the asciidoc support for ascii-diagrams. We have a -few of those (e.g. to describe mode timings), and asciidoc supports converting -some ascii-art dialect into pngs. Would be really pretty to make that work. - -Contact: Daniel Vetter, Jani Nikula - -Jani is working on this already, hopefully lands in 4.8.