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@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
