Quoting Matthew Auld (2019-10-18 17:55:53)
> diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c b/drivers/gpu/drm/i915/intel_region_lmem.c
> new file mode 100644
> index 000000000000..7a3f96e1f766
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_region_lmem.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#include "i915_drv.h"
> +#include "intel_memory_region.h"
> +#include "gem/i915_gem_lmem.h"
> +#include "gem/i915_gem_region.h"
> +#include "intel_region_lmem.h"
> +
> +static struct drm_i915_gem_object *
> +lmem_create_object(struct intel_memory_region *mem,
> + resource_size_t size,
> + unsigned int flags)
> +{
> + struct drm_i915_private *i915 = mem->i915;
> + struct drm_i915_gem_object *obj;
> +
> + if (size > BIT(mem->mm.max_order) * mem->mm.chunk_size)
> + return ERR_PTR(-E2BIG);
> +
> + obj = i915_gem_object_alloc();
> + if (!obj)
> + return ERR_PTR(-ENOMEM);
> +
> + drm_gem_private_object_init(&i915->drm, &obj->base, size);
> + i915_gem_object_init(obj, &i915_gem_lmem_obj_ops);
Ah no. Under the current partitioning, you are leaking the GEM object
class out of its hierarchy.
intel_region_*.c provide the abstractions to work with the HW, with
gem/i915_gem_lmem.c wrapping that into a GEM object.
What's the driving force to put the _GEM_ object interface here?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
