Quoting Matthew Auld (2019-02-14 14:57:08)
> From: Abdiel Janulgue <abdiel.janulgue@xxxxxxxxxxxxxxx>
Why?
So can something without a CPU visible struct page even have a pfn?
> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@xxxxxxxxxxxxxxx>
> Signed-off-by: Matthew Auld <matthew.auld@xxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/i915/intel_region_lmem.c | 11 +++++++++++
> drivers/gpu/drm/i915/intel_region_lmem.h | 3 +++
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c b/drivers/gpu/drm/i915/intel_region_lmem.c
> index 4a205639cbb6..b398becb2733 100644
> --- a/drivers/gpu/drm/i915/intel_region_lmem.c
> +++ b/drivers/gpu/drm/i915/intel_region_lmem.c
> @@ -65,6 +65,17 @@ static const struct intel_memory_region_ops region_lmem_ops = {
> .object_create = region_lmem_object_create,
> };
>
> +unsigned long i915_gem_object_lmem_io_pfn(struct drm_i915_gem_object *obj,
> + unsigned long n)
> +{
> + struct intel_memory_region *mem = obj->memory_region;
> + resource_size_t offset;
> +
> + offset = i915_gem_object_get_dma_address(obj, n);
Magic of type convenience?
We definitely do not want to be returning a dma_address as a CPU
address. The semantics here needs to be cleaned up.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
