| Age | Commit message (Collapse) | Author |
|---|
|
Add required library interfaces to support VM_BIND
functionality.
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
|
|
Will be useful later.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
|
|
Most users shouldn't care about such an interface, but where required,
this should be useful to aid in setting NEEDS_CPU_ACCESS for a given BO.
Underneath we try to smooth over needing to provide an explicit SMEM
region, or if this is SMEM-only, we don't want the kernel to throw an
error.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
|
|
For now limit to direct callers.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
|
|
Promote intel_os.c helpers to igt_os.c, so that I can re-use them for
some additional msm tests. Just big churny rename, no functional change.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Probing alignment/offset (A/O) in default context works properly only
when there're no processes which competes on same vm space. To avoid
risk that single probe will be called on already used offset in another
process lets use dedicated context for this purpose if possible.
In other words when forking occur without A/O cache filled (subject of
COW) children will exercise A/O individually. Using same default context
leads to risk of probing offset which is in flight in another child
thus we can get different A/O. Such behavior is not allowed as allocator
infrastructure requires same type, strategy and alignment on single vm.
We expect coherent A/O in different children so we try to use separate
context to fill this requirement.
v2: on old gens where're no logical contexts use default context
v3: adding missing condition for context destroy (Matt)
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/5729
|
|
Make sure that we can continue to create buffers, primarily to service as
framebuffers for scanout, even while the device is wedged.
v2:
- Deleted gem_memory_topology.[ch] and moved it's content
to intel_memory_region.[ch]. [Ashutosh]
- Fixed checkpatch.pl warning.
v3:
- Added igt_describe() for new added tests. [Kamil]
Cc: CQ Tang <cq.tang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
Not all systems supports dma-buf or supports it partially thus tests which
relies on this functionality should be skipped. Partially means some
memory regions can support it whereas other not. Add a helper function
which will verify dma-buf support on memory regions and create a set of
those supported.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>
Reviewed-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
|
|
With era of new gens we're enforced to use no-reloc (softpin). This
brings few problems like vm range limitations which were well solved
by the kernel. This can be handled also in userspace code by adding
gen related conditionals or by trying to detect the constraints.
Lets try to do this dynamically and detect safe start offset and
alignment for each memory region we got. This should be universal solution
regardless hw limitations and bugs. As such detection is not lightweight
technique add also some caching structures to handle consequtive calls
about same data.
v2: unify cache
v3: move allocation of cache entry out of mutex
v4: remove assert on allocation newentry, just skip adding to cache
v5: fix function documentation (Ashutosh)
v6: remove unnecessary buffers count initialization (Ashutosh)
add 48b flag for pinning object
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
As Ashutosh noticed I've handled errors from the kernel too wide
packing it to same error bag and returning system memory region in this
case. That's of course is wrong and can lead to return system memory on
discrete if invalid arguments would be passed to the query.
Return previous behavior of query memory regions handling -ENODEV path
individually. For this error lets assume we got kernel which doesn't
support this query yet so returning system memory region is a reasonable
choice because this region exists for all of i915 gens.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Reported-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
For stable kernels we get -ENODEV on integrated where gem_create_ext()
call tries to allocate bo in system memory. Instead of asserting this
case we can fallback to gem_create() as this allocation can be resolved
using legacy call.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
For stable kernels we can currently get -ENODEV on integrated gens
when no CONFIG_DRM_I915_UNSTABLE_FAKE_LMEM is set.
Provide system memory region stub to avoid failing on querying
kernel for memory regions.
v2: use offsetof() instead of manual size calculation
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Add typechecking to the min/max macros and make their locals truly
unique-ish to reduce the risk of shadowing.
v2: small bug fix, write also height coordinate on rotation
test. (jheikkil)
v3: Fix up a couple of other max/max_t instances (Ashutosh)
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
In 22643ce4014a ("Return allocated size in gem_create_in_memory_regions()
and friends") we modified __gem_create_in_memory_regions and
gem_create_in_memory_regions to return the allocated size for buffer
objects. However, this also unnecessarily complicates programming in the
majority of cases where the allocated size is not needed. For example in
several cases it requires tracking the requested and allocated sizes
separately, the size used must be strictly uint64_t etc.
In order to simplify things and provide greater flexibility, here we change
22643ce4014a to follow the same scheme followed in gem_create_ext (and in
gem_create) where __gem_create_ext returns the allocated size but
gem_create_ext doesn't. With this change, __gem_create_in_memory_regions
returns the allocated size for situations where it is needed but in the
majority of cases where the allocated size is not needed we can just use
gem_create_in_memory_regions for casual use as before.
v2: Store requested not allocated bo size in intel_buf->size (Zbigniew)
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
Often the allocated size is of interest and is different from the
requested size. Therefore return allocated size for the object (by
__gem_create_ext()) in gem_create_in_memory_regions() and friends.
v2: Assign buf->size correctly in __intel_buf_init (Zbigniew)
Cc: Andrzej Turko <andrzej.turko@linux.intel.com>
Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
Functions which extract information from drm_i915_query_memory_regions
structures passed via their pointer as an argument don't modify those
structures, let them accept that content declared as constant.
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
While checking for LMEM support on older kernels with the
DRM_I915_QUERY_MEMORY_REGIONS, it may fail with EINVAL.
Instead of abort/asserting the test, make sure gem_has_lmem
remains functional.
V2:
* Rebase
V3:
* Update commit message (Ashutosh)
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
If the regions query fails then the error will be encoded in the
item.length, while the ioctl will still return success.
Reported-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
|
|
query_info calloc'd in gem_get_query_memory_regions should be freed in
gem_get_lmem_region_count.
Cc: Andrzej Turko <andrzej.turko@linux.intel.com>
Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Fixes: f32993a2ed ("lib/i915/intel_memory_region: Add new memory region lib")
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
|
|
With an introduction of Local Memory concept we should be able to
allocate object in specific memory region. This patch implements
helper functions that allow this, both for querying what the device
supports and hooking into gem_create_ext to select the placements.
Co-authored-by: Lukasz Kalamarz <lukasz.kalamarz@intel.com>
Co-authored-by: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Signed-off-by: Andrzej Turko <andrzej.turko@linux.intel.com>
Signed-off-by: Lukasz Kalamarz <lukasz.kalamarz@intel.com>
Signed-off-by: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
