Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: michael.cheng@intel.com, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, siva.mullati@intel.com
Subject: Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/guc: use the memcpy_from_wc call from the drm
Date: Tue, 22 Mar 2022 19:21:29 +0530	[thread overview]
Message-ID: <YjnUYfBkLA5XAcAm@bvivekan-mobl.gar.corp.intel.com> (raw)
In-Reply-To: <20220321211407.ujlokc44jx4kbtvo@ldmartin-desk2>

On 21.03.2022 14:14, Lucas De Marchi wrote:
> On Thu, Mar 03, 2022 at 11:30:10PM +0530, Balasubramani Vivekanandan wrote:
> > memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
> > by the implementation in drm_cache.c.
> > Updated to use the functions provided by drm_cache.c.
> > 
> > v2: Check if the log object allocated from local memory or system memory
> >    and according setup the iosys_map (Lucas)
> > 
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > 
> > Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 15 ++++++++++++---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > index a24dc6441872..b9db765627ea 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > @@ -3,6 +3,7 @@
> >  * Copyright © 2014-2019 Intel Corporation
> >  */
> > 
> > +#include <drm/drm_cache.h>
> > #include <linux/debugfs.h>
> > #include <linux/string_helpers.h>
> > 
> > @@ -206,6 +207,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log *log)
> > 	enum guc_log_buffer_type type;
> > 	void *src_data, *dst_data;
> > 	bool new_overflow;
> > +	struct iosys_map src_map;
> > 
> > 	mutex_lock(&log->relay.lock);
> > 
> > @@ -282,14 +284,21 @@ static void guc_read_update_log_buffer(struct intel_guc_log *log)
> > 		}
> > 
> > 		/* Just copy the newly written data */
> > +		if (i915_gem_object_is_lmem(log->vma->obj))
> > +			iosys_map_set_vaddr_iomem(&src_map, (void __iomem *)src_data);
> > +		else
> > +			iosys_map_set_vaddr(&src_map, src_data);
> 
> It would be better to keep this outside of the loop. So inside the loop
> we can use only iosys_map_incr(&src_map, buffer_size). However you'd
> also have to handle the read_offset. The iosys_map_ API has both a
> src_offset and dst_offset due to situations like that. Maybe this is
> missing in the new drm_memcpy_* function you're adding?
> 
> This function was not correct wrt to IO memory access with the other
> 2 places in this function doing plain memcpy(). Since we are starting to
> use iosys_map here, we probably should handle this commit as "migrate to
> iosys_map", and convert those. In your current final state
> we have 3 variables aliasing the same memory location. IMO it will be
> error prone to keep it like that
yes, it is a good suggestion to completely change the reading of the GuC
log for the relay to use the iosys_map interfaces.
Though it was planned eventually, doing it now with this series will
avoid mixing of memcpy() and drm_memcpy_*(which needs iosys_map
parameters) functions.
I will do the changes.
> 
> +Michal, some questions:
> 
> - I'm not very familiar with the relayfs API. Is the `dst_data += PAGE_SIZE;`
> really correct?
> 
> - Could you double check this patch and ack if ok?
> 
> Heads up that since the log buffer is potentially in lmem, we will need
> to convert this function to take that into account. All those accesses
> to log_buf_state need to use the proper kernel abstraction for system vs
> I/O memory.
> 
> thanks
> Lucas De Marchi
> 
> > +
> > 		if (read_offset > write_offset) {
> > -			i915_memcpy_from_wc(dst_data, src_data, write_offset);
> > +			drm_memcpy_from_wc_vaddr(dst_data, &src_map,
> > +						 write_offset);
> > 			bytes_to_copy = buffer_size - read_offset;
> > 		} else {
> > 			bytes_to_copy = write_offset - read_offset;
> > 		}
> > -		i915_memcpy_from_wc(dst_data + read_offset,
> > -				    src_data + read_offset, bytes_to_copy);
> > +		iosys_map_incr(&src_map, read_offset);
> > +		drm_memcpy_from_wc_vaddr(dst_data + read_offset, &src_map,
> > +					 bytes_to_copy);
> > 
> > 		src_data += buffer_size;
> > 		dst_data += buffer_size;
> > -- 
> > 2.25.1
> > 

  parent reply	other threads:[~2022-03-22 13:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03 18:00 [Intel-gfx] [PATCH v2 0/7] drm/i915: Use the memcpy_from_wc function from drm Balasubramani Vivekanandan
2022-03-03 18:00 ` [Intel-gfx] [PATCH v2 1/7] drm: Relax alignment constraint for destination address Balasubramani Vivekanandan
2022-03-03 18:00 ` [Intel-gfx] [PATCH v2 2/7] drm: Add drm_memcpy_from_wc() variant which accepts " Balasubramani Vivekanandan
2022-03-21 19:29   ` Lucas De Marchi
2022-03-03 18:00 ` [Intel-gfx] [PATCH v2 3/7] drm/i915: use the memcpy_from_wc call from the drm Balasubramani Vivekanandan
2022-03-03 18:00 ` [Intel-gfx] [PATCH v2 4/7] drm/i915/guc: " Balasubramani Vivekanandan
2022-03-21 21:14   ` Lucas De Marchi
2022-03-22  8:47     ` Michal Wajdeczko
2022-03-22 13:51     ` Balasubramani Vivekanandan [this message]
2022-04-12  0:57     ` Ceraolo Spurio, Daniele
2022-03-03 18:00 ` [Intel-gfx] [PATCH v2 5/7] drm/i915/selftests: " Balasubramani Vivekanandan
2022-03-21 23:00   ` Lucas De Marchi
2022-03-21 23:07     ` Lucas De Marchi
2022-03-28 13:38       ` Balasubramani Vivekanandan
2022-03-03 18:00 ` [Intel-gfx] [PATCH v2 6/7] drm/i915/gt: Avoid direct dereferencing of io memory Balasubramani Vivekanandan
2022-03-03 18:00 ` [Intel-gfx] [PATCH v2 7/7] drm/i915: Avoid dereferencing io mapped memory Balasubramani Vivekanandan
2022-03-03 18:51 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Use the memcpy_from_wc function from drm (rev3) Patchwork
2022-03-03 19:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-04  6:47 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-03-21 10:07 ` [Intel-gfx] [PATCH v2 0/7] drm/i915: Use the memcpy_from_wc function from drm Das, Nirmoy

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=YjnUYfBkLA5XAcAm@bvivekan-mobl.gar.corp.intel.com \
    --to=balasubramani.vivekanandan@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=michael.cheng@intel.com \
    --cc=siva.mullati@intel.com \
    /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