| Message ID | 20170322083617.13361-10-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 > ===========
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 ===========
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> --- Documentation/gpu/todo.rst | 70 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+)