[Intel-gfx] [PATCH 01/11] drm: update todo.rst

[Neil Armstrong]

On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> 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.
> 
> v2: Keep a bunch of the todos, Gabriel is working on them.
> 
> Cc: Gabriel Krisman Bertazi <krisman at collabora.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
>  Documentation/gpu/todo.rst | 31 ++++---------------------------
>  1 file changed, 4 insertions(+), 27 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index e255b36b34a3..1bdb7356a310 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.
>  
> @@ -175,7 +175,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
>  ----------------------------------------------------------------
> @@ -217,6 +217,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
> @@ -244,13 +246,8 @@ 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.
> @@ -408,23 +405,3 @@ Contact: Noralf Trønnes, Daniel Vetter
>  
>  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.
> 

Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>