All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Noralf Trønnes" <noralf@tronnes.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: thomas.petazzoni@free-electrons.com, dri-devel@lists.freedesktop.org
Subject: Re: [RFC v2 1/8] drm/fb-helper: Add fb_deferred_io support
Date: Mon, 18 Apr 2016 17:15:03 +0200	[thread overview]
Message-ID: <5714F9F7.2020409@tronnes.org> (raw)
In-Reply-To: <20160413110931.GZ2510@phenom.ffwll.local>


Den 13.04.2016 13:09, skrev Daniel Vetter:
> On Fri, Apr 08, 2016 at 07:05:03PM +0200, Noralf Trønnes wrote:
>> This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
>> Accumulated fbdev framebuffer changes are signaled using the callback
>> (struct drm_framebuffer_funcs *)->dirty()
>>
>> The drm_fb_helper_sys_*() functions will accumulate changes and
>> schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
>> This worker is used by the deferred io mmap code to signal that it
>> has been collecting page faults. The page faults and/or other changes
>> are then merged into a drm_clip_rect and passed to the framebuffer
>> dirty() function.
>>
>> The driver is responsible for setting up the fb_info.fbdefio structure
>> and calling fb_deferred_io_init() using the provided callback:
>> (struct fb_info *)->fbdefio->deferred_io = drm_fb_helper_deferred_io;
>>
>> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
> For this one it'd be awesome to throw patches for qxl/udl on top to remove
> their own hand-rolled implementations. Just to maximize the testing
> coverage of this new code. Should be doable to set up a qxl virtual
> machine quickly, but even without that we should be able to pull it in
> (since it's mostly just about removing code from these two drivers).

There are three fb_deferred_io users in drivers/gpu/drm: qxl, udl and 
vmwgfx.

drivers/gpu/drm/vmwgfx
It doesn't use drm_fb_helper (uses the cfb_{fillrect,copyarea,imageblit}
functions directly). This made me think that I should probably add
fb_deferred_io support to drm_fb_helper_cfb_*() as well.

drivers/gpu/drm/udl
First of all it has had deferred io disabled by default since 2013
(commit 677d23b). Secondly it handles damage directly in it's
fb_{fillrect,copyarea,imageblit} functions, but defers to the next call if
it is in atomic context. My patch always defers those function to a worker.
The driver uses the drm_fb_helper_sys_* functions, so my patch would mess
it up if someone would enable deferred io (module_param: fb_defio).
So this driver isn't a good candidate for easy conversion also because it
has different code paths for fbdev mmap damage and the other damages
(although the code is similar). But it needs a patch to use the sys_*()
functions directly.

drivers/gpu/drm/qxl
This one uses a worker as a buffer between the mmap damage tracking and
fb_*() functions, and flushing of the changes. I'll give it a go.

Studying these in detail and looking at the git log was useful as it showed
me that the (struct fb_ops *)->fb_*() functions can be called in interrupt
context. This means that I need the irq version of spin_lock(). It also
validates my choice to defer these calls using the mmap defer damage worker
((struct fb_info).deferred_work), because it ensures that the dirty() call
will always run in process context.


Noralf.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-04-18 15:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-08 17:05 [RFC v2 0/8] drm: Add support for tiny LCD displays Noralf Trønnes
2016-04-08 17:05 ` [RFC v2 1/8] drm/fb-helper: Add fb_deferred_io support Noralf Trønnes
2016-04-13 10:57   ` Daniel Vetter
2016-04-13 11:09   ` Daniel Vetter
2016-04-18 15:15     ` Noralf Trønnes [this message]
2016-04-20 11:12       ` Daniel Vetter
2016-04-20 15:22         ` Noralf Trønnes
2016-04-20 22:29       ` Dave Airlie
2016-04-21  6:53         ` Daniel Vetter
2016-04-08 17:05 ` [RFC v2 2/8] drm/fb-cma-helper: " Noralf Trønnes
2016-04-13 11:19   ` Daniel Vetter
2016-04-08 17:05 ` [RFC v2 3/8] drm: Add helper for simple kms drivers Noralf Trønnes
2016-04-13 11:05   ` Daniel Vetter
2016-05-02 15:55     ` Noralf Trønnes
2016-05-02 20:20       ` Daniel Vetter
2016-04-08 17:05 ` [RFC v2 4/8] drm: Add DRM support for tiny LCD displays Noralf Trønnes
2016-04-08 17:05 ` [RFC v2 5/8] drm/tinydrm: Add lcd register abstraction Noralf Trønnes
2016-04-08 17:05 ` [RFC v2 6/8] drm/tinydrm/lcdreg: Add SPI support Noralf Trønnes
2016-04-08 17:05 ` [RFC v2 7/8] drm/tinydrm: Add mipi-dbi support Noralf Trønnes
2016-04-08 17:05 ` [RFC v2 8/8] drm/tinydrm: Add support for several Adafruit TFT displays Noralf Trønnes
2016-04-13 11:11 ` [RFC v2 0/8] drm: Add support for tiny LCD displays Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5714F9F7.2020409@tronnes.org \
    --to=noralf@tronnes.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=thomas.petazzoni@free-electrons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.