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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox