From: Thomas Zimmermann <tzimmermann@suse.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: eric@anholt.net, airlied@linux.ie, sam@ravnborg.org,
dri-devel@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
sumit.semwal@linaro.org, linaro-mm-sig@lists.linaro.org,
hdegoede@redhat.com, virtualization@lists.linux-foundation.org,
sean@poorly.run, christian.koenig@amd.com,
linux-media@vger.kernel.org
Subject: Re: [PATCH v3 2/8] drm/ast: Only map cursor BOs during updates
Date: Fri, 11 Dec 2020 11:49:48 +0100 [thread overview]
Message-ID: <0c628bab-e4e0-170b-e695-abf3cde13c01@suse.de> (raw)
In-Reply-To: <20201211101833.GQ401619@phenom.ffwll.local>
[-- Attachment #1.1.1: Type: text/plain, Size: 7703 bytes --]
Am 11.12.20 um 11:18 schrieb Daniel Vetter:
> On Wed, Dec 09, 2020 at 03:25:21PM +0100, Thomas Zimmermann wrote:
>> The HW cursor's BO used to be mapped permanently into the kernel's
>> address space. GEM's vmap operation will be protected by locks, and
>> we don't want to lock the BO's for an indefinate period of time.
>>
>> Change the cursor code to map the HW BOs only during updates. The
>> vmap operation in VRAM helpers is cheap, as a once estabished mapping
>> is being reused until the BO actually moves. As the HW cursor BOs are
>> permanently pinned, they never move at all.
>>
>> v2:
>> * fix typos in commit description
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Acked-by: Christian König <christian.koenig@amd.com>
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Now there's a pretty big issue here though: We can't take dma_resv_lock in
> commit_tail, because of possible deadlocks on at least gpus that do real
> async rendering because of the dma_fences. Unfortunately my annotations
> patches got stuck a bit, I need to refresh them.
>
> Rules are you can pin and unpin stuff in prepare/cleanup_plane, and also
> take dma_resv_lock there, but not in commit_tail in-between. So I think
> our vmap_local needs to loose the unconditional assert_locked and require
> either that or a pin count.
I guess my commit description is misleading when it speaks of updates.
ast_cursor_blit() is actually called from the cursor plane's prepare_fb
function. [1] The vmap code in ast_cursor_show() could be moved into
blit() as well, I think.
I guess the clean solution is to integrate the cursor code with the
modesetting code in ast_mode. From there, locks and mappings can be
established in prepare_fb and the HW state can be updated in atomic_commit.
Best regards
Thomas
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/ast/ast_mode.c#n646
> -Daniel
>
>> ---
>> drivers/gpu/drm/ast/ast_cursor.c | 51 ++++++++++++++++++--------------
>> drivers/gpu/drm/ast/ast_drv.h | 2 --
>> 2 files changed, 28 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
>> index 68bf3d33f1ed..fac1ee79c372 100644
>> --- a/drivers/gpu/drm/ast/ast_cursor.c
>> +++ b/drivers/gpu/drm/ast/ast_cursor.c
>> @@ -39,7 +39,6 @@ static void ast_cursor_fini(struct ast_private *ast)
>>
>> for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
>> gbo = ast->cursor.gbo[i];
>> - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
>> drm_gem_vram_unpin(gbo);
>> drm_gem_vram_put(gbo);
>> }
>> @@ -53,14 +52,13 @@ static void ast_cursor_release(struct drm_device *dev, void *ptr)
>> }
>>
>> /*
>> - * Allocate cursor BOs and pins them at the end of VRAM.
>> + * Allocate cursor BOs and pin them at the end of VRAM.
>> */
>> int ast_cursor_init(struct ast_private *ast)
>> {
>> struct drm_device *dev = &ast->base;
>> size_t size, i;
>> struct drm_gem_vram_object *gbo;
>> - struct dma_buf_map map;
>> int ret;
>>
>> size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
>> @@ -77,15 +75,7 @@ int ast_cursor_init(struct ast_private *ast)
>> drm_gem_vram_put(gbo);
>> goto err_drm_gem_vram_put;
>> }
>> - ret = drm_gem_vram_vmap(gbo, &map);
>> - if (ret) {
>> - drm_gem_vram_unpin(gbo);
>> - drm_gem_vram_put(gbo);
>> - goto err_drm_gem_vram_put;
>> - }
>> -
>> ast->cursor.gbo[i] = gbo;
>> - ast->cursor.map[i] = map;
>> }
>>
>> return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
>> @@ -94,7 +84,6 @@ int ast_cursor_init(struct ast_private *ast)
>> while (i) {
>> --i;
>> gbo = ast->cursor.gbo[i];
>> - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
>> drm_gem_vram_unpin(gbo);
>> drm_gem_vram_put(gbo);
>> }
>> @@ -168,31 +157,38 @@ static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int h
>> int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
>> {
>> struct drm_device *dev = &ast->base;
>> - struct drm_gem_vram_object *gbo;
>> - struct dma_buf_map map;
>> - int ret;
>> - void *src;
>> + struct drm_gem_vram_object *dst_gbo = ast->cursor.gbo[ast->cursor.next_index];
>> + struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
>> + struct dma_buf_map src_map, dst_map;
>> void __iomem *dst;
>> + void *src;
>> + int ret;
>>
>> if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
>> drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
>> return -EINVAL;
>>
>> - gbo = drm_gem_vram_of_gem(fb->obj[0]);
>> -
>> - ret = drm_gem_vram_vmap(gbo, &map);
>> + ret = drm_gem_vram_vmap(src_gbo, &src_map);
>> if (ret)
>> return ret;
>> - src = map.vaddr; /* TODO: Use mapping abstraction properly */
>> + src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
>>
>> - dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem;
>> + ret = drm_gem_vram_vmap(dst_gbo, &dst_map);
>> + if (ret)
>> + goto err_drm_gem_vram_vunmap;
>> + dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
>>
>> /* do data transfer to cursor BO */
>> update_cursor_image(dst, src, fb->width, fb->height);
>>
>> - drm_gem_vram_vunmap(gbo, &map);
>> + drm_gem_vram_vunmap(dst_gbo, &dst_map);
>> + drm_gem_vram_vunmap(src_gbo, &src_map);
>>
>> return 0;
>> +
>> +err_drm_gem_vram_vunmap:
>> + drm_gem_vram_vunmap(src_gbo, &src_map);
>> + return ret;
>> }
>>
>> static void ast_cursor_set_base(struct ast_private *ast, u64 address)
>> @@ -243,17 +239,26 @@ static void ast_cursor_set_location(struct ast_private *ast, u16 x, u16 y,
>> void ast_cursor_show(struct ast_private *ast, int x, int y,
>> unsigned int offset_x, unsigned int offset_y)
>> {
>> + struct drm_device *dev = &ast->base;
>> + struct drm_gem_vram_object *gbo = ast->cursor.gbo[ast->cursor.next_index];
>> + struct dma_buf_map map;
>> u8 x_offset, y_offset;
>> u8 __iomem *dst;
>> u8 __iomem *sig;
>> u8 jreg;
>> + int ret;
>>
>> - dst = ast->cursor.map[ast->cursor.next_index].vaddr;
>> + ret = drm_gem_vram_vmap(gbo, &map);
>> + if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n", ret))
>> + return;
>> + dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
>>
>> sig = dst + AST_HWC_SIZE;
>> writel(x, sig + AST_HWC_SIGNATURE_X);
>> writel(y, sig + AST_HWC_SIGNATURE_Y);
>>
>> + drm_gem_vram_vunmap(gbo, &map);
>> +
>> if (x < 0) {
>> x_offset = (-x) + offset_x;
>> x = 0;
>> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
>> index ccaff81924ee..f871fc36c2f7 100644
>> --- a/drivers/gpu/drm/ast/ast_drv.h
>> +++ b/drivers/gpu/drm/ast/ast_drv.h
>> @@ -28,7 +28,6 @@
>> #ifndef __AST_DRV_H__
>> #define __AST_DRV_H__
>>
>> -#include <linux/dma-buf-map.h>
>> #include <linux/i2c.h>
>> #include <linux/i2c-algo-bit.h>
>> #include <linux/io.h>
>> @@ -133,7 +132,6 @@ struct ast_private {
>>
>> struct {
>> struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
>> - struct dma_buf_map map[AST_DEFAULT_HWC_NUM];
>> unsigned int next_index;
>> } cursor;
>>
>> --
>> 2.29.2
>>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2020-12-11 10:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 14:25 [PATCH v3 0/8] drm: Support short-term vmap via vmap_local Thomas Zimmermann
2020-12-09 14:25 ` [PATCH v3 1/8] drm/ast: Don't pin cursor source BO explicitly during update Thomas Zimmermann
2020-12-11 10:14 ` Daniel Vetter
2020-12-09 14:25 ` [PATCH v3 2/8] drm/ast: Only map cursor BOs during updates Thomas Zimmermann
2020-12-11 10:18 ` Daniel Vetter
2020-12-11 10:49 ` Thomas Zimmermann [this message]
2020-12-11 13:57 ` Daniel Vetter
2020-12-09 14:25 ` [PATCH v3 3/8] dma-buf: Add vmap_local and vnumap_local operations Thomas Zimmermann
2020-12-09 14:27 ` Thomas Zimmermann
2020-12-11 9:24 ` Daniel Vetter
2020-12-11 14:09 ` Daniel Vetter
2020-12-09 14:25 ` [PATCH v3 4/8] drm/gem: Create infrastructure for GEM vmap_local Thomas Zimmermann
2020-12-11 9:29 ` Daniel Vetter
2020-12-09 14:25 ` [PATCH v3 5/8] drm/cma-helper: Provide a vmap function for short-term mappings Thomas Zimmermann
2020-12-11 9:40 ` Daniel Vetter
2020-12-11 10:02 ` Daniel Vetter
2020-12-09 14:25 ` [PATCH v3 6/8] drm/shmem-helper: " Thomas Zimmermann
2020-12-11 9:50 ` Daniel Vetter
2021-01-07 10:28 ` Thomas Zimmermann
2021-01-07 15:01 ` Daniel Vetter
2020-12-09 14:25 ` [PATCH v3 7/8] drm/vram-helper: " Thomas Zimmermann
2020-12-11 9:57 ` Daniel Vetter
2020-12-09 14:25 ` [PATCH v3 8/8] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker Thomas Zimmermann
2020-12-11 10:01 ` Daniel Vetter
2020-12-11 10:16 ` Thomas Zimmermann
2020-12-11 14:00 ` 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=0c628bab-e4e0-170b-e695-abf3cde13c01@suse.de \
--to=tzimmermann@suse.de \
--cc=airlied@linux.ie \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=hdegoede@redhat.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=sam@ravnborg.org \
--cc=sean@poorly.run \
--cc=sumit.semwal@linaro.org \
--cc=virtualization@lists.linux-foundation.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).