| Age | Commit message (Collapse) | Author |
|---|
|
calls
The display driver init and cleanup calls are slightly asymmetric. The
cleanup order should be intel_display_driver_remove_noirq() and
intel_display_driver_remove_nogem(), not the other way around. This is
also what i915 does. Follow suit in xe.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/afb11c4e11cc4d946f0360aaad1664d004a93f41.1781549229.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The intel_opregion_setup(), intel_dram_detect(), and intel_bw_init_hw()
calls should really be in display. Move them at the beginning of
intel_display_driver_probe_noirq().
This is a completely non-functional change for xe.
For i915, the init order changes slightly:
- i915_pcode_init() will happen before intel_opregion_setup(). This
should be of no consequence.
- The intel_gvt_init() calls will happen before the mentioned
functions. There's a lot going on in intel_gvt_init(), but it does not
look like this should have dependencies on them either.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/aa37d6443516ae660c2de53aba8ca42e6e6d1a5c.1781549229.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
pci_disable_msi() checks for pdev->msi_enabled internally. There's no
need to peek at pdev internals in i915. Remove them.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/71f61eee227178b61af9c1211be8545828a3f3ef.1781549229.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Having display probe be called from i915_driver_create() is slightly
misleading, and an artefact from the past. Move the
intel_display_device_probe() call a level higher.
Use the shared PCI disable error path while at it.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/c97a8790a5cb1f6b10061286adad8148972c5b3b.1781549229.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Currently, xe_display_bo_framebuffer_init() unconditionally attempts to
apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with
-EINVAL if the BO is already VM_BINDed.
However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem
to make much sense since CPU caching policy is entirely controlled by
the exporter. Plus there is no place to set this flag, in the first
place. Also this is not rejected if not yet vm_binded, but that seems
arbitrary since setting or not setting FORCE_WC should a noop either
way, at this stage, and whether it is currently VM_BINDed makes no
difference.
Currently if we run an app and offload rendering to an external dGPU,
like NV or another xe device, the dma-buf passed back to the compositor
(igpu) will be an actual external import from xe pov, and it will be
missing FORCE_WC, and if the compositor side did a VM_BIND before
turning into it into an fb the whole thing gets rejected.
So it looks like we either need to reject outright, no matter what, or
this usecase is valid and we need to loosen the restriction for sg
buffers. Proposing here to loosen the restriction.
Assisted-by: Gemini:gemini-3.1-pro-preview
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260612170501.550816-2-matthew.auld@intel.com
|
|
Non-migratable faults that require devmem incorrectly jump to the 'out'
label, which squashes the error code intended to be returned to the
upper layers. Fix this by returning -EACCES instead.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 4208fac3dce5 ("drm/xe: Add more SVM GT stats")
Cc: stable@vger.kernel.org
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Francois Dugast <francois.dugast@intel.com>
Link: https://patch.msgid.link/20260617135101.1245574-1-matthew.brost@intel.com
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
drm-misc-fixes for v7.2:
- drm/sysfb truncation and alignment fixes.
- fix edid OOB read.
- fix error handling paths in nouveau
- amdxdna get_bo_info fix.
- increase displayid topology id to correct size.
- fix leak when error handling in ivpu.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/2d17f718-43f5-4772-9c04-a975c9ad4bc3@linux.intel.com
|
|
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
- Fix corrupted display output on GLK, #16209 (Ville)
- Add missing Spectre mitigation for parallel submit IOCTL (Joonas)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patch.msgid.link/ajzIhInnHnGCwMlu@jlahtine-mobl
|
|
No functional changes intended.
Signed-off-by: Gary Guo <gary@garyguo.net>
Acked-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260610141359.1033755-1-gary@kernel.org
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
lc variable took it's name as an acronym from struct
intel_dp_link_config. Rename the variable into lce since the struct was
renamed into intel_dp_link_config_entry.
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260623224619.1949975-30-michal.grzelak@intel.com
|
|
Since CNL got nuked cnp_encoder_to_ddc_pin() will never
see a port F. Remove the leftovers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623125111.6632-7-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
|
|
The modern GMBUS pin numbers are just a sequential set of
numbers, so the platform suffixes don't really buy us anything.
Let's just drop them. We'll keep the _TCx suffixes for pins
9+ since that's the way they always get used.
v2: Deal with gvt
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623141117.24115-1-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
|
|
The GMBUS pin pair <-> GPIO mapping is purely a property
of the PCH (on the platforms where GMBUS lives in the PCH).
So rename gmbus_pins_skl[] to gmbus_pins_spt[] and apply
it based on the presence of the correct PCH type.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623125111.6632-5-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
|
|
LPT/WPT-LP don't have as many GPIO pins as the -H variants.
Add proper mapping for the -LP PCHs so that we can't end up
poking at non-existent GPIOs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623125111.6632-4-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
|
|
The GMBUS pin pair <-> GPIO mapping is purely a property
of the PCH (on the platforms where GMBUS lives in the PCH).
So rename gmbus_pins_bdw[] to gmbus_pins_lpt[] and extend
it to cover all platforms with LPT/WPT PCHs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623125111.6632-3-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
|
|
Replace the alphabetical GPIOA,GPIOB,... with numeric
GPIO_0,GPIO_1,... This makes the naming scheme agree with
BSpec. No idea why the alphabetical naming was originally
chosen as BSpec never used that convention for the GPIO pins.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623125111.6632-2-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
|
|
Pass the link_caps pointer to the common rate helpers in
intel_dp_link_caps.c, as it holds the state with the relevant
information.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-29-imre.deak@intel.com
|
|
Pass the link_caps pointer to the update/lookup helpers in
intel_dp_link_caps.c, as it holds the state with the relevant
information.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-28-imre.deak@intel.com
|
|
Pass the link_caps pointer to static functions in intel_dp_link_caps.c,
as it holds the state with the relevant information.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-27-imre.deak@intel.com
|
|
Now that all users access the max link limits via helpers, move tracking
of these limits from struct intel_dp to the link_caps state.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-26-imre.deak@intel.com
|
|
Add a helper to reset the link_caps state, removing all restrictions
except user-forced parameters, re-allowing all supported
configurations. Currently this only resets the maximum link limits,
but follow-up changes will also re-enable configurations previously
disabled on a per-configuration basis by fallback or other logic.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-25-imre.deak@intel.com
|
|
Add a helper to reset the link_caps::max_limits max link limits to the
maximum common supported rate and lane count.
This is needed by a follow-up change in the link training fallback code,
which temporarily resets max_limits before searching for a fallback
configuration.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-24-imre.deak@intel.com
|
|
Add intel_dp_link_caps_set_max_limits() to set the current maximum link
limits (max bound over all allowed configurations) through the link caps
API instead of direct accesses.
This allows tracking the state internally within the link caps module.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-23-imre.deak@intel.com
|
|
Add intel_dp_link_caps_get_max_limits() to query the current maximum
link limits (max bound over all allowed configurations) through the
link caps API instead of direct accesses.
This allows tracking the state internally within the link caps module.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-22-imre.deak@intel.com
|
|
Convert all users of intel_dp_max_common_lane_count() to query the
maximum common lane count via the link capability API, in common with
the link rate queries.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-21-imre.deak@intel.com
|
|
Pass the maximum common lane count to intel_dp_link_caps_update() and
track it together with the supported link rates. This prepares for
converting all users of intel_dp_max_common_lane_count() to query the
value from the link caps module instead.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-20-imre.deak@intel.com
|
|
Now that all users access the supported link rates via helpers, move
tracking of these rates from struct intel_dp to the link_caps state.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-19-imre.deak@intel.com
|
|
Add intel_dp_link_caps_common_rate_idx() to look up supported link rates
tracked by the link_caps module by rate. This prepares for tracking these
capabilities internally within the link caps module.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-18-imre.deak@intel.com
|
|
Add intel_dp_link_caps_num_common_rates() to return the number of
supported link rates tracked by the link_caps module. This prepares for
tracking these capabilities internally within the link caps module.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-17-imre.deak@intel.com
|
|
Add intel_dp_link_caps_print_rates() to print all the supported link
rates tracked by the link_caps module. This prepares for tracking
these capabilities internally within the link caps module.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-16-imre.deak@intel.com
|
|
Pass the supported link rates explicitly to intel_dp_link_caps_update().
This prepares for tracking these capabilities internally within the
link caps module.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-15-imre.deak@intel.com
|
|
Factor out a helper to get the supported link rates. This allows to
gather all the link capabilities and pass these to the link capability
module from a single place. A follow-up change will extend this to
gather and pass the maximum lane count capability in the same way.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-14-imre.deak@intel.com
|
|
Rename the helper updating link configurations to
intel_dp_link_caps_update() to better reflect its functionality.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-13-imre.deak@intel.com
|
|
Move tracking of the link configurations from struct intel_dp to struct
intel_dp_link_caps.
Previous changes moved the helpers operating on configurations to the
link caps module, so the state can now be kept internal to that module.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-12-imre.deak@intel.com
|
|
Move the helpers handling link configurations to intel_dp_link_caps.c.
Their functionality is part of the link capability logic and will be
updated to use the link capability state in follow-up changes.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-11-imre.deak@intel.com
|
|
Move tracking of the forced link parameters from struct intel_dp to
struct intel_dp_link_caps.
Previous changes made all users access these parameters through the link
caps helpers, so the state can now be kept internal to the link caps
module.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-10-imre.deak@intel.com
|
|
Use intel_dp_link_caps_get_forced_params() in the link training fallback
code instead of directly accessing the state. This allows the link caps
module to track changes to forced parameters internally.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-9-imre.deak@intel.com
|
|
Move the debugfs entries for the forced and max DP link parameters to
intel_dp_link_caps. Their functionality is part of the link capability
logic and will be updated to use the link capability state in follow-up
changes.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-8-imre.deak@intel.com
|
|
Simplify querying the forced link rate and lane count by
performing the zero checks inside the helpers, allowing callers
to use the returned values directly.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-7-imre.deak@intel.com
|
|
Move the helpers handling forced link parameters to intel_dp_link_caps.c.
Their functionality is part of the link capability logic and will be
updated to use the link capability state in follow-up changes.
Return the forced link rate and lane count through a
struct intel_dp_link_config, which is the canonical way the rest of the
link capability API will also accept and return link configurations.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-6-imre.deak@intel.com
|
|
Move the helpers handling common link rates to intel_dp_link_caps.c.
Their functionality is part of the link capability logic and will be
updated to use the link capability state in follow-up changes.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-5-imre.deak@intel.com
|
|
Start isolating the DP link capability logic from the generic DP code by
adding a separate intel_dp_link_caps module and a corresponding state
object.
Allocate the state so it can remain opaque within its module.
Follow-up changes will move link capability helpers and state from
intel_dp.c and intel_dp_link_training.c to the new module and state.
v2: Remove unnecessary function documentation. (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-4-imre.deak@intel.com
|
|
Add a struct representing the public unpacked format of a link
configuration. This will be used by the DP link capability API added
as a follow-up, and by DP code in general that needs to track a link
configuration.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-3-imre.deak@intel.com
|
|
Rename intel_dp_link_config to intel_dp_link_config_entry to prepare
for tracking a link configuration in both an internal packed and a
public unpacked format. A follow-up change will add
struct intel_dp_link_config representing the public unpacked format.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-2-imre.deak@intel.com
|
|
Adjust the panel fixed mode selection algorithm to only consider
fixed modes that are "VRR compatible" with the old fixed mode
when userspace doesn't want to allow full modesets. This will
allow a VRR based refresh rate changes (ie. just a change in
the vblank length) via the fastset path.
When full modesets are allowed, we still use the original algorithm
as that may pick a fixed mode with a more optimal dotclock, potentially
leading to reduced power consumption.
This approach works as long as userspace does the initial
allow_modeset=true commit using the highest refresh rate it will
want to use. Subsequent commits with allow_modeset=false can then
switch between lower refresh rates without blinks.
One remaining hurdle we may need to solve is the guardband length.
Assuming the highest refresh rate vblank is too short for
intel_vrr_compute_optimized_guardband() the intitial guardband will
match the highest refresh rate vblank. A subsequent switch to a lower
refresh rate will then recompute the guardband and select a value
that is higher (since the vblank will be longer). The mismatch in
guardband lengths will prevent the fastset. We may either have to
preserve the original (sub-optimal) guardband, or we'll have to
revisit the idea of changing the guardband without a full modeset.
Note that I'm not 100% happy with this solution because
intel_panel_fixed_mode() is no longer fully idempotent, but I wasn't
able to come up with anything truly better either :/ The simple
solution would be just to always pick the fixed mode with the highest
dotclock, but that could lead to increased power consumption even
when high refresh rates are never used.
Perhaps the proper solution would be to just deprecate this
idea of taking in random modes for internal panels and then
cooking up a compatible fixed modes. Life would be easier if
userspace was required to provide the desired fixed mode directly.
But in order to do that we'd need to introduce new uapi properties
to control the pfit aspect of this, and we'd probably need a new
client cap to select between the old and new userspace behaviour.
Something to consider in the future...
v2: Rebase due to earlier changes to VRR fixed mode selection
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260622213602.7244-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
Pass the full atomic state to intel_panel_compute_config(). We'll
need this for some upcoming VRR fastset tricks. And to accompany
full state we'll also need the crtc (or its state) as well.
v2: Rebase
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623114130.7333-1-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
Upcoming changes will need access to the full atomic state
in .compute_config(). Pass it in from the top.
Couple of the implementations already dug this out via the
crtc_state/conn_state->state pointer, but we don't want to
use that anywhere because it's a bit of a footgun by only
being valid during the early stages of the commit.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260622213602.7244-4-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add a new mode matching flag DRM_MODE_MATCH_TIMINGS_VRR. This is
identical to DRM_MODE_MATCH_TIMINGS, except it requires the vsync
pulse to remain anchored to the end of vtotal, as opposed to the
start of the frame. VRR capable hardware can therefore treat
matching modes as just variants of the same mode with a different
vblank lengths.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260622213602.7244-3-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
separate stages
Split the VRR vs. fixed refresh rate fixed mode selection into two
completely separate stages. First try the VRR method, which will
only accept fixed modes that are in the VRR range and whose refresh
rate is equal or higher to the user's requested mode's refresh rate.
If the VRR method doesn't find anything we fall back to the fixed
refresh rate method of simply looking for the fixed mode with the
closest refresh rate to the user's request.
The main benefit is that we will only perform the VRR vtotal adjustment
on fixed modes that have equal or higher refresh rate to the user's
requested mode, thus we will never end up in a situation where we'd
have to shrink the fixed mode's vtotal. This avoids any risk of ending
up with a vtotal that is too short.
v2: Drop redundant intel_panel_fixed_mode() call (Ankit)
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623114035.7185-1-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
Remove the 'err' local variable in drm_fb_helper_hotplug_event() which
only stores a return value that is never used beyond the immediate
return statement. This simplifies the code without behavior changes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260602-dw-hdmi-qp-scramb-v7-1-445eb54ee1ed@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
