On 24/01/2020 16:46, Chris Wilson wrote:
Quoting Matthew Auld (2020-01-24 16:41:31)
Technically mmap__cpu and mmap__wc just ignore the prot value, so it
doesn't really matter, but the intention is to have write access to the
ptr, so make that clear. Also if the underlying mmap__wc were to at some
point use mmap_offset where the prot is not ignored then we won't have
any surprises.
The ptr here was just meant for cheaply reading back from the buffer to
verify the relocation took place. E.g.,
-static void exec1(int fd, uint32_t handle, uint64_t reloc_ofs, unsigned flags, char *ptr)
+static void exec1(int fd, uint32_t handle, uint64_t reloc_ofs, unsigned flags, const char *ptr)
{
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 gem_exec[1];
@@ -126,7 +126,7 @@ static void xchg_reloc(void *array, unsigned i, unsigned j)
*b = tmp;
}
-static void execN(int fd, uint32_t handle, uint64_t batch_size, unsigned flags, char *ptr)
+static void execN(int fd, uint32_t handle, uint64_t batch_size, unsigned flags, const char *ptr)
{
What am I missing?
*(uint64_t *)(ptr + gem_reloc[n].offset) = gem_reloc[n].presumed_offset;
?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
