Re: [PATCH 09/16] drm/todo: Add tinydrm refactoring ideas

["Noralf Trønnes" <noralf@tronnes.org>]

Den 22.03.2017 09.36, skrev Daniel Vetter:
> Discussed with Noralf on the list a bit.
>
> An open question is tinydrm vs. drm_panel, but until we have a clear
> idea what's really needed in that space, I think it's best to just
> move forward with what we have.
>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---

Thanks Daniel,
Acked-by: Noralf Trønnes <noralf@tronnes.org>


>   Documentation/gpu/todo.rst | 70 ++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 70 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7dc6de07a3bc..479bb040f6d4 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -99,6 +99,30 @@ events for atomic commits correctly. But fixing these bugs is good anyway.
>   
>   Contact: Daniel Vetter, respective driver maintainers
>   
> +Better manual-upload support for atomic
> +---------------------------------------
> +
> +This would be especially useful for tinydrm:
> +
> +- Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the
> +  crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in
> +  __drm_atomic_helper_crtc_duplicate_state().
> +
> +- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_
> +  prefix ofc and using drm_fb_. drm_framebuffer.c makes sense since this
> +  is a function useful to implement the fb->dirty function.
> +
> +- Create a new drm_fb_dirty function which does essentially what e.g.
> +  mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as the
> +  template. But instead of doing a simple full-screen plane update, this new
> +  helper also sets crtc_state->dirty_clip to the right coordinates. And of
> +  course it needs to check whether the fb is actually active (and maybe where),
> +  so there's some book-keeping involved. There's also some good fun involved in
> +  scaling things appropriately. For that case we might simply give up and
> +  declare the entire area covered by the plane as dirty.
> +
> +Contact: Noralf Trønnes, Daniel Vetter
> +
>   Fallout from atomic KMS
>   -----------------------
>   
> @@ -313,5 +337,51 @@ Contact: Daniel Vetter
>   Driver Specific
>   ===============
>   
> +tinydrm
> +-------
> +
> +Tinydrm is the helper driver for really simple fb drivers. The goal is to make
> +those drivers as simple as possible, so lots of room for refactoring:
> +
> +- backlight helpers, probably best to put them into a new drm_backlight.c.
> +  This is because drivers/video is de-facto unmaintained. We could also
> +  move drivers/video/backlight to drivers/gpu/backlight and take it all
> +  over within drm-misc, but that's more work.
> +
> +- spi helpers, probably best put into spi core/helper code. Thierry said
> +  the spi maintainer is fast&reactive, so shouldn't be a big issue.
> +
> +- extract the mipi-dbi helper (well, the non-tinydrm specific parts at
> +  least) into a separate helper, like we have for mipi-dsi already. Or follow
> +  one of the ideas for having a shared dsi/dbi helper, abstracting away the
> +  transport details more.
> +
> +- tinydrm_lastclose could be drm_fb_helper_lastclose. Only thing we need
> +  for that is to store the drm_fb_helper pointer somewhere in
> +  drm_device->mode_config. And then we could roll that out to all the
> +  drivers.
> +
> +- tinydrm_gem_cma_prime_import_sg_table should probably go into the cma
> +  helpers, as a _vmapped variant (since not every driver needs the vmap).
> +  And tinydrm_gem_cma_free_object could the be merged into
> +  drm_gem_cma_free_object().
> +
> +- tinydrm_fb_create we could move into drm_simple_pipe, only need to add
> +  the fb_create hook to drm_simple_pipe_funcs, which would again simplify a
> +  bunch of things (since it gives you a one-stop vfunc for simple drivers).
> +
> +- Quick aside: The unregister devm stuff is kinda getting the lifetimes of
> +  a drm_device wrong. Doesn't matter, since everyone else gets it wrong
> +  too :-)
> +
> +- With the fbdev pointer in dev->mode_config we could also make
> +  suspend/resume helpers entirely generic, at least if we add a
> +  dev->mode_config.suspend_state. We could even provide a generic pm_ops
> +  structure with those.
> +
> +- also rework the drm_framebuffer_funcs->dirty hook wire-up, see above.
> +
> +Contact: Noralf Trønnes, Daniel Vetter
> +
>   Outside DRM
>   ===========

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx