lkml.org 
[lkml]   [2016]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support
    On Fri, Apr 29, 2016 at 04:47:08PM +0200, Noralf Trønnes wrote:
    >
    > Den 29.04.2016 14:50, skrev Tomi Valkeinen:
    > >Hi,
    > >
    > >On 28/04/16 18:18, Noralf Trønnes wrote:
    > >>This adds deferred io support to drm_fb_helper.
    > >>The fbdev framebuffer changes are flushed using the callback
    > >>(struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
    > >>ensuring that it always runs in process context.
    > >>
    > >>Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
    > >>Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    > >>---
    > >Thanks for the series! Unfortunately I haven't been able to follow the
    > >discussions properly, so I hope my questions haven't been covered earlier.
    > >
    > >>Changes since v3:
    > >>- Don't use forward decl, move drm_fb_helper_dirty_work()
    > >>- Use DIV_ROUND_UP in drm_fb_helper_deferred_io()
    > >>
    > >>Changes since v2:
    > >>- FB_DEFERRED_IO is now always selected by DRM_KMS_FB_HELPER, ifdef removed
    > >>- The drm_clip_rect utility functions are dropped, so open code it
    > >>- docs: use & to denote structs
    > >>
    > >>Changes since v1:
    > >>- Use a dedicated worker to run the framebuffer flushing like qxl does
    > >>- Add parameter descriptions to drm_fb_helper_deferred_io
    > >>
    > >> drivers/gpu/drm/Kconfig | 1 +
    > >> drivers/gpu/drm/drm_fb_helper.c | 103 +++++++++++++++++++++++++++++++++++++++-
    > >> include/drm/drm_fb_helper.h | 15 ++++++
    > >> 3 files changed, 118 insertions(+), 1 deletion(-)
    > >>
    > >>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
    > >>index 9e4f2f1..8e6f34b 100644
    > >>--- a/drivers/gpu/drm/Kconfig
    > >>+++ b/drivers/gpu/drm/Kconfig
    > >>@@ -52,6 +52,7 @@ config DRM_KMS_FB_HELPER
    > >> select FB_CFB_FILLRECT
    > >> select FB_CFB_COPYAREA
    > >> select FB_CFB_IMAGEBLIT
    > >>+ select FB_DEFERRED_IO
    > >> help
    > >> FBDEV helpers for KMS drivers.
    > >>
    > >>diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
    > >>index 855108e..62f849f 100644
    > >>--- a/drivers/gpu/drm/drm_fb_helper.c
    > >>+++ b/drivers/gpu/drm/drm_fb_helper.c
    > >>@@ -84,6 +84,15 @@ static LIST_HEAD(kernel_fb_helper_list);
    > >> * and set up an initial configuration using the detected hardware, drivers
    > >> * should call drm_fb_helper_single_add_all_connectors() followed by
    > >> * drm_fb_helper_initial_config().
    > >>+ *
    > >>+ * If CONFIG_FB_DEFERRED_IO is enabled and &drm_framebuffer_funcs ->dirty is
    > >>+ * set, the drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit}
    > >>+ * functions will accumulate changes and schedule &fb_helper .dirty_work to run
    > >>+ * right away. This worker then calls the dirty() function ensuring that it
    > >>+ * will always run in process context since the fb_*() function could be
    > >>+ * running in atomic context. If drm_fb_helper_deferred_io() is used as the
    > >Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
    > >That sounds like a very bad idea to me...
    >
    > I haven't verified it myself, but took it as fact based on
    > commit: bcb39af4486be07e896fc374a2336bad3104ae0a

    I've added a citation to this commit as the reason why we need to handle
    atomic, to make sure Tomi's question is answered for posterity.
    -Daniel

    >
    > drm/udl: make usage as a console safer
    > Okay you don't really want to use udl devices as your console, but if
    > you are unlucky enough to do so, you run into a lot of schedule while atomic
    > due to printk being called from all sorts of funky places. So check if we
    > are in an atomic context, and queue the damage for later, the next printk
    > should cause it to appear. This isn't ideal, but it is simple, and seems to
    > work okay in my testing here.
    >
    > (dirty area idea came from xenfb)
    >
    > fixes a bunch of sleeping while atomic issues running fbcon on udl devices.
    >
    > Cc: stable@vger.kernel.org
    > Signed-off-by: Dave Airlie <airlied@redhat.com>
    >
    > >If this is only for accumulating changes, I think it may be better to
    > >leave that to the driver as it may have better idea of how to accumulate.
    > >
    > >But, of course, this is a helper, so if all the drivers use this kind of
    > >accumulation, it makes sense =).
    >
    > qxl already accumulates damage this way and upcoming tinydrm also.
    > udl has handled this damage inline except when in_atomic() which results
    > in damage being deferred to the next fb_*() call.
    >
    > It is possible for drivers to have their own fb_*() handling and still
    > use drm_fb_helper_deferred_io().
    >
    >
    > For those who likes details, this is fbcon unblanking which results in a
    > full display update on a 320x240 display, shell with blinking cursor on
    > the last line of the console:
    >
    > [ 5505.164150] drm_fb_helper_dirty: x=152,width=8,y=224,height=16
    > [ 5505.164186] [drm:drm_atomic_state_init] Allocated atomic state b859e400
    > [...more drm atomic msgs...]
    > [ 5505.164713] drm_fb_helper_dirty: x=152,width=8,y=224,height=16
    > [ 5505.164746] [drm:drm_atomic_state_init] Allocated atomic state b859e440
    > [...more drm atomic msgs...]
    > [ 5505.165086] drm_fb_helper_dirty: x=0,width=320,y=0,height=16
    > [ 5505.165153] drm_fb_helper_dirty: x=0,width=320,y=16,height=16
    > [ 5505.165220] drm_fb_helper_dirty: x=0,width=320,y=32,height=16
    > [ 5505.165287] drm_fb_helper_dirty: x=0,width=320,y=48,height=16
    > [ 5505.165354] drm_fb_helper_dirty: x=0,width=320,y=64,height=16
    > [ 5505.165420] drm_fb_helper_dirty: x=0,width=320,y=80,height=16
    > [ 5505.165487] drm_fb_helper_dirty: x=0,width=320,y=96,height=16
    > [ 5505.165553] drm_fb_helper_dirty: x=0,width=320,y=112,height=16
    > [ 5505.165619] drm_fb_helper_dirty: x=0,width=320,y=128,height=16
    > [ 5505.165686] drm_fb_helper_dirty: x=0,width=320,y=144,height=16
    > [ 5505.165752] drm_fb_helper_dirty: x=0,width=320,y=160,height=16
    > [ 5505.165818] drm_fb_helper_dirty: x=0,width=320,y=176,height=16
    > [ 5505.165884] drm_fb_helper_dirty: x=0,width=320,y=192,height=16
    > [ 5505.165949] drm_fb_helper_dirty: x=0,width=320,y=208,height=16
    > [ 5505.165978] drm_fb_helper_dirty: x=0,width=112,y=224,height=16
    > [ 5505.165988] drm_fb_helper_dirty: x=112,width=8,y=224,height=16
    > [ 5505.166002] drm_fb_helper_dirty: x=120,width=24,y=224,height=16
    > [ 5505.166041] drm_fb_helper_dirty: x=144,width=176,y=224,height=16
    > [ 5505.166058] drm_fb_helper_dirty: x=152,width=8,y=224,height=16
    > [ 5505.166079] drm_fb_helper_dirty: x=152,width=8,y=224,height=16
    > [ 5505.166424] drm_fb_helper_dirty_work: x1=0,x2=320,y1=0,y2=240
    > [ 5505.166452] adafruit-tft spi0.0: mipi_dbi_dirtyfb: vmem=bac40000, x1=0,
    > x2=320, y1=0, y2=240
    >
    > Cursor blinking:
    >
    > [ 5505.363478] drm_fb_helper_dirty: x=152,width=8,y=224,height=16
    > [ 5505.363509] drm_fb_helper_dirty_work: x1=152,x2=160,y1=224,y2=240
    > [ 5505.363539] adafruit-tft spi0.0: mipi_dbi_dirtyfb: vmem=bac40000, x1=152,
    > x2=160, y1=224, y2=240
    >
    > [ 5505.563488] drm_fb_helper_dirty: x=152,width=8,y=224,height=16
    > [ 5505.563514] drm_fb_helper_dirty_work: x1=152,x2=160,y1=224,y2=240
    > [ 5505.563542] adafruit-tft spi0.0: mipi_dbi_dirtyfb: vmem=bac40000, x1=152,
    > x2=160, y1=224, y2=240
    >
    >
    > Noralf.
    >
    >

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

    \
     
     \ /
      Last update: 2016-05-02 16:41    [W:5.865 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site