On 2023/3/29 17:04, Thomas Zimmermann wrote:
(cc'ing Lucas)
Hi
Am 25.03.23 um 08:46 schrieb Sui Jingfeng:
The assignment already done in drm_client_buffer_vmap(),
just trival clean, no functional change.
Signed-off-by: Sui Jingfeng <15330273260@xxxxxx>
---
drivers/gpu/drm/drm_fbdev_generic.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 4d6325e91565..1da48e71c7f1 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -282,7 +282,7 @@ static int drm_fbdev_damage_blit(struct
drm_fb_helper *fb_helper,
struct drm_clip_rect *clip)
{
struct drm_client_buffer *buffer = fb_helper->buffer;
- struct iosys_map map, dst;
+ struct iosys_map map;
int ret;
/*
@@ -302,8 +302,7 @@ static int drm_fbdev_damage_blit(struct
drm_fb_helper *fb_helper,
if (ret)
goto out;
- dst = map;
- drm_fbdev_damage_blit_real(fb_helper, clip, &dst);
+ drm_fbdev_damage_blit_real(fb_helper, clip, &map);
I see what you're doing and it's probably correct in this case.
But there's a larger issue with this iosys interfaces. Sometimes the
address has to be modified (see calls of iosys_map_incr()). That can
prevent incorrect uses of the mapping in other places, especially in
unmap code.
I think it would make sense to consider a separate structure for the
I/O location. The buffer as a whole would still be represented by
struct iosys_map. And that new structure, let's call it struct
iosys_ptr, would point to an actual location within the buffer's
memory range. A few locations and helpers would need changes, but
there are not so many callers that it's an issue. This would also
allow for a few debugging tests that ensure that iosys_ptr always
operates within the bounds of an iosys_map.
I've long considered this idea, but there was no pressure to work on
it. Maybe now.
Ok. that's fine then.
Best regards
Thomas
drm_client_buffer_vunmap(buffer);
