Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1731713rwl; Thu, 30 Mar 2023 00:18:17 -0700 (PDT) X-Google-Smtp-Source: AKy350ZGSq293OXpaAJ/Jlv8XLoCC/9E48YmvboJwrCK0tXj+bqChJOwr5QT+qYebUlPaXRjsS81 X-Received: by 2002:a05:6402:34c6:b0:502:92d:4f50 with SMTP id w6-20020a05640234c600b00502092d4f50mr1813956edc.1.1680160696762; Thu, 30 Mar 2023 00:18:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680160696; cv=none; d=google.com; s=arc-20160816; b=NV6Nyfz0PJncor6lhfhMroWmBrcnNlbw80EaJuhKAWMpgIHZSUY9f5CARvmLcBMWdZ mbN8eEOOEzeUjikAUqbi06fpCR+dSg3v+3GHXjF2MfCjN87igmPOblvb8nm2mfnhw+0+ bSWi3VmTMrVYTJJk7B2BKoQ1UGy/Wcxkj1yrhXySEorhAhj9PEHoN6rcSrZuCBZGQ1Gv WhF0UqPgjmOt+6eNDV04qUAS+UtH5TofGysV5rEexRBkGIY2y/mWOEBe3l/CVey77uK0 a3S37oNeI85WMZ/AwkCHZ5uB5VTPmDggs2CY3KwhBZH/xx4SeiowTGe6xTCYL2LDOfed BMQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:sender:hmm_source_type:hmm_attache_num :hmm_source_ip; bh=qfOvedPmaVSmJjZlPB5jHIZLl50iqJbx1qvZBBP2lFo=; b=fUuui8AqbK5wmWGY1fd9Harb1W16rSVM5AKnSKuVhpNHaqffTlkUSRCU4Ie5hvyOFn 1XxFWnT0R2pJDttNnbbhlvF2bzOeCMIiaSylnfuvTf0RjJK24FSy3KzPA5v6HgBtAdLz B2nHzTclmijb2KVl2zaAPA8tqvfWkw+9kd0x3MO5wTuTgyNSDKqvHh4pPTqGHK7axh0H mDOL6THYpm7XRmteI+jkZJcWBG5gyAImuHzh0XH01Xhhb3n1nAbEKVb46V/VuNlIlrEy aiDBWFyoLlqCkDkQ4kl/kPb2kUXtAw/OmITlNHuegt/KzzDCMUq9V4L618FbDhAp64Jl 1Qug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k14-20020a05640212ce00b004fe961ba207si38134646edx.236.2023.03.30.00.17.51; Thu, 30 Mar 2023 00:18:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230403AbjC3HRk (ORCPT + 99 others); Thu, 30 Mar 2023 03:17:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbjC3HRj (ORCPT ); Thu, 30 Mar 2023 03:17:39 -0400 Received: from 189.cn (ptr.189.cn [183.61.185.104]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C9CA1E4 for ; Thu, 30 Mar 2023 00:17:37 -0700 (PDT) HMM_SOURCE_IP: 10.64.8.41:52436.1038174395 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-114.242.206.180 (unknown [10.64.8.41]) by 189.cn (HERMES) with SMTP id 291B51004BF; Thu, 30 Mar 2023 15:17:36 +0800 (CST) Received: from ([114.242.206.180]) by gateway-151646-dep-7b48884fd-ljp89 with ESMTP id 6b506376444e4fc7abb957a239188155 for tzimmermann@suse.de; Thu, 30 Mar 2023 15:17:37 CST X-Transaction-ID: 6b506376444e4fc7abb957a239188155 X-Real-From: 15330273260@189.cn X-Receive-IP: 114.242.206.180 X-MEDUSA-Status: 0 Sender: 15330273260@189.cn Message-ID: <2e6ec82f-dfde-0f3a-7980-136cea161d6b@189.cn> Date: Thu, 30 Mar 2023 15:17:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] drm/fbdev-generic: optimize out a redundant assignment clause Content-Language: en-US To: Thomas Zimmermann , Lucas De Marchi Cc: David Airlie , liyi , linux-kernel@vger.kernel.org, Sui Jingfeng <15330273260@189.cn>, dri-devel@lists.freedesktop.org References: <20230325074636.136833-1-15330273260@189.cn> <20230330041726.w7boceq7ljymvfq2@ldmartin-desk2> From: Sui Jingfeng <15330273260@189.cn> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.6 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FROM_LOCAL_DIGITS,FROM_LOCAL_HEX,NICE_REPLY_A, SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2023/3/30 14:57, 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@189.cn> >>>> --- >>>>  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. >  Here i fix a typo, 'tine' -> 'time' As far as i can see, they are two major type of memory in the system. System memory or VRAM,  for the gpu with dedicate video ram, VRAM is belong to the IO memory category. But there are system choose carveout part of system ram as video ram(i915?,  for example). the name iosys_map and iosys_ptr have no difference at the first sight, tell me which one is for mapping system ram and which one is for mapping vram? > 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 >> >> >> >