Age | Commit message (Collapse) | Author | Files | Lines |
|
The kernel top level Makefile, and recently scripts/Makefile.extrawarn,
have included -Wall, and the disables -Wno-format-security and
$(call cc-disable-warning,frame-address,) for a very long time. They're
redundant in our local subdir-ccflags-y and can be dropped.
Cc: Arnd Bergmann <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Acked-by: Nick Desaulniers <[email protected]>
Reviewed-by: Masahiro Yamada <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/5ab754ddc2e342c75deb8476275984918e573beb.1697009258.git.jani.nikula@intel.com
|
|
Currently, with MFD/pin assignment D, the driver clears the pipe reset bit
of lane 1 which is not owned by display. This causes the display
to block S0iX.
By not clearing this bit for lane 1 and keeping whatever default, S0ix
started to work. This is already what the driver does at the end
of the phy lane reset sequence (Step#8)
Bspec: 65451
Fixes: 619a06dba6fa ("drm/i915/mtl: Reset only one lane in case of MFD")
Cc: Mika Kahola <[email protected]>
Cc: Gustavo Sousa <[email protected]>
Signed-off-by: Khaled Almahallawy <[email protected]>
Reviewed-by: Gustavo Sousa <[email protected]>
Signed-off-by: Radhakrishna Sripada <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
interrupt.c
Structs intel_gvt_irq_info and intel_gvt_irq_map are not used outside of
interrupt.c. Hide them, and reduce includes.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Zhenyu Wang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
struct engine_mmio is not used outside of mmio_context.c. Hide it, and
reduce includes.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Zhenyu Wang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
intel_gvt_mmio_table.c has no need to include the massive
gvt.h. Simplify.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Zhenyu Wang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
gvt.h has no need to include i915_drv.h once the unused to_gvt() has
been removed.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Zhenyu Wang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Update the number of scalers per pipe based on the display
capabilities reported.
v1: define the field values instead of the magic number (JaniN)
Bspec: 71161
Signed-off-by: Vinod Govindapillai <[email protected]>
Reviewed-by: Jouni Högander <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Jouni Högander <[email protected]>
|
|
Update the global dsc flag based on the display capabilities
reported.
v1: define the field values instead of the magic number (JaniN)
Bspec: 71161
Signed-off-by: Vinod Govindapillai <[email protected]>
Reviewed-by: Jouni Högander <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Jouni Högander <[email protected]>
|
|
Register definitions to track the reported scalable display
feature configurations
Bspec: 71161
Signed-off-by: Vinod Govindapillai <[email protected]>
Reviewed-by: Jouni Högander <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Jouni Högander <[email protected]>
|
|
Add a wrapper around intel_step_name that takes in driver data as an
argument. This wrapper will help maintain compatibility with the
proposed xe driver.
Signed-off-by: Chaitanya Kumar Borah <[email protected]>
Signed-off-by: Animesh Manna <[email protected]>
Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Uma Shankar <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Free hw_crtc_state in verify_crtc_state after we are done using
this or else it's just a resource leak.
Fixes: 2745bdda2095 ("drm/i915: Stop clobbering old crtc state during state check")
Signed-off-by: Suraj Kandpal <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
VLV was missed when the color.get_config() hook was added.
Remedy that.
Not really sure what the final plan here was since a bunch of
color related readout was left in intel_display.c anyway,
but that's for anothr day to figure out...
Cc: Jani Nikula <[email protected]>
Fixes: 9af09dfcdfa1 ("drm/i915/color: move pre-SKL gamma and CSC enable read to intel_color")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
Correct typo of "its".
Add commas for clarity.
Capitalize L3.
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: [email protected]
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: [email protected]
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove redundant intel_connector NULL check. Having it here just
creates further confusion and also the variable already gets
dereferenced before the aforementioned NULL check
Signed-off-by: Suraj Kandpal <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Switch the state checker over to using the new 'i915' variable
name insteda of the old 'dev_priv'.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
Switch over to the modern variable naming in the state checker.
Ie. rename the pipe_config stuff to crtc_state.
Also make it clear which is the "software state" (ie. what the
current state should be) vs. "hardware state" (ie. what the
currnet state really is).
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
We're passing in a totally random mismash of things into the state
checker. Clean it up to pass in the minimum needed.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
Mark the remaining crtc states used by the state checker as const.
There is no reason to ever mutate them here.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
Passing in the atomic state + crtc state is a bit weird. The latter
can be just the crtc (which is the normal calling convention used
in a lot of other places).
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
State checkers should never modify the crtc states, so make
them const.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
There is never any reason to pass in both the crtc and its state
as one can always dig out the crtc from its state. But for more
consistency across the whole state checker let's just pass the
overall atomic state+crtc here as well.
v2: Also pass state+crtc here (Jani)
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The skl+ wm state checker has no reason to modify the crtc state,
so make it const.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
Make life simpler by just passing in the atomic state + crtc
instead of plumbing in all kinds of crtc states.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
The DPLL state checker should not be modifying the crtc states,
so make the const.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
The state checker overwrites the old crtc state with the
current hardware state. While that does save a kmalloc() it seems
rather dubious as there might still be something that we need
in the old crtc state.
Stop doing that and just allocate a temporary state for the state
checker. Should the extra malloc during the commit phase turn out
too annoying we could of course preallocate one for each crtc, but
let's proceed with the straightforward approch for now.
And while at it let's mark the new crtc state as const to make
sure the state checker doesn't mess it up.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
intel_psr_pre_plane_update() operates on a per-crtc level, whereas
intel_psr_post_plane_update() operates on the whole atomic commit,
for no real reason that I can see. Adjust intel_psr_post_plane_update()
to match the intel_psr_pre_plane_update() approach.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
|
|
Plane stride is always a multiple of 64 bytes. Remove the
pointless check that really doesn't have anything to do
with FBC.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Vinod Govindapillai <[email protected]>
|
|
Carve up pixel_format_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
Note that the XRGB1555 can be dropped from the g4x+ variant
since the plane no longer supports that format anyway.
TODO: maybe go for vfuncs later
v2: Update for lnl changes
Reviewed-by: Juha-Pekka Heikkila <[email protected]> #v1
Reviewed-by: Vinod Govindapillai <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Carve up rotation_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila <[email protected]>
Reviewed-by: Vinod Govindapillai <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Carve up tiling_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila <[email protected]>
Reviewed-by: Vinod Govindapillai <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Carve up stride_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila <[email protected]>
Reviewed-by: Vinod Govindapillai <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The 16k max plane stride limit seems to be originally from
i965gm, and no explicit limit has been specified since (g4x+).
So let's assume the max plane stride itself is a suitable limit
also for the more recent FBC hardware.
In fact even for i965gm the max X-tiled stride is also 16k so
technically we don't need the check there either, but let's
keep it there anyway since it's explicitly mentioned in the
spec. Gen2/3 have more strict limits checked separately.
Reviewed-by: Swati Sharma <[email protected]>
Reviewed-by: Juha-Pekka Heikkila <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use local64_try_cmpxchg instead of local64_cmpxchg (*ptr, old, new) == old
in i915_pmu_event_read. x86 CMPXCHG instruction returns success in ZF flag,
so this change saves a compare after cmpxchg (and related move instruction
in front of cmpxchg).
Also, try_cmpxchg implicitly assigns old *ptr value to "old" when cmpxchg
fails. There is no need to re-read the value in the loop.
No functional change intended.
Cc: Jani Nikula <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Uros Bizjak <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Current vga arbiter implementation in i915 needs a re-design.
The current approach would cause real problems if anyone actually
needs to talk another GPU using legacy VGA resources.
The main issue is that X becomes a slideshow if it thinks there
are multiple GPUs that have VGA decoding enabled as it insists
on adjusting the VGA routing pretty much for every little operation
involving any of the GPUs.
The cleanup will be planned for i915. Meanwhile to focus on Xe
upstreaming and have a cleaner separation, the said functionality
is being moved to a different file exclusive for i915. Xe driver
will re-use rest of the display code from i915.
v2: Addressed Jani Nikula's review comments.
v3: Dropped a duplicate function (Jani)
v4: Updated commit message with reasoning as sugested by Ville.
Signed-off-by: Uma Shankar <[email protected]>
Reviewed-by: Arun R Murthy <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Atm the MST encoder config computation may use an out-of-date pbn_div
value, if the sink is unplugged and a sink is replugged with different
link rate/lane count capabilities. The current way of reinitializing
pbn_div depends on pbn_div getting cleared via intel_atomic_check() ->
drm_dp_mst_atomic_check() ->
drm_dp_mst_atomic_check_payload_alloc_limits(), however the clearing
won't happen if the sink got unplugged (and hence
drm_dp_mst_topology_mgr::mst_state being false).
To fix the above, simply update pbn_div unconditionally during config
computation, making pbn_div always match the link rate and lane count.
Cc: Lyude Paul <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This is to eliminate all cases of "*ERROR* LSPCON mode hasn't settled",
followed by link training errors. Intel engineers recommended increasing
this timeout and that does resolve the issue.
On some CometLake-based device designs the Parade PS175 takes more than
400ms to settle in PCON mode. 100 reboot trials on one device resulted
in a median settle time of 440ms and a maximum of 444ms. Even after
increasing the timeout to 500ms, 2% of devices still had this error. So
this increases the timeout to 800ms.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9443
Signed-off-by: Pablo Ceballos <[email protected]>
Signed-off-by: Niko Tsirakis <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Since gt0 == i915->gt[0], just drop the former.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Gustavo Sousa <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Acked-by: Michał Winiarski <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/5319364f4c9416fed218382d020a57c5b0a17bee.1696236329.git.jani.nikula@intel.com
|
|
Convert i915->gt0 to a pointer, and allocate it dynamically.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Gustavo Sousa <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Acked-by: Michał Winiarski <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/01bf968aa431b77d491790178cbeece18b5fc4c0.1696236329.git.jani.nikula@intel.com
|
|
Have to give up the const on i915 pointer, but it's not big of a deal
considering non-const i915 gets passed all over the place.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Gustavo Sousa <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Acked-by: Michał Winiarski <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/63e644f056c7745eb0e8e165c990c392a38ec85c.1696236329.git.jani.nikula@intel.com
|
|
Backmerge to sync up with drm-intel-gt-next and drm-misc-next.
Signed-off-by: Jani Nikula <[email protected]>
|
|
Do a s/dev_priv/i915/ pass over the shared_dpll code to
get the variable names into sync with modern standards.
v2: Rebase
Reviewed-by: Jani Nikula <[email protected]> #v1
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
No one really cares how we store the shared_dplls. Currently
it happens to be an array, but we could change that to a more
flexible scheme at some point. Hide the implementation details
behind an iterator macro.
The slight downside is the pll variable moving out of the
loop scope, but maybe someday soon we'll start to convert
everything over to having declarations within for-statements...
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Stop assuming the size of PLL ID based bitmask is restricted
to I915_NUM_PLLS bits. This is the last thing coupling the
two things together and thus artificially limiting PLL IDs.
We could just pass any arbitrary (large enough) size to
for_each_set_bit() and be done with it, but the WARN
requiring the caller to not pass in a bogus bitmask seems
potentially useful to keep around. So let's just calculate
the full bitmask on the spot.
And while at it let's assert that the PLL IDs will fit
into the bitmask we use for them.
TODO: could also get rid of I915_NUM_PLLS entirely and just
dynamically allocate i915->shared_dplls[] and state->shared_dpll[].
But that would involve error handling in the modeset init path. Uff.
v2: Warn about conflicting PLL IDs (Jani)
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There's no good reason to keep around this PLL index == PLL ID
footgun. Get rid of it.
Both i915->shared_dplls[] and state->shared_dpll[] are indexed
by the same thing now, which is just the index we get at
initialization from dpll_mgr->dpll_info[]. The rest is all about
PLL IDs now.
v2: Add pll->index to mimic drm_crtc & co.
Remove the comment saying ID should match the index
v3: s/i/pll->index/ in debugfs loop (Jani)
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Adjusting ->port_mask does not belong in
intel_device_info_subplatform_init(), but rather
intel_display_device_info_runtime_init().
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/1035800e623e13d5e7baf1215b07e7cdad5eb764.1696336887.git.jani.nikula@intel.com
|
|
Move display related functionality from intel_device_info_runtime_init()
to intel_display_device_info_runtime_init() and call the latter from the
top level.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/a2226a47a4450e75d867c2ac48665b387af0e42d.1696336887.git.jani.nikula@intel.com
|
|
Anything looking at display (runtime) info should be under display.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/41b53870ffa7bd41ccc337616c756c69326f05cf.1696336887.git.jani.nikula@intel.com
|
|
There's no need for this to be a macro. Add some documentation too.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/480b9b697b2ffa0c8677115bd443ba633801c6c1.1696336887.git.jani.nikula@intel.com
|
|
FBC is supported with RGB32 8:8:8:8 with or without alpha
Bspec: 68904, 69560
Signed-off-by: Vinod Govindapillai <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In LNL onwards, FBC can be associated to the first three planes.
FBC will be enabled on planes first come first served basis
until the userspace can select one of these FBC capable planes
explicitly.
v2:
- avoid fbc->state.plane check in intel_fbc_check_plane (Ville)
- simplify plane binding register writes (Matt)
- Update the subject to reflect that fbc can be enabled only in
the first three planes (Matt)
v3:
- use icl_is_hdr_plane(), use wrapper macro for plane binding
register access, comments update and patch split (Ville)
v4:
- update to the plane binding register access macro
Bspec: 69560
Signed-off-by: Vinod Govindapillai <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|