From: Tony Lindgren <tony@atomide.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Javier Martinez Canillas <javierm@redhat.com>,
Sam Ravnborg <sam@ravnborg.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/omapdrm: Fix console with deferred ops
Date: Tue, 20 Feb 2024 12:16:54 +0200 [thread overview]
Message-ID: <20240220101654.GP5299@atomide.com> (raw)
In-Reply-To: <56475919-7aaf-47d6-8803-ef9c7673857b@suse.de>
* Thomas Zimmermann <tzimmermann@suse.de> [240220 09:32]:
> Am 20.02.24 um 09:56 schrieb Tony Lindgren:
> > Oh right, yes omapdrm is operating on memory.
>
> With the latest kernels, you should see a warning if helpers operate on the
> wrong type of memory. [1][2]
OK
> [1] https://elixir.bootlin.com/linux/v6.8-rc5/source/drivers/video/fbdev/core/fb_io_fops.c#L16
> [2] https://elixir.bootlin.com/linux/v6.8-rc5/source/drivers/video/fbdev/core/fb_sys_fops.c#L26
> > The following test patch works for me.. Not sure about the tracking though.
>
> I know that i915 doesn't track mmap'ed pages correctly and I've see systems
> that do not update the framebuffer. IDK how/why this works with omapdrm.
Sounds like the a similar issue might exist on omapdrm too then.
> > Do you mean that tracking needs to be implemented if fb_deferred_io_mmap()
> > did not work?
>
> omap_fbdev_fb_mmap() appears to mmap the DMA memory pages directly to
> userspace. So the fb_dirty callback won't be invoked when userspace writes
> to this framebuffer memory.
>
> To implement tracking, you'd need to set fb_mmap to fb_deferred_io_mmap().
> If you init omap_fb_ops with FB_DEFAULT_DEFERRED_OPS(), [3] you'd get that
> automatically. fb_deferred_io_mmap() sets up the tracking whenever
> userspaces writes to a mapped page. You also need to init the write-back
> mechanisms that calls fb_dirty for the tracked pages. You should be able to
> duplicate the code from [4] into omapdrm.
OK great. Updated test patch below with FB_DEFAULT_DEFERRED_OPS, maybe that's
all there is to it if I follow you :) The fb_dirty part was already done in
patch 1/2.
> [3] https://elixir.bootlin.com/linux/latest/source/include/linux/fb.h#L704
> [4] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_fbdev_generic.c#L119
Regards,
Tony
8< ---------------------------
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c b/drivers/gpu/drm/omapdrm/omap_fbdev.c
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -51,6 +51,10 @@ static void pan_worker(struct work_struct *work)
omap_gem_roll(bo, fbi->var.yoffset * npages);
}
+FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS(omap_fbdev,
+ drm_fb_helper_damage_range,
+ drm_fb_helper_damage_area)
+
static int omap_fbdev_pan_display(struct fb_var_screeninfo *var,
struct fb_info *fbi)
{
@@ -76,15 +80,6 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo *var,
return drm_fb_helper_pan_display(var, fbi);
}
-static int omap_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
-{
- struct drm_fb_helper *helper = info->par;
- struct drm_framebuffer *fb = helper->fb;
- struct drm_gem_object *bo = drm_gem_fb_get_obj(fb, 0);
-
- return drm_gem_mmap_obj(bo, omap_gem_mmap_size(bo), vma);
-}
-
static void omap_fbdev_fb_destroy(struct fb_info *info)
{
struct drm_fb_helper *helper = info->par;
@@ -94,6 +89,7 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
DBG();
+ fb_deferred_io_cleanup(info);
drm_fb_helper_fini(helper);
omap_gem_unpin(bo);
@@ -106,15 +102,13 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
- __FB_DEFAULT_DMAMEM_OPS_RDWR,
+ FB_DEFAULT_DEFERRED_OPS(omap_fbdev),
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_blank = drm_fb_helper_blank,
.fb_pan_display = omap_fbdev_pan_display,
- __FB_DEFAULT_DMAMEM_OPS_DRAW,
.fb_ioctl = drm_fb_helper_ioctl,
- .fb_mmap = omap_fbdev_fb_mmap,
.fb_destroy = omap_fbdev_fb_destroy,
};
@@ -213,6 +207,15 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
fbi->fix.smem_start = dma_addr;
fbi->fix.smem_len = bo->size;
+ /* deferred I/O */
+ helper->fbdefio.delay = HZ / 20;
+ helper->fbdefio.deferred_io = drm_fb_helper_deferred_io;
+
+ fbi->fbdefio = &helper->fbdefio;
+ ret = fb_deferred_io_init(fbi);
+ if (ret)
+ goto fail;
+
/* if we have DMM, then we can use it for scrolling by just
* shuffling pages around in DMM rather than doing sw blit.
*/
diff --git a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -686,6 +686,10 @@ extern int fb_deferred_io_fsync(struct file *file, loff_t start,
__FB_GEN_DEFAULT_DEFERRED_OPS_RDWR(__prefix, __damage_range, sys) \
__FB_GEN_DEFAULT_DEFERRED_OPS_DRAW(__prefix, __damage_area, sys)
+#define FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS(__prefix, __damage_range, __damage_area) \
+ __FB_GEN_DEFAULT_DEFERRED_OPS_RDWR(__prefix, __damage_range, sys) \
+ __FB_GEN_DEFAULT_DEFERRED_OPS_DRAW(__prefix, __damage_area, sys)
+
/*
* Initializes struct fb_ops for deferred I/O.
*/
--
2.43.1
next prev parent reply other threads:[~2024-02-20 10:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 14:19 [PATCH 1/2] drm/omapdrm: Fix console by implementing fb_dirty Tony Lindgren
2024-02-19 14:19 ` [PATCH 2/2] drm/omapdrm: Fix console with deferred ops Tony Lindgren
2024-02-19 16:43 ` Thomas Zimmermann
2024-02-20 8:56 ` Tony Lindgren
2024-02-20 9:32 ` Thomas Zimmermann
2024-02-20 10:16 ` Tony Lindgren [this message]
2024-02-20 10:42 ` Thomas Zimmermann
2024-02-25 6:44 ` Tony Lindgren
2024-02-19 16:31 ` [PATCH 1/2] drm/omapdrm: Fix console by implementing fb_dirty Thomas Zimmermann
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=20240220101654.GP5299@atomide.com \
--to=tony@atomide.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=sam@ravnborg.org \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=tzimmermann@suse.de \
/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.