| Age | Commit message (Collapse) | Author |
|---|
|
Reorganize ast_post_gpu() so that it first branches by Gen and then
by config mode and TX chip. This will later make it possible to split
up the function by Gen.
The helper ast_init_3rdtx() only handles Gen4 and Gen5, so leave it
out from the other Gens.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117103450.28692-4-tzimmermann@suse.de
|
|
Move DRAM detection before TX-chip detection. Both steps are independent
from each other. Detection of the TX-chip is now next to posting those
chips, which can be done in a single step.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117103450.28692-3-tzimmermann@suse.de
|
|
Wide-screen support is relevant for mode validation. Do not detect it
before setting up the mode-setting pipeline. Gets the function call out
of the way of other initialization code.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117103450.28692-2-tzimmermann@suse.de
|
|
In the combination of DRM_KMS_HELPER=m, DRM_GEM_SHMEM_HELPER=y, DRM_FBDEV_EMULATION=y,
The shmem code fails to link against the KMS helpers:
x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_driver_fbdev_probe':
(.text+0xeec601): undefined reference to `drm_fb_helper_alloc_info'
x86_64-linux-ld: (.text+0xeec633): undefined reference to `drm_fb_helper_fill_info'
x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_get_page':
drm_fbdev_shmem.c:(.text+0xeec7d2): undefined reference to `drm_gem_fb_get_obj'
x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_fb_mmap':
drm_fbdev_shmem.c:(.text+0xeec9f6): undefined reference to `drm_gem_fb_get_obj'
x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_defio_imageblit':
(.rodata+0x5b2288): undefined reference to `drm_fb_helper_check_var'
x86_64-linux-ld: (.rodata+0x5b2290): undefined reference to `drm_fb_helper_set_par'
This can happen for a number of device drivers that select DRM_GEM_SHMEM_HELPER
without also selecting DRM_KMS_HELPER. To work around this, add another select
that forces DRM_KMS_HELPER to be built-in rather than a loadable module, but
only if FBDEV emulation is also enabled. DRM_TTM_HELPER and DRM_GEM_DMA_HELPER
look like they have the same problem in theory even if there is no possible
configuration that shows it. For consistency, do the same change to those.
Closes: https://lore.kernel.org/all/20250121-greedy-flounder-of-abundance-4d2ee8-mkl@pengutronix.de
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20250122090211.3161186-1-arnd@kernel.org
|
|
While setting the bounds for compressed bpp, we ensure that the
compressed bpp is less than the pipe bpp.
This causes an issue with the 420 output format, where the effective
link bpp (or output bpp) is half that of the pipe bpp. Therefore instead
of using pipe bpp, use the output bpp to set the bounds for the
compressed bpp.
v2: Use identifier output_bpp instead of link_bpp (Imre)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117050713.152012-1-ankit.k.nautiyal@intel.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull rust updates from Miguel Ojeda:
"Toolchain and infrastructure:
- Finish the move to custom FFI integer types started in the previous
cycle and finally map 'long' to 'isize' and 'char' to 'u8'. Do a
few cleanups on top thanks to that.
- Start to use 'derive(CoercePointee)' on Rust >= 1.84.0.
This is a major milestone on the path to build the kernel using
only stable Rust features. In particular, previously we were using
the unstable features 'coerce_unsized', 'dispatch_from_dyn' and
'unsize', and now we will use the new 'derive_coerce_pointee' one,
which is on track to stabilization. This new feature is a macro
that essentially expands into code that internally uses the
unstable features that we were using before, without having to
expose those.
With it, stable Rust users, including the kernel, will be able to
build custom smart pointers that work with trait objects, e.g.:
fn f(p: &Arc<dyn Display>) {
pr_info!("{p}\n");
}
let a: Arc<dyn Display> = Arc::new(42i32, GFP_KERNEL)?;
let b: Arc<dyn Display> = Arc::new("hello there", GFP_KERNEL)?;
f(&a); // Prints "42".
f(&b); // Prints "hello there".
Together with the 'arbitrary_self_types' feature that we started
using in the previous cycle, using our custom smart pointers like
'Arc' will eventually only rely in stable Rust.
- Introduce 'PROCMACROLDFLAGS' environment variable to allow to link
Rust proc macros using different flags than those used for linking
Rust host programs (e.g. when 'rustc' uses a different C library
than the host programs' one), which Android needs.
- Help kernel builds under macOS with Rust enabled by accomodating
other naming conventions for dynamic libraries (i.e. '.so' vs.
'.dylib') which are used for Rust procedural macros. The actual
support for macOS (i.e. the rest of the pieces needed) is provided
out-of-tree by others, following the policy used for other parts of
the kernel by Kbuild.
- Run Clippy for 'rusttest' code too and clean the bits it spotted.
- Provide Clippy with the minimum supported Rust version to improve
the suggestions it gives.
- Document 'bindgen' 0.71.0 regression.
'kernel' crate:
- 'build_error!': move users of the hidden function to the documented
macro, prevent such uses in the future by moving the function
elsewhere and add the macro to the prelude.
- 'types' module: add improved version of 'ForeignOwnable::borrow_mut'
(which was removed in the past since it was problematic); change
'ForeignOwnable' pointer type to '*mut'.
- 'alloc' module: implement 'Display' for 'Box' and align the 'Debug'
implementation to it; add example (doctest) for 'ArrayLayout::new()'
- 'sync' module: document 'PhantomData' in 'Arc'; use
'NonNull::new_unchecked' in 'ForeignOwnable for Arc' impl.
- 'uaccess' module: accept 'Vec's with different allocators in
'UserSliceReader::read_all'.
- 'workqueue' module: enable run-testing a couple more doctests.
- 'error' module: simplify 'from_errno()'.
- 'block' module: fix formatting in code documentation (a lint to catch
these is being implemented).
- Avoid 'unwrap()'s in doctests, which also improves the examples by
showing how kernel code is supposed to be written.
- Avoid 'as' casts with 'cast{,_mut}' calls which are a bit safer.
And a few other cleanups"
* tag 'rust-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (32 commits)
kbuild: rust: add PROCMACROLDFLAGS
rust: uaccess: generalize userSliceReader to support any Vec
rust: kernel: add improved version of `ForeignOwnable::borrow_mut`
rust: kernel: reorder `ForeignOwnable` items
rust: kernel: change `ForeignOwnable` pointer to mut
rust: arc: split unsafe block, add missing comment
rust: types: avoid `as` casts
rust: arc: use `NonNull::new_unchecked`
rust: use derive(CoercePointee) on rustc >= 1.84.0
rust: alloc: add doctest for `ArrayLayout::new()`
rust: init: update `stack_try_pin_init` examples
rust: error: import `kernel`'s `LayoutError` instead of `core`'s
rust: str: replace unwraps with question mark operators
rust: page: remove unnecessary helper function from doctest
rust: rbtree: remove unwrap in asserts
rust: init: replace unwraps with question mark operators
rust: use host dylib naming convention to support macOS
rust: add `build_error!` to the prelude
rust: kernel: move `build_error` hidden function to prevent mistakes
rust: use the `build_error!` macro, not the hidden function
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks
Pull kthread updates from Frederic Weisbecker:
"Kthreads affinity follow either of 4 existing different patterns:
1) Per-CPU kthreads must stay affine to a single CPU and never
execute relevant code on any other CPU. This is currently handled
by smpboot code which takes care of CPU-hotplug operations.
Affinity here is a correctness constraint.
2) Some kthreads _have_ to be affine to a specific set of CPUs and
can't run anywhere else. The affinity is set through
kthread_bind_mask() and the subsystem takes care by itself to
handle CPU-hotplug operations. Affinity here is assumed to be a
correctness constraint.
3) Per-node kthreads _prefer_ to be affine to a specific NUMA node.
This is not a correctness constraint but merely a preference in
terms of memory locality. kswapd and kcompactd both fall into this
category. The affinity is set manually like for any other task and
CPU-hotplug is supposed to be handled by the relevant subsystem so
that the task is properly reaffined whenever a given CPU from the
node comes up. Also care should be taken so that the node affinity
doesn't cross isolated (nohz_full) cpumask boundaries.
4) Similar to the previous point except kthreads have a _preferred_
affinity different than a node. Both RCU boost kthreads and RCU
exp kworkers fall into this category as they refer to "RCU nodes"
from a distinctly distributed tree.
Currently the preferred affinity patterns (3 and 4) have at least 4
identified users, with more or less success when it comes to handle
CPU-hotplug operations and CPU isolation. Each of which do it in its
own ad-hoc way.
This is an infrastructure proposal to handle this with the following
API changes:
- kthread_create_on_node() automatically affines the created kthread
to its target node unless it has been set as per-cpu or bound with
kthread_bind[_mask]() before the first wake-up.
- kthread_affine_preferred() is a new function that can be called
right after kthread_create_on_node() to specify a preferred
affinity different than the specified node.
When the preferred affinity can't be applied because the possible
targets are offline or isolated (nohz_full), the kthread is affine to
the housekeeping CPUs (which means to all online CPUs most of the time
or only the non-nohz_full CPUs when nohz_full= is set).
kswapd, kcompactd, RCU boost kthreads and RCU exp kworkers have been
converted, along with a few old drivers.
Summary of the changes:
- Consolidate a bunch of ad-hoc implementations of
kthread_run_on_cpu()
- Introduce task_cpu_fallback_mask() that defines the default last
resort affinity of a task to become nohz_full aware
- Add some correctness check to ensure kthread_bind() is always
called before the first kthread wake up.
- Default affine kthread to its preferred node.
- Convert kswapd / kcompactd and remove their halfway working ad-hoc
affinity implementation
- Implement kthreads preferred affinity
- Unify kthread worker and kthread API's style
- Convert RCU kthreads to the new API and remove the ad-hoc affinity
implementation"
* tag 'kthread-for-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks:
kthread: modify kernel-doc function name to match code
rcu: Use kthread preferred affinity for RCU exp kworkers
treewide: Introduce kthread_run_worker[_on_cpu]()
kthread: Unify kthread_create_on_cpu() and kthread_create_worker_on_cpu() automatic format
rcu: Use kthread preferred affinity for RCU boost
kthread: Implement preferred affinity
mm: Create/affine kswapd to its preferred node
mm: Create/affine kcompactd to its preferred node
kthread: Default affine kthread to its preferred NUMA node
kthread: Make sure kthread hasn't started while binding it
sched,arm64: Handle CPU isolation on last resort fallback rq selection
arm64: Exclude nohz_full CPUs from 32bits el0 support
lib: test_objpool: Use kthread_run_on_cpu()
kallsyms: Use kthread_run_on_cpu()
soc/qman: test: Use kthread_run_on_cpu()
arm/bL_switcher: Use kthread_run_on_cpu()
|
|
Pull drm updates from Dave Airlie:
"There are two external interactions of note, the msm tree pull in some
opp tree, hopefully the opp tree arrives from the same git tree
however it normally does.
There is also a new cgroup controller for device memory, that is used
by drm, so is merging through my tree. This will hopefully help open
up gpu cgroup usage a bit more and move us forward.
There is a new accelerator driver for the AMD XDNA Ryzen AI NPUs.
Then the usual xe/amdgpu/i915/msm leaders and lots of changes and
refactors across the board:
core:
- device memory cgroup controller added
- Remove driver date from drm_driver
- Add drm_printer based hex dumper
- drm memory stats docs update
- scheduler documentation improvements
new driver:
- amdxdna - Ryzen AI NPU support
connector:
- add a mutex to protect ELD
- make connector setup two-step
panels:
- Introduce backlight quirks infrastructure
- New panels: KDB KD116N2130B12, Tianma TM070JDHG34-00,
- Multi-Inno Technology MI1010Z1T-1CP11
bridge:
- ti-sn65dsi83: Add ti,lvds-vod-swing optional properties
- Provide default implementation of atomic_check for HDMI bridges
- it605: HDCP improvements, MCCS Support
xe:
- make OA buffer size configurable
- GuC capture fixes
- add ufence and g2h flushes
- restore system memory GGTT mappings
- ioctl fixes
- SRIOV PF scheduling priority
- allow fault injection
- lots of improvements/refactors
- Enable GuC's WA_DUAL_QUEUE for newer platforms
- IRQ related fixes and improvements
i915:
- More accurate engine busyness metrics with GuC submission
- Ensure partial BO segment offset never exceeds allowed max
- Flush GuC CT receive tasklet during reset preparation
- Some DG2 refactor to fix DG2 bugs when operating with certain CPUs
- Fix DG1 power gate sequence
- Enabling uncompressed 128b/132b UHBR SST
- Handle hdmi connector init failures, and no HDMI/DP cases
- More robust engine resets on Haswell and older
i915/xe display:
- HDCP fixes for Xe3Lpd
- New GSC FW ARL-H/ARL-U
- support 3 VDSC engines 12 slices
- MBUS joining sanitisation
- reconcile i915/xe display power mgmt
- Xe3Lpd fixes
- UHBR rates for Thunderbolt
amdgpu:
- DRM panic support
- track BO memory stats at runtime
- Fix max surface handling in DC
- Cleaner shader support for gfx10.3 dGPUs
- fix drm buddy trim handling
- SDMA engine reset updates
- Fix doorbell ttm cleanup
- RAS updates
- ISP updates
- SDMA queue reset support
- Rework DPM powergating interfaces
- Documentation updates and cleanups
- DCN 3.5 updates
- Use a pm notifier to more gracefully handle VRAM eviction on
suspend or hibernate
- Add debugfs interfaces for forcing scheduling to specific engine
instances
- GG 9.5 updates
- IH 4.4 updates
- Make missing optional firmware less noisy
- PSP 13.x updates
- SMU 13.x updates
- VCN 5.x updates
- JPEG 5.x updates
- GC 12.x updates
- DC FAMS updates
amdkfd:
- GG 9.5 updates
- Logging improvements
- Shader debugger fixes
- Trap handler cleanup
- Cleanup includes
- Eviction fence wq fix
msm:
- MDSS:
- properly described UBWC registers
- added SM6150 (aka QCS615) support
- DPU:
- added SM6150 (aka QCS615) support
- enabled wide planes if virtual planes are enabled (by using two
SSPPs for a single plane)
- added CWB hardware blocks support
- DSI:
- added SM6150 (aka QCS615) support
- GPU:
- Print GMU core fw version
- GMU bandwidth voting for a740 and a750
- Expose uche trap base via uapi
- UAPI error reporting
rcar-du:
- Add r8a779h0 Support
ivpu:
- Fix qemu crash when using passthrough
nouveau:
- expose GSP-RM logging buffers via debugfs
panfrost:
- Add MT8188 Mali-G57 MC3 support
rockchip:
- Gamma LUT support
hisilicon:
- new HIBMC support
virtio-gpu:
- convert to helpers
- add prime support for scanout buffers
v3d:
- Add DRM_IOCTL_V3D_PERFMON_SET_GLOBAL
vc4:
- Add support for BCM2712
vkms:
- line-per-line compositing algorithm to improve performance
zynqmp:
- Add DP audio support
mediatek:
- dp: Add sdp path reset
- dp: Support flexible length of DP calibration data
etnaviv:
- add fdinfo memory support
- add explicit reset handling"
* tag 'drm-next-2025-01-17' of https://gitlab.freedesktop.org/drm/kernel: (1070 commits)
drm/bridge: fix documentation for the hdmi_audio_prepare() callback
doc/cgroup: Fix title underline length
drm/doc: Include new drm-compute documentation
cgroup/dmem: Fix parameters documentation
cgroup/dmem: Select PAGE_COUNTER
kernel/cgroup: Remove the unused variable climit
drm/display: hdmi: Do not read EDID on disconnected connectors
drm/tests: hdmi: Add connector disablement test
drm/connector: hdmi: Do atomic check when necessary
drm/amd/display: 3.2.316
drm/amd/display: avoid reset DTBCLK at clock init
drm/amd/display: improve dpia pre-train
drm/amd/display: Apply DML21 Patches
drm/amd/display: Use HW lock mgr for PSR1
drm/amd/display: Revised for Replay Pseudo vblank control
drm/amd/display: Add a new flag for replay low hz
drm/amd/display: Remove unused read_ono_state function from Hwss module
drm/amd/display: Do not elevate mem_type change to full update
drm/amd/display: Do not wait for PSR disable on vbl enable
drm/amd/display: Remove unnecessary eDP power down
...
|
|
The scale() functions detects invalid parameters, but continues
its calculations anyway. This causes bad results if negative values
are used for unsigned operations. Worst case, a division by 0 error
will be seen if source_min == source_max.
On top of that, after v6.13, the sequence of WARN_ON() followed by clamp()
may result in a build error with gcc 13.x.
drivers/gpu/drm/i915/display/intel_backlight.c: In function 'scale':
include/linux/compiler_types.h:542:45: error:
call to '__compiletime_assert_415' declared with attribute error:
clamp() low limit source_min greater than high limit source_max
This happens if the compiler decides to rearrange the code as follows.
if (source_min > source_max) {
WARN(..);
/* Do the clamp() knowing that source_min > source_max */
source_val = clamp(source_val, source_min, source_max);
} else {
/* Do the clamp knowing that source_min <= source_max */
source_val = clamp(source_val, source_min, source_max);
}
Fix the problem by evaluating the return values from WARN_ON and returning
immediately after a warning. While at it, fix divide by zero error seen
if source_min == source_max.
Analyzed-by: Linus Torvalds <torvalds@linux-foundation.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Suggested-by: David Laight <david.laight.linux@gmail.com>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250121145203.2851237-1-linux@roeck-us.net
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
A small typo leads to the following static code checker warning:
drivers/gpu/drm/xe/xe_guc_buf.c:81 xe_guc_buf_reserve()
warn: sizeof(NUMBER)?
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/intel-xe/0d5bcbf1-79f9-4a10-a221-ddbaec9f6122@stanley.mountain/
Fixes: 696bfdf273ea ("drm/xe/guc: Introduce the GuC Buffer Cache")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250121094832.588-1-michal.wajdeczko@intel.com
|
|
The migration support only needs to be initialized once, but it
was incorrectly called from the xe_gt_sriov_pf_init_hw(), which
is part of the reset flow and may be called multiple times.
Fixes: d86e3737c7ab ("drm/xe/pf: Add functions to save and restore VF GuC state")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250120232443.544-1-michal.wajdeczko@intel.com
|
|
perf event already has a default function that returns 0, no need to
override with the same thing.
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250113183329.3138138-1-lucas.demarchi@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
UMD's have interest in setting unused bits of the oa_ctrl register "out of
band" for certain experiments. To facilitate this, don't clobber previous
oa_ctrl unused bits, i.e. rmw the values rather than simply write them.
Fixes: e936f885f1e9 ("drm/xe/oa/uapi: Expose OA stream fd")
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117032155.3048063-1-ashutosh.dixit@intel.com
|
|
Now that we know how to issue the push with the DSB we can
allow the DSB to drive the commits even when VRR is active.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-9-ville.syrjala@linux.intel.com
|
|
We have at least two options for how to do the
TRANS_PUSH_SEND + commit completion signalling
with the DSB:
Option A)
1. trigger TRANS_PUSH_SEND
2. wait for "safe window"
3. signal the interrupt
In this cases step 2 should not do anything if we were already
between vmin and vmax decision boundaries. Otherwise we'll wait
until the next start of the vblank period.
Option B)
1. wait for "safe window"
2. trigger TRANS_PUSH_SEND
3. signal the interrupt
This option is perhaps a bit less racy, but if we do somehow
screw up and the wait is a nop but the push gets deferred
until the next frame then we'll end up completing the commit
a frame too early.
So for now I'm leaning towards option A since losing the race
won't have any drastic consequences. To deal with the race we
can give the DSB a bit more time to start step 2 before the
hardware has started the vblank termination properly. Often
times it seems to be fast enough to make it in time even without
any extra vblank delay (the push is issued somewhere within a
scanline and it latches on the next scanline).
v2: Use intel_vrr_possible() to determine if we need some
vblank delay (also avoids adding it for DSI which doens't
actually program the transcoder registers correctly for it)
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-8-ville.syrjala@linux.intel.com
|
|
GOP might not agree with our idea of what the vblank delay should be.
Reuse the LRR codepaths to fix that up via a fastset.
The relevant registers aren't actually double buffered so this is a
little bit dodgy. While I've not seen any real issues from frobbing
these live, let's limit this to just the fastboot case (by only
allowing it when old_crtc_state->inherited==true).
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Pull the "do we actually need a LRR update?" checks into a small
helper for clarity.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
DSI outputs
intel_set_transcoder_timings*() aren't currently suitable for DSI.
Warn if someone accidentally calls them in such cases.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Update TRANS_SET_CONTEXT_LATENCY in intel_set_transcoder_timings_lrr()
as well. While for actual LRR updates this should not change, I want
to reuse this code to also sanitize the vblank delay during boot,
and in that case we do need to update this.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
I want to start using intel_set_transcoder_timings_lrr() also for
fixing up the vblank delay during boot. To that end make sure it
can cope with interlaced modes as well.
Note that we have soft-defeatured interlaced modes on tgl+ so
technically this is dead code, but if we ever have the need to
bring interlaced support back it seems better to handle this.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
intel_set_transcoder_timings() will set TRANS_VBLANK.vblank_start to 0
for clarity on ADL+ (non-DSI) because the hardware no longer uses that
value. Do the same in intel_set_transcoder_timings_lrr() to make sure
the registers stay consistent even when doing LRR timing updates.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Code for the DP tunnelling functionality in the xe driver can be
built only if the display code is also built, adjust the kconfig
dependency accordingly.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Fixes: 73900dce57e4 ("drm/xe/dp: Enable DP tunneling")
Reported-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117153843.1312303-1-imre.deak@intel.com
|
|
This is already handled below in the code by fixup_initial_plane_config.
Fixes: a8153627520a ("drm/i915: Try to relocate the BIOS fb to the start of ggtt")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210083111.230484-3-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
No allocations should be done before we have had a chance to preserve
the display fb.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210083111.230484-4-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
It was mentioned in a review that there is a possibility of choosing
to load the module with VF in execlists mode.
Of course this doesn't work, just bomb out as hard as possible.
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210083111.230484-12-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
When testing on my tiled display, initially the tiled display is
detected correctly:
[90376.523692] xe 0000:67:00.0: [drm:drm_client_firmware_config.isra.0 [drm]] fallback: Not all outputs enabled
[90376.523713] xe 0000:67:00.0: [drm:drm_client_firmware_config.isra.0 [drm]] Enabled: 0, detected: 2
...
[90376.523967] xe 0000:67:00.0: [drm:drm_client_modeset_probe [drm]] [CRTC:82:pipe A] desired mode 1920x2160 set (1920,0)
[90376.524020] xe 0000:67:00.0: [drm:drm_client_modeset_probe [drm]] [CRTC:134:pipe B] desired mode 1920x2160 set (0,0)
But then, when modes have been set:
[90379.729525] xe 0000:67:00.0: [drm:drm_client_firmware_config.isra.0 [drm]] [CONNECTOR:287:DP-4] on [CRTC:82:pipe A]: 1920x2160
[90379.729640] xe 0000:67:00.0: [drm:drm_client_firmware_config.isra.0 [drm]] [CONNECTOR:289:DP-5] on [CRTC:134:pipe B]: 1920x2160
...
[90379.730036] xe 0000:67:00.0: [drm:drm_client_modeset_probe [drm]] [CRTC:82:pipe A] desired mode 1920x2160 set (0,0)
[90379.730124] xe 0000:67:00.0: [drm:drm_client_modeset_probe [drm]] [CRTC:134:pipe B] desired mode 1920x2160 set (0,0)
Call drm_client_get_tile_offsets() in drm_client_firmware_config() as
well, to ensure that the offset is set correctly.
This has to be done as a separate pass, as the tile order may not be
equal to the drm connector order.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116142825.3933-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Cc: <stable@vger.kernel.org>
|
|
Tiled displays have a different x/y offset to begin with. Instead of
attempting to remember this, just apply a delta instead.
This fixes the first tile being duplicated on other tiles when vt
switching.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116142825.3933-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Cc: <stable@vger.kernel.org>
|
|
A specific allocation for the CRTC is not strictly necessary at this
point, but in order to implement dynamic configuration of VKMS (configFS),
it will be easier to have one allocation per CRTC.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117-b4-vkms-allocated-v4-3-8ec8fd21aaf6@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
A specific allocation for the encoder is not strictly necessary at this
point, but in order to implement dynamic configuration of VKMS (configFS),
it will be easier to have one allocation per encoder.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: José Expósito <jose.exposito89@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117-b4-vkms-allocated-v4-2-8ec8fd21aaf6@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
A specific allocation for the connector is not strictly necessary
at this point, but in order to implement dynamic configuration of
VKMS (configFS), it will be easier to have one allocation per
connector.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: José Expósito <jose.exposito89@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117-b4-vkms-allocated-v4-1-8ec8fd21aaf6@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
Currently we are forcing full modeset if Panel Replay mode is changed. This
is not necessary as long as we are not changing sink PANEL REPLAY ENABLE
bit in PANEL REPLAY ENABLE AND CONFIGURATION 1 register. This can be
achieved by entering Panel Replay inactive mode (Live Frame mode) when
Panel Replay is disabled and keep PANEL REPLAY ENABLE bit in PANEL REPLAY
ENABLE AND CONFIGURATION 1 enabled always if panel is just supporting Panel
Replay.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-5-jouni.hogander@intel.com
|
|
Intel_psr_enable_sink is not used outside intel_psr.c. Convert it as local
static function.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-4-jouni.hogander@intel.com
|
|
Currently we are configuring Panel Replay on sink when it get's
enabled. This means we need to do full modeset when enabling Panel
Replay. This is required as DP specification is saying sink Panel Replay
needs to be configured before link training. Avoid full modeset by enabling
Panel Replay on sink always when it's supported by the sink and the
source.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-3-jouni.hogander@intel.com
|
|
According to DP/eDP specification only DP_PANEL_REPLAY_ENABLE has to be set
prior link training. For this purpose add a new function which sets this
bit on sink side if Panel Replay is supported by the sink and the source.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-2-jouni.hogander@intel.com
|
|
The current VKMS driver uses non-managed function to create
writeback connectors. It is not an issue yet, but in order
to support multiple devices easily, convert this code to
use drm and device managed helpers.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: José Expósito <jose.exposito89@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116-google-vkms-managed-v9-8-3e4ae1bd05a0@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
To allows driver to only use drmm objects, add helper to create
drm_writeback_connectors with automated lifetime management.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116-google-vkms-managed-v9-7-3e4ae1bd05a0@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
The current implementation of drm_writeback_connector initialization does
not properly clean up all resources in case of failure (allocated
properties and possible_encoders). Add this cleaning in case of failure.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116-google-vkms-managed-v9-6-3e4ae1bd05a0@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
As the old drm and the new drmm variants of drm_writeback_connector
requires almost the same initialization, create an internal helper to do
most of the initialization work.
Currently there is no cleanup function for writeback connectors. To allows
implementation of drmm variant of writeback connector, create a cleanup
function that can be used to properly remove all the writeback-specific
properties and allocations.
This also introduce an helper to cleanup only the drm_writeback_connector
properties, so it can be used during initialization to cleanup in case of
failure.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116-google-vkms-managed-v9-5-3e4ae1bd05a0@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
The current VKMS driver uses managed function to create crtc, but
don't use it to properly clean the crtc workqueue. It is not an
issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: José Expósito <jose.exposito89@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116-google-vkms-managed-v9-4-3e4ae1bd05a0@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
Add drmm_alloc_ordered_workqueue(), a helper that provides managed ordered
workqueue cleanup. The workqueue will be destroyed with the final
reference of the DRM device.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116-google-vkms-managed-v9-3-3e4ae1bd05a0@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
The current VKMS driver uses non-managed function to create encoders. It
is not an issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: José Expósito <jose.exposito89@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116-google-vkms-managed-v9-2-3e4ae1bd05a0@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
The current VKMS driver uses non-managed function to create connectors. It
is not an issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: José Expósito <jose.exposito89@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116-google-vkms-managed-v9-1-3e4ae1bd05a0@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
i915 has this really nice, infrastructure where everything becomes
complicated, GGTT needs eviction, etc..
Lets not do that, and make the dumbest possible interface instead.
Try to retrieve the VMA from old_plane_state, or intel_fbdev if kernel
fb.
Link: https://patchwork.freedesktop.org/patch/msgid/20241206182032.196307-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Tested-by: Jani Saarinen <jani.saarinen@intel.com>
|
|
Use intel_encoder_is_hdmi function which was recently introduced to
see if encoder is HDMI or not.
--v2
-Add Fixes tag [Jani]
Fixes: 6a3691ca4799 ("drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117041247.1084381-1-suraj.kandpal@intel.com
|
|
Split skl_get_plane_caps() into four variants:
skl_plane_caps(), glk_plane_caps(), icl_plane_caps(),
tgl_plane_caps().
Makes it easier to figure out what is actually going on there.
v2: skl_plane_caps() should return u8 not bool
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241010164617.10280-1-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
|
|
Move the xe AUX neutering out from skl_get_plane_caps() into the
caller so that it'll be easier to refactor skl_get_plane_caps()
into a more readable shape. This isn't really hardware specific
anyway, and just some kind of bug/misfeature of xe.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-9-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
|
|
Wa_22011186057 (some CCS problem) only affected ADL A-stepping,
which I presume is pre-production hw. Drop the dead code.
Bspec: 54369
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-8-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
|
|
TGL+ should no longer need any VT-d scanout workarounds.
Don't apply any.
Not 100% sure whether pre-SNB might also suffer from this. The
workaround did originate on SNB but who knows if it was just
never caught before that. Not that I ever managed to enable
VT-d any older hardware. Last time I tried on my ILK it ate
the disk!
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-7-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
|
|
Rename vlv_primary_min_alignment() to vlv_plane_min_alignment()
and use it to replace vlv_sprite_min_alignment() since the
behaviour is now identical when the plane init doesn't set up
any async flips stuff.
Technically VLV/CHV sprites do support async flips, so this
also makes us a bit more future proof if/when we extend async
flip support to more than one plane.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-6-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
|
|
Async flips often require bigger alignment that sync flips.
Currently we have HAS_ASYNC_FLIPS() checks strewn about to
inidcate that async flips are generally supported and thus
we want more alignment. Switch that over to using
intel_plane_can_async_flip() so that we can handle these
in a slightly less messy way. Currently we don't have cases
where async flips would require different alignment for
different modifiers on the same plane.
We'll also move the HAS_ASYNC_FLIPS() check to the plane init
code so that we can still use that as a quick way to disable
the async flips workarounds for testing purposes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-5-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
|
