Re: [PATCH] drm/fbdev-generic: optimize out a redundant assignment clause

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 30, 2023 at 08:57:36AM +0200, Thomas Zimmermann wrote:
Hi

Am 30.03.23 um 06:17 schrieb Lucas De Marchi:
On Wed, Mar 29, 2023 at 11:04:17AM +0200, 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.

using a initializer for the cases it's needed IMO would make these kind
of problems go away, because then the intent is explicit


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

sounds fine to me, but I'd have to take a deeper look later (or when
someone writes the patch).  It seems we'd replicate almost the entire
API to just accomodate the 2 structs.  And the different types will lead
to confusion when one or the other should be used

I think we can split the current interface onto two categories: mapping and I/O. The former would use iosys_map and the latter would use iosys_ptr. And we'd need a helper that turns gets a ptr for a given map.

If I find the tine, I'll probably type up a patch.

yeah, a split would make it better rather than just make iosys_ptr
replace the current cases where we copy the struct. In this case most
places passing a buffer around in the same driver would migrate to
iosys_ptr.

thanks
Lucas De Marchi


Best regards
Thomas


thanks
Lucas De Marchi

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.

Best regards
Thomas

     drm_client_buffer_vunmap(buffer);

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev




--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev






[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux