[PATCH] drm/Documentation: Refine TODO for backlight helpers in tinydrm

[Daniel Vetter]

On Wed, Sep 27, 2017 at 04:21:23PM +0530, Meghana Madhyastha wrote:
> Add a summary which resulted from discussions on what should
> be done to refactor backlight helpers in tinydrm so that
> they can be used in other drivers as well.
> 
> Signed-off-by: Meghana Madhyastha <meghana.madhyastha at gmail.com>

Applied, thanks.

One thing that just crossed my mind is that we could still move
tinydrm_of_find_backlight into drm_of.c (and rename to
drm_of_find_backlight). Plus check out all other drivers for similar code.

That should be a much more well defined task, suitable for the application
period. Signed up?

Thanks, Daniel

> ---
>  Documentation/gpu/todo.rst | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 22af55d..1acf84fe 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -353,7 +353,16 @@ 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.
> +  over within drm-misc, but that's more work. Backlight helpers require a fair
> +  bit of reworking and refactoring. A simple example is the enabling of a backlight.
> +  Tinydrm has helpers for this. It would be good if other drivers can also use the
> +  helper. However, there are various cases we need to consider i.e different
> +  drivers seem to have different ways of enabling/disabling a backlight.
> +  We also need to consider the backlight drivers (like gpio_backlight). The situation
> +  is further complicated by the fact that the backlight is tied to fbdev
> +  via fb_notifier_callback() which has complicated logic. For further details, refer
> +  to the following discussion thread:
> +  https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA
>  
>  - 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.
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch