linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Noralf Trønnes" <noralf@tronnes.org>,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org
Cc: laurent.pinchart@ideasonboard.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support
Date: Fri, 29 Apr 2016 12:50:40 +0000	[thread overview]
Message-ID: <572358A0.8010002@ti.com> (raw)
In-Reply-To: <1461856717-6476-4-git-send-email-noralf@tronnes.org>


[-- Attachment #1.1: Type: text/plain, Size: 2999 bytes --]

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...

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 =).

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-04-29 12:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 15:18 [PATCH v4 0/7] drm: Add fbdev deferred io support to helpers Noralf Trønnes
2016-04-28 15:18 ` [PATCH v4 1/7] drm/udl: Change drm_fb_helper_sys_*() calls to sys_*() Noralf Trønnes
2016-04-28 15:18 ` [PATCH v4 2/7] drm/qxl: " Noralf Trønnes
2016-04-28 15:18 ` [PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support Noralf Trønnes
2016-04-29 12:50   ` Tomi Valkeinen [this message]
2016-04-29 14:47     ` Noralf Trønnes
2016-05-02 14:24       ` Daniel Vetter
2016-04-29 14:55     ` Daniel Vetter
2016-04-29 15:00       ` Tomi Valkeinen
2016-04-29 15:36         ` Daniel Vetter
2016-04-29 15:38           ` Daniel Vetter
2016-04-28 15:18 ` [PATCH v4 4/7] fbdev: fb_defio: Export fb_deferred_io_mmap Noralf Trønnes
2016-04-29 14:07   ` Tomi Valkeinen
2016-04-28 15:18 ` [PATCH v4 5/7] drm/fb-cma-helper: Add fb_deferred_io support Noralf Trønnes
2016-04-28 15:18 ` [PATCH v4 6/7] drm/qxl: Use drm_fb_helper deferred_io support Noralf Trønnes
2016-04-28 15:18 ` [PATCH v4 7/7] drm/udl: " Noralf Trønnes
2016-04-29 14:57 ` [PATCH v4 0/7] drm: Add fbdev deferred io support to helpers Daniel Vetter
2016-05-02 14:26   ` 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=572358A0.8010002@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noralf@tronnes.org \
    /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;
as well as URLs for NNTP newsgroup(s).