The remaining utils display needs from i915_utils.h are primarily
MISSING_CASE() and fetch_and_zero(), with a couple of
i915_inject_probe_failure() uses.
To avoid excessive churn, add duplicates of MISSING_CASE() and
fetch_and_zero() to intel_display_utils.h, and switch display to use the
display utils.
As long as there are display files that include i915_drv.h, which
includes i915_utils.h, we'll need #ifndef guards for MISSING_CASE() and
fetch_and_zero() in both utils headers. We can remove them once display
no longer depends on i915_drv.h.
A couple of files in display still need i915_utils.h for
i915_inject_probe_failure(). Annotate this. They will be handled
separately.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patch.msgid.link/79f9e31ca64c8c045834d48e20ceb0c515d1e9e1.1761146196.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
drm_sched_run_job_work() contains a comment which explains that an
entity being NULL means that there is no more work to do. It can,
however, also mean that there is work, but the scheduler doesn't have
enough credits to process the jobs right now.
Provide this detail in the comment.
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20251028134602.94125-3-phasta@kernel.org
VMA pinning to GGTT is now commited asynchronously in CHV / BXT+VDT
environments to avoid lock inversion among reservation_ww and cpu_hotplug
locks, the latter acquired from stop_machine(). Then,
vma->resource->page_sizes_gtt the test uses as shift count may still be
not populated (equal 0) after i915_vma_pin() returns. Wait for VMA bind
completion in those cases to avoid shift-out-of-bounds kernel warnings and
the test case failing with -EBADSLT.
v2: Explain why VMA pinning is commited asynchronously on CHV/BXT+VTD
(Krzysztof),
- use more precise wording in commit description.
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
Acked-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20251023082925.351307-8-janusz.krzysztofik@linux.intel.com
When running on a Cherryview, or on a Broxton with VTD enabled, pinning of
a VMA to GGTT is now committed asynchronously to avoid lock inversion
among reservation_ww and cpu_hotplug locks, the latter acquired from
stop_machine(). That may defer further processing of resources that
depend on that VMA. As a consequence, a 10ms delay in a multithreaded
migrate test case may occur too short and still incomplete threads may be
interrupted, and the test case may fail with -ERESTARTSYS or -EINTR error
code returned by any of those threads.
Extend the delay to empirically determined 100ms on affected platforms.
v3: Add an in-line comment that explains why 100ms (Andi).
v2: Fix spelling (Sebastian, Krzysztof),
- explain why VMA pinning is commited asynchronously on CHV/BXT+VTD
(Krzysztof).
Cc: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
Acked-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20251023082925.351307-7-janusz.krzysztofik@linux.intel.com
GPUs typically benefit from contiguous memory via reduced TLB pressure and
improved caching performance, where the maximum size of contiguous block
which adds a performance benefit is related to hardware design.
TTM pool allocator by default tries (hard) to allocate up to the system
MAX_PAGE_ORDER blocks. This varies by the CPU platform and can also be
configured via Kconfig.
If that limit was set to be higher than the GPU can make an extra use of,
lets allow the individual drivers to let TTM know over which allocation
order can the pool allocator afford to make a little bit less effort with.
We implement this by disabling direct reclaim for those allocations, which
reduces the allocation latency and lowers the demands on the page
allocator, in cases where expending this effort is not critical for the
GPU in question.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20251020115411.36818-5-tvrtko.ursulin@igalia.com
They are all doing the same thing with the mask being the param. Just
declare our own attribute to store the mask and provide a single
function.
Another common pattern is to define the show function in the macro,
however on follow up work the mask may be used for returning more
information, so it'd need to be stored in any case.
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-7-d1f5abbb8114@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Move the attribute definitions to be grouped together rather than near
the show() function: checkpatch keeps complaining about the missing
newline when defining new attributes and it reads better to group
everything, which should match e.g. the xe_pmu.c style.
While grouping them, also define a THROTTLE_ATTR_RO(), similar to
DEVICE_ATTR_RO(), and use it to define all attributes. This makes it
shorter and with a familiar syntax.
Finally, during the cri_throttle_attrs[] array definition, also
highlight what's coming from common attributes and what is CRI-specific.
These 3 things could be done as separate commits, but they are all about
the same thing: reduce the attribute definition verbosity and are very
simple and mechanical.
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-5-d1f5abbb8114@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Use a single function to read and mask the value the callers will be
interested in. This reduces the risk of a caller using a plain call to
xe_gt_throttle_get_limit_reasons() without applying any mask, which can
return unexpected bits for future platforms.
Select which reg and mask it's going to be used according to the
platform and gt type and always use that one function.
There was an odd xe_gt_dbg() when reading the status, which is not done
for any other throttle/* sysfs file, so just make the status be as
special as everybody else.
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Link: https://patch.msgid.link/20251029-gt-throttle-cri-v3-3-d1f5abbb8114@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Rename drm_client_framebuffer_create() to drm_client_buffer_create_dump()
and adapt callers. The new name reflects the function's purpose. Using
dumb buffers is the easiest way for creating a GEM buffer in a drivers-
independent way.
There's also drm_client_buffer_create(), which creates the client buffer
from a preexisting buffer object. This helper can be exported for drivers
that create their own GEM buffer object.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Francesco Valla <francesco@valla.it>
Link: https://patch.msgid.link/20251027121042.143588-7-tzimmermann@suse.de
Release client buffers with drm_client_buffer_delete() instead of
drm_client_framebuffer_delete(). The latter is just a tiny wrapper
around the former.
Move the test for !buffer into drm_client_buffer_delete(), although
all callers appear to always have a valid pointer.
v2:
- test for !buffer before deref-ing pointer (Jocelyn, Dan)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Francesco Valla <francesco@valla.it>
Link: https://patch.msgid.link/20251027121042.143588-6-tzimmermann@suse.de
The client buffer's framebuffer holds a reference and pointer on
each of its GEM buffer objects. Thus the field gem in the client-
buffer struct is not necessary. Deprecated the field and convert
the client-buffer helpers to use the framebuffer's objects.
In drm_client_buffer_delete(), do a possible vunmap before releasing
the framebuffer. Otherwise we'd eventually release the framebuffer
before unmaping its buffer objects.
v2:
- avoid dependency on CONFIG_DRM_KMS_HELPER
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Francesco Valla <francesco@valla.it>
Link: https://patch.msgid.link/20251027121042.143588-5-tzimmermann@suse.de
Creating and deleting a client buffer always creates and deletes
the underlying DRM framebuffer. Inline the helper functions into
their callers.
With the _addfb code being inlined into drm_client_buffer_create(),
clean up the function's error rollback to release the framebuffer's
handle and GEM buffer object as needed.
Move the _rmfb code into drm_client_buffer_delete() rather than its
current location in drm_client_framebuffer_delete(). The former is
now the inverse of drm_client_buffer_create(). Makes no difference
for cleaning up. Also prepares for the removal of
drm_client_framebuffer_delete().
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Francesco Valla <francesco@valla.it>
Link: https://patch.msgid.link/20251027121042.143588-4-tzimmermann@suse.de
Dumb-buffer creation within the client code is asymetrically balanced
across drm_client_buffer_create() and drm_client_framebuffer_create().
Put all dumb-buffer code into drm_client_framebuffer_create() and leave
client-buffer initialization to drm_client_buffer_create(). Clarifies
responsibility between these functions.
Apart form the architectural improvements, drm_client_buffer_create()
can now be exported if needed by clients. The client will be able to
initialize buffers that have been created from other interfaces than
dumb buffers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Francesco Valla <francesco@valla.it>
Link: https://patch.msgid.link/20251027121042.143588-3-tzimmermann@suse.de
This is the new API for allocating DRM bridges.
This conversion was missed during the initial conversion of all bridges to
the new API. Thus all kernels with commit 94d50c1a2c ("drm/bridge:
get/put the bridge reference in drm_bridge_attach/detach()") and using this
driver now warn due to drm_bridge_attach() incrementing the refcount, which
is not initialized without using devm_drm_bridge_alloc() for allocation.
To make the conversion simple and straightforward without messing up with
the drmm_simple_encoder_alloc(), move the struct drm_bridge from struct
imx_parallel_display_encoder to struct imx_parallel_display.
Also remove the 'struct imx_parallel_display *pd' from struct
imx_parallel_display_encoder, not needed anymore.
Fixes: 94d50c1a2c ("drm/bridge: get/put the bridge reference in drm_bridge_attach/detach()")
Reported-by: Ernest Van Hoecke <ernestvanhoecke@gmail.com>
Closes: https://lore.kernel.org/all/hlf4wdopapxnh4rekl5s3kvoi6egaga3lrjfbx6r223ar3txri@3ik53xw5idyh/
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
Tested-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Link: https://patch.msgid.link/20251014-drm-bridge-alloc-imx-ipuv3-v1-1-a1bb1dcbff50@bootlin.com
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Call intel_casf_enable and intel_casf_disable
in atomic commit path to enable and disable casf.
Call intel_casf_update_strength to only update
the desired strength value.
v2: Introduce casf_enable here.[Ankit]
v3: Use is_disabling in casf_disabling.[Ankit]
v4: Swap old_state and new_state param.[Ankit]
v5: In disable fn move win_sz after sharpness_ctl.
v6: Rebase and update commit message.
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251028120747.3027332-10-ankit.k.nautiyal@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Both sharpness and panel fitter use pipe scaler,
but only one can be enabled at a time. Furthermore
sharpness uses second scaler. So for CASF, check if
second scaler is available and make sure that only
either of panel fitter or sharpness is enabled at
a time.
v2: Add the panel fitting check before enabling sharpness
v3: Reframe commit message[Arun]
v4: Replace string based comparison with plane_state[Jani]
v5: Rebase
v6: Fix build issue
v7: Remove scaler id from verify_crtc_state[Ankit]
v8: Change the patch title. Add code comment.
Move the config part in patch#6. [Ankit]
v9: Refactor the patch[Ankit]
v10: Modify the header of patch[Ankit]
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251028120747.3027332-8-ankit.k.nautiyal@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
