Imre Deak [Tue, 20 Feb 2024 21:18:40 +0000 (23:18 +0200)]
drm/i915/dp: Read DPRX for all long HPD pulses
The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager
depends on the GFX driver reading out the sink's DPRX capabilities in
response to a long HPD pulse. Since in i915 this read-out can be blocked
by another connector's/encoder's hotplug event handling (which is
serialized by drm_mode_config::connection_mutex), do a dummy DPRX read-out
in the encoder's HPD pulse handler (which is not blocked by other
encoders).
Imre Deak [Tue, 20 Feb 2024 21:18:39 +0000 (23:18 +0200)]
drm/i915/dp: Suspend/resume DP tunnels
Suspend and resume DP tunnels during system suspend/resume, disabling
the BW allocation mode during suspend, re-enabling it after resume. This
reflects the link's BW management component (Thunderbolt CM) disabling
BWA during suspend. Before any BW requests the driver must read the
sink's DPRX capabilities (since the BW manager requires this
information, so snoops for it on AUX), so ensure this read takes place.
Imre Deak [Tue, 20 Feb 2024 21:18:38 +0000 (23:18 +0200)]
drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders
A follow-up change will need to resume DP tunnels during system resume,
so call intel_dp_sync_state() always for DDI encoders, so this function
can resume the tunnels for all DP connectors.
Imre Deak [Tue, 20 Feb 2024 21:18:37 +0000 (23:18 +0200)]
drm/i915/dp: Handle DP tunnel IRQs
Handle DP tunnel IRQs a sink (or rather a BW management component like
the Thunderbolt Connection Manager) raises to signal the completion of a
BW request by the driver, or to signal any state change related to the
link BW.
Imre Deak [Tue, 20 Feb 2024 21:18:35 +0000 (23:18 +0200)]
drm/i915/dp: Compute DP tunnel BW during encoder state computation
Compute the BW required through a DP tunnel on links with such tunnels
detected and add the corresponding atomic state during a modeset.
v2:
- Fix error check of intel_dp_tunnel_compute_stream_bw(). (Ville)
- Move intel_dp_tunnel_atomic_cleanup_inherited_state() to this patch.
(Ville)
- Move intel_dp_tunnel_atomic_clear_stream_bw() to this patch.
Imre Deak [Tue, 20 Feb 2024 21:18:34 +0000 (23:18 +0200)]
drm/i915/dp: Account for tunnel BW limit in intel_dp_max_link_data_rate()
Take any link BW limitation into account in
intel_dp_max_link_data_rate(). Such a limitation can be due to multiple
displays on (Thunderbolt) links with DP tunnels sharing the link BW.
Imre Deak [Tue, 20 Feb 2024 21:18:33 +0000 (23:18 +0200)]
drm/i915/dp: Add DP tunnel atomic state and check BW limit
Add the atomic state during a modeset required to enable the DP tunnel
BW allocation mode on links where such a tunnel was detected. This state
applies to an already enabled output, the state added for a newly
enabled output will be computed and added/cleared to/from the atomic
state in a follow-up patch.
v2:
- s/old_crtc_state/crtc_state in intel_crtc_duplicate_state().
- Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up
patch adding the corresponding state. (Ville)
- Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up
patch adding the corresponding state.
Imre Deak [Mon, 26 Feb 2024 18:52:46 +0000 (20:52 +0200)]
drm/i915/dp: Add support for DP tunnel BW allocation
Add support to enable the DP tunnel BW allocation mode. Follow-up
patches will call the required helpers added here to prepare for a
modeset on a link with DP tunnels, the last change in the patchset
actually enabling BWA.
With BWA enabled, the driver will expose the full mode list a display
supports, regardless of any BW limitation on a shared (Thunderbolt)
link. Such BW limits will be checked against only during a modeset, when
the driver has the full knowledge of each display's BW requirement.
If the link BW changes in a way that a connector's modelist may also
change, userspace will get a hotplug notification for all the connectors
sharing the same link (so it can adjust the mode used for a display).
The BW limitation can change at any point, asynchronously to modesets
on a given connector, so a modeset can fail even though the atomic check
for it passed. In such scenarios userspace will get a bad link
notification and in response is supposed to retry the modeset.
v2:
- Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state().
(Ville)
- Fix propagating the error from
intel_dp_tunnel_atomic_compute_stream_bw(). (Ville)
- Move tunnel==NULL checks from driver to DRM core helpers. (Ville)
- Simplify return flow from intel_dp_tunnel_detect(). (Ville)
- s/dp_tunnel_state/inherited_dp_tunnels (Ville)
- Simplify struct intel_dp_tunnel_inherited_state. (Ville)
- Unconstify object pointers (vs. states) where possible. (Ville)
- Init crtc_state while declaring it in check_group_state(). (Ville)
- Join obj->base.id, obj->name arg lines in debug prints to reduce LOC.
(Ville)
- Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the
BW allocation from encoder hooks up to intel_atomic_commit_tail()
later in the patchset.
- Disable BW alloc mode during system suspend.
- Allocate the required BW for all tunnels during system resume.
- Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded
sequence in a follow-up patch.
- Add function documentation to all exported functions.
- Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL.
v3:
- Rebase on intel_dp_get_active_pipes() change in previous patch.
Imre Deak [Mon, 26 Feb 2024 18:52:45 +0000 (20:52 +0200)]
drm/i915/dp: Sync instead of try-sync commits when getting active pipes
Sync instead of only try-sync non-blocking commits when getting the
active pipes through a given DP port. Atm intel_dp_get_active_pipes()
will only try to sync a given pipe and if that would block ignore the
pipe. This was supposed to avoid link retraining in case a pending
modeset would do that anyway, however that could incorrectly ignore
fastset pipes as well for instance (which don't retraing the link).
The TC port reset path needs to handle all pipes, even if a waiting for
a pending commit would block. To account for the above cases sync all
the pipes unconditionally.
This also prepares for a follow-up change enabling the DP tunnel BW
allocation mode which needs to ensure that all active pipes are synced
and returned from intel_dp_get_active_pipes().
v2:
- Add a separate function to try-sync the pipes. (Ville)
v3:
- Just sync the pipes unconditionally in intel_dp_get_active_pipes().
(Ville)
Imre Deak [Tue, 20 Feb 2024 21:18:30 +0000 (23:18 +0200)]
drm/i915/dp: Add intel_dp_max_link_data_rate()
Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX
BW used by a follow-up patch enabling the DP tunnel BW allocation mode.
The link BW can be below the DPRX BW due to a BW limitation on a link
shared by multiple sinks.
Imre Deak [Tue, 20 Feb 2024 21:18:24 +0000 (23:18 +0200)]
drm/i915/dp: Add support to notify MST connectors to retry modesets
On shared (Thunderbolt) links with DP tunnels, the modeset may need to
be retried on all connectors on the link due to a link BW limitation
arising only after the atomic check phase. To support this add a helper
function queuing a work to retry the modeset on a given port's connector
and at the same time any MST connector with streams through the same
port. A follow-up change enabling the DP tunnel Bandwidth Allocation
Mode will take this into use.
v2:
- Send the uevent only to enabled MST connectors. (Jouni)
Imre Deak [Tue, 20 Feb 2024 21:18:23 +0000 (23:18 +0200)]
drm/i915: Fix display bpp limit computation during system resume
The system resume display mode restoration should happen with an output
configuration matching that of the suspend time saved mode. Since the
restored mode configuration is subject to the bpp fallback logic,
starting out with an unlimited bpp and reducing the bpp as required by
any (MST) link BW limit, the resulting bpp will match the one during
suspend only if the BW limit checks during suspend and resume are
applied in an identical way. The latter is not guaranteed at the moment,
since the pre-suspend MST topology may not be in place during resume
(for instance if the MST sink was disconnected while being suspended),
which makes the MST link BW check accept the unlimited bpp mode
configuration unconditionally without ensuring that the required BW fits
into the available MST link BW.
To fix the above, initialize the bpp fallback logic with the max link
bpp / force-FEC limits left behind by the suspend time mode save.
Imre Deak [Mon, 26 Feb 2024 18:52:44 +0000 (20:52 +0200)]
drm/dp: Add support for DP tunneling
Add support for Display Port tunneling. For now this includes the
support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay
support for later.
BWA allows using displays that share the same (Thunderbolt) link with
their maximum resolution. Atm, this may not be possible due to the
coarse granularity of partitioning the link BW among the displays on the
link: the BW allocation policy is in a SW/FW/HW component on the link
(on Thunderbolt it's the SW or FW Connection Manager), independent of
the driver. This policy will set the DPRX maximum rate and lane count
DPCD registers the GFX driver will see (0x00000, 0x00001, 0x02200,
0x02201) based on the available link BW.
The granularity of the current BW allocation policy is coarse, based on
the required link rate in the 1.62Gbs..8.1Gbps range and it may prevent
using higher resolutions all together: the display connected first will
get a share of the link BW which corresponds to its full DPRX capability
(regardless of the actual mode it uses). A subsequent display connected
will only get the remaining BW, which could be well below its full
capability.
BWA solves the above coarse granularity (reducing it to a 250Mbs..1Gps
range) and first-come/first-served issues by letting the driver request
the BW for each display on a link which reflects the actual modes the
displays use.
This patch adds the DRM core helper functions, while a follow-up change
in the patchset takes them into use in the i915 driver.
v2:
- Fix prepare_to_wait vs. wake-up cond check order in
allocate_tunnel_bw(). (Ville)
- Move tunnel==NULL checks from callers in drivers to here. (Ville)
- Avoid var inits in declaration blocks that can fail or have
side-effects. (Ville)
- Use u8 for driver and group IDs. (Ville)
- Simplify API removing drm_dp_tunnel_get/put_untracked(). (Ville)
- Reuse str_yes_no() instead of a local yes_no_chr(). (Ville)
- s/drm_dp_tunnel_atomic_clear_state()/free_tunnel_state() and unexport
the function. (Ville)
- s/clear_tunnel_group_state()/free_group_state() and move kfree() to
this function. (Ville)
- Add separate group_free_bw() helper and describe what the tunnel
estimated BW includes. (Ville)
- Improve help text for CONFIG_DRM_DISPLAY_DP_TUNNEL. (Ville)
- Add code comment explaining the purpose of DPCD reg read helpers.
(Ville)
- Add code comment describing the tunnel group name prefix format.
(Ville)
- Report the allocated BW as undetermined until the first allocation
request.
- Skip allocation requests matching the previous request.
- Clear any stale BW request status flags before a new request.
- Add missing error return check of drm_dp_tunnel_atomic_get_group_state()
in drm_dp_tunnel_atomic_set_stream_bw().
- Add drm_dp_tunnel_get_allocated_bw().
- s/drm_dp_tunnel_atomic_get_tunnel_bw/drm_dp_tunnel_atomic_get_required_bw
- Fix return value description in function doc of drm_dp_tunnel_detect().
- Add function documentation to all exported functions.
v3:
- Improve grouping of fields in drm_dp_tunnel_group struct. (Uma)
- Fix validating the BW granularity DPCD reg value. (Uma)
- Document return value of check_and_clear_status_change(). (Uma)
- Fix resetting drm_dp_tunnel_ref::tunnel in drm_dp_tunnel_ref_put().
(Ville)
- Allow for ALLOCATED_BW to change after a BWA enable/disable sequence.
Imre Deak [Mon, 26 Feb 2024 18:52:43 +0000 (20:52 +0200)]
drm/dp: Add drm_dp_max_dprx_data_rate()
Copy intel_dp_max_data_rate() to DRM core. It will be needed by a
follow-up DP tunnel patch, checking the maximum rate the DPRX (sink)
supports. Accordingly use the drm_dp_max_dprx_data_rate() name for
clarity. This patchset will also switch calling the new DRM function
in i915 instead of intel_dp_max_data_rate().
While at it simplify the function documentation/comments, removing
parts described already by drm_dp_bw_channel_coding_efficiency().
v2: (Ville)
- Remove max_link_rate_kbps.
- Simplify the function documentation.
v3:
- Rebased on latest drm-tip.
Suraj Kandpal [Mon, 26 Feb 2024 06:30:52 +0000 (12:00 +0530)]
drm/i915/hdcp: Read Rxcaps for robustibility
We see some monitors and docks report incorrect hdcp version
and capability in first few reads so we read rx_caps three times
before we conclude the monitor's or docks HDCP capability
--v2
-Add comment to justify the 3 time read loop for hdcp capability[Ankit]
Suraj Kandpal [Mon, 26 Feb 2024 06:30:51 +0000 (12:00 +0530)]
drm/i915/hdcp: Allocate stream id after HDCP AKE stage
Allocate stream id after HDCP AKE stage and not before so that it
can also be done during link integrity check.
Right now for MST scenarios LIC fails after hdcp enablement for this
reason.
--v2
-no need for else block in prepare_streams function [Ankit]
--v3
-remove intel_hdcp argument from required_content_stream function
[Ankit]
Suraj Kandpal [Mon, 26 Feb 2024 06:30:50 +0000 (12:00 +0530)]
drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link
Whenever LIC fails instead of moving from ENABLED to DESIRED
CP property we directly enable HDCP1.4 without informing the userspace
of this failure in link integrity check.
Now we will just update the value to DESIRED send the event to
userspace and then continue with the normal flow of HDCP enablement.
Suraj Kandpal [Mon, 26 Feb 2024 06:30:49 +0000 (12:00 +0530)]
drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link
Whenever LIC fails instead of moving from ENABLED to DESIRED
CP property we directly enable HDCP2.2 without informing the userspace
of this failure in link integrity check.
Now we will just update the value to DESIRED send the event to
userspace and then continue with the normal flow of HDCP enablement.
--v2
-Don't change the function prototype in this function [Ankit]
Suraj Kandpal [Fri, 23 Feb 2024 08:14:48 +0000 (13:44 +0530)]
drm/i915/hdcp: HDCP Capability for the downstream device
Currently we are only checking capability of remote device and not
immediate downstream device but during capability check we need are
concerned with only the HDCP capability of downstream device.
During i915_display_info reporting we need HDCP Capability for both
the monitors and downstream branch device if any this patch adds that.
--v2
-Use MST Hub HDCP version [Ankit]
--v3
-Redefined how we seprate remote and direct read to make sure HDMI
shim functions are not touched [Ankit]
--v4
- Fix the conditions so that hdcp_info with remote_req true is sent
only when encoder is mst [Ankit]
--v5
-No need to have the MST Hub version in i915_hdcp_sink_capability[Ankit]
Suraj Kandpal [Fri, 23 Feb 2024 08:14:42 +0000 (13:44 +0530)]
drm/i915/hdcp: Move to direct reads for HDCP
Even for MST scenarios we need to do direct reads only on the
immediate downstream device the rest of the authentication is taken
care by that device. Remote reads will only be used to check
capability of the monitors in MST topology.
--v2
-Add fixes tag [Ankit]
-Derive aux where needed rather than through a function [Ankit]
Bhanuprakash Modem [Wed, 21 Feb 2024 11:12:23 +0000 (16:42 +0530)]
drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status
If the connected panel supports both DRRS & PSR, driver gives preference
to PSR ("DRRS enabled: no"). Even though the hardware supports DRRS,
IGT treats ("DRRS enabled: yes") as not capable.
Introduce a new entry "DRRS capable" to debugfs i915_drrs_status, so
that IGT will read the DRRS capability as "DRRS capable: yes".
Suraj Kandpal [Mon, 19 Feb 2024 06:36:38 +0000 (12:06 +0530)]
drm/i915/lnl: Program PKGC_LATENCY register
If fixed refresh rate program the PKGC_LATENCY register
with the highest latency from level 1 and above LP registers
and program ADDED_WAKE_TIME = DSB execution time.
else program PKGC_LATENCY with all 1's and ADDED_WAKE_TIME as 0.
This is used to improve package C residency by sending the highest
latency tolerance requirement (LTR) when the planes are done with the
frame until the next frame programming window (set context latency,
window 2) starts.
Bspec: 68986
--v2
-Fix indentation [Chaitanya]
--v3
-Take into account if fixed refrersh rate or not [Vinod]
-Added wake time dependengt on DSB execution time [Vinod]
-Use REG_FIELD_PREP [Jani]
-Call program_pkgc_latency from appropriate place [Jani]
-no need for the ~0 while setting max latency [Jani]
-change commit message to add the new changes made in.
--v4
-Remove extra blank line [Vinod]
-move the vrr.enable check to previous loop [Vinod]
Maxime Ripard [Tue, 20 Feb 2024 13:12:51 +0000 (14:12 +0100)]
drm/i915/tv: Fix TV mode
Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
to update all the users of the struct drm_tv_connector_state mode field,
which resulted in a build failure in i915.
However, a subsequent commit in the same series reintroduced a mode
field in that structure, with a different semantic but the same type,
with the assumption that all previous users were updated.
Since that didn't happen, the i915 driver now compiles, but mixes
accesses to the legacy_mode field and the newer mode field, but with the
previous semantics.
This obviously doesn't work very well, so we need to update the accesses
that weren't in the legacy renaming commit.
Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220131251.453060-1-mripard@kernel.org
intel_vgpu_gtt::active_ppgtt_mm_bitmap was never used since its
addition in commit 2707e4446688 (drm/i915/gvt: vGPU graphics memory
virtualization). Drop it.
Found by https://github.com/jirislaby/clang-struct.
i915_perf_stream::size_exponent was never used since its addition in
commit a37f08a882b0 (drm/i915/perf: Refactor oa object to better manage
resources). Drop it.
Found by https://github.com/jirislaby/clang-struct.
intel_guc::ads_engine_usage_size was never used since its addition in
commit 77cdd054dd2c (drm/i915/pmu: Connect engine busyness stats from
GuC to pmu). Drop it.
Found by https://github.com/jirislaby/clang-struct.
intel_vgpu_workload::ring_context was never used since its addition in
commit 28c4c6ca7f79 (drm/i915/gvt: vGPU workload submission) and
::restore_inhibit since its addition in commit e473405783c0
(drm/i915/gvt: vGPU workload scheduler). Drop them.
Found by https://github.com/jirislaby/clang-struct.
intel_gvt_mmio_info::device is not used since commit e0f74ed4634d
(i915/gvt: Separate the MMIO tracking table from GVT-g) and ::addr_range
was never used since its addition in commit 12d14cc43b34 (drm/i915/gvt:
Introduce a framework for tracking HW registers.). Drop them.
Found by https://github.com/jirislaby/clang-struct.
intel_gvt_gtt::{mm_alloc_page_table,mm_free_page_table} are not used
since commit ede9d0cfcb78 (drm/i915/gvt: Rework shadow graphic memory
management code). Drop them.
Found by https://github.com/jirislaby/clang-struct.
intel_dsi::port_bits is unused since commit 369602d370fa (drm/i915: Add
support for port enable/disable for dual link configuration) and ::hs is
unused likely since commit 063c86f60ad4 (drm/i915/dsi: remove
intel_dsi_cmd.c and the unused functions therein). Drop them.
Found by https://github.com/jirislaby/clang-struct.
drm/i915: remove structs intel_vgpu_pipe_format and intel_vgpu_fb_format
Both struct intel_vgpu_pipe_format and intel_vgpu_fb_format were never
used since its addition in commit 9f31d1063b43 (drm/i915/gvt: Add
framebuffer decoder support). Drop them.
Found by https://github.com/jirislaby/clang-struct.
struct intel_dvo_dev_ops's ::create_resources(), ::prepare(),
::commit::, and get_modes() are all unused since their addition in 79e539453b34 (DRM: i915: add mode setting support). Drop all of them.
Found by https://github.com/jirislaby/clang-struct.
Ville Syrjälä [Wed, 7 Feb 2024 01:33:33 +0000 (03:33 +0200)]
drm/i915/cdclk: Remove the hardcoded divider from cdclk_compute_crawl_and_squash_midpoint()
cdclk_compute_crawl_and_squash_midpoint() was still assuming
that cd2x divider == 1 (ie. full divider == 2). Remove that
assumption by computing the dividers properly.
We'll also toss in a WARN in case the divider somehow ends
up different between the old and new cdclk configs. That should
never happen given we have div==2 in all the cdclk table entries
for the affected platforms.
If in the future we need a config where the divider also needs
to be changed then we likely need to add an extra step into the
cdclk programming sequence to make sure things stay within
legal limits throughout the process.
Ville Syrjälä [Wed, 7 Feb 2024 01:33:31 +0000 (03:33 +0200)]
drm/i915/cdclk: Extract cdclk_divider()
Extract the cdclk divider calculation into a helper. We'll have
more users of this soon. We can now also get rid of the intermediate
'unsquashed_cdclk' variable.
Ville Syrjälä [Fri, 9 Feb 2024 18:38:09 +0000 (20:38 +0200)]
drm/i915: Enable fastboot across the board
There's nothing magical about vlv+ platforms vs. fastboot.
If it works somewhere it should work everywhere, assuming
we've not missed any crucial state checks. That seems unlikely
on older platforms with less state to check anyway.
Just enable fastboot across the board, and the remove the
remnants of the optional stuff (we already removed the
modparam for fastboot anyway).
Ville Syrjälä [Fri, 9 Feb 2024 18:38:08 +0000 (20:38 +0200)]
drm/i915: Add PLL .compare_hw_state() vfunc
Chunk up the humongous dpll_hw_state comparison check into per-platform
variants, implemented in the dpll_mgr. This is step one in allowing
each platform (or perhaps even PLL) type to have a custom hw state
structure instead of having to smash it all into one.
Imre Deak [Mon, 12 Feb 2024 17:52:37 +0000 (19:52 +0200)]
drm/i915: Prevent HW access during init from connector get_modes hooks
Prevent accessing the HW from the get_modes hooks of connectors deriving
the mode list from the display's EDID. drm_edid_connector_add_modes()
will return the mode list based on the EDID which was cached during a
previous detection/get_modes call.
This also fixes the NULL deref problem (10085) which was
introduced/revealed by
commit bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown")
After the above change MST connectors will not change state during
driver init/shutdown; thus some of these connectors with no I2C/DDC
adapter registered for them (since the given MST port has no sink
connected) may stay then in the 'unknown' connector status. The
get_modes() hook should not try to use the I2C/DDC adapter in this state
(which would lead to the above NULL deref) which this patch ensures.
v2:
- Remove the redundant check from intel_crt_ddc_get_modes().
- Rebase on latest drm-tip.
- Add Fixes: line / related commit notes.
Imre Deak [Mon, 12 Feb 2024 17:52:36 +0000 (19:52 +0200)]
drm/i915: Prevent HW access during init from SDVO TV get_modes hook
Prevent accessing the HW from the SDVO/TV get_modes connector hook.
Returning 0 from the hook will make the caller -
drm_helper_probe_single_connector_modes() - return a default/EDID
override mode list to users. This matches the case where
intel_sdvo_get_tv_modes() fails to retrieve the current mode list due to
a HW access failure.
v2: Clarify the commit message wrt. which modes get_modes() returns. (Jouni)
Stanislav Lisovskiy [Mon, 12 Feb 2024 12:50:11 +0000 (18:20 +0530)]
drm/i915: Add bigjoiner force enable option to debugfs
For validation purposes, it might be useful to be able to
force Bigjoiner mode, even if current dotclock/resolution
do not require that.
Lets add such to option to debugfs.
v2: - Apparently intel_dp_need_bigjoiner can't be used, when
debugfs entry is created so lets just check manually
the DISPLAY_VER.
v3: - Switch to intel_connector from drm_connector(Jani Nikula)
- Remove redundant modeset lock(Jani Nikula)
- Use kstrtobool_from_user for boolean value(Jani Nikula)
v4: - Apply the changes to proper function(Jani Nikula)
v5: - Removed unnecessary check from i915_bigjoiner_enable_show
(Ville Syrjälä)
- Added eDP connector check to intel_connector_debugfs_add
(Ville Syrjälä)
- Removed debug message in order to prevent dmesg flooding
(Ville Syrjälä)
v6: - Assume now always that m->private is intel_connector
- Fixed other similar conflicts
v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
- Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
manually.(Ville Syrjälä)
v8: - Pass intel_connector to debugfs_create_file, instead of drm_connector.
(Jani Nikula)
Ville Syrjälä [Thu, 8 Feb 2024 15:17:15 +0000 (17:17 +0200)]
drm/i915/hdcp: Use per-device debugs
Switch to per-device debugs in the hdcp code so we see at least which
device is involved. Should proably also print the connector/encoder/etc.
in there, but left that for the future.
Ville Syrjälä [Thu, 8 Feb 2024 15:45:52 +0000 (17:45 +0200)]
drm/i915/dp: Limit SST link rate to <=8.1Gbps
Limit the link rate to HBR3 or below (<=8.1Gbps) in SST mode.
UHBR (10Gbps+) link rates require 128b/132b channel encoding
which we have not yet hooked up into the SST/no-sideband codepaths.
Manasi Navare [Mon, 5 Feb 2024 20:46:19 +0000 (20:46 +0000)]
drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address
Commit bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS
register") defines a new macro to calculate the DSC PPS register
addresses with PPS number as an input. This macro correctly calculates
the addresses till PPS 11 since the addresses increment by 4. So in that
case the following macro works correctly to give correct register
address:
_MMIO(_DSCA_PPS_0 + (pps) * 4)
However after PPS 11, the register address for PPS 12 increments by 12
because of RC Buffer memory allocation in between. Because of this
discontinuity in the address space, the macro calculates wrong addresses
for PPS 12 - 16 resulting into incorrect DSC PPS parameter value
read/writes causing DSC corruption.
This fixes it by correcting this macro to add the offset of 12 for PPS
>=12.
v3: Add correct paranthesis for pps argument (Jani Nikula)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10172 Fixes: bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS register") Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <sean@poorly.run> Cc: Drew Davenport <ddavenport@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205204619.1991673-1-navaremanasi@chromium.org
Jouni Högander [Tue, 30 Jan 2024 11:11:29 +0000 (13:11 +0200)]
drm/i915/alpm: Calculate ALPM Entry check
ALPM Entry Check represents the number of lines needed to put the main link
to sleep and keep it in the sleep state before it can be taken out of the
SLEEP state (eDP requires the main link to be in the SLEEP state for a
minimum of 5us).
Bspec: 71477
v2: move display version check into _lnl_compute_alpm_param
Ville Syrjälä [Fri, 2 Feb 2024 22:43:39 +0000 (00:43 +0200)]
drm/i915: Try to relocate the BIOS fb to the start of ggtt
On MTL the GOP (for whatever reason) likes to bind its framebuffer
high up in the ggtt address space. This can conflict with whatever
ggtt_reserve_guc_top() is trying to do, and the result is that
ggtt_reserve_guc_top() fails and then we proceed to explode when
trying to tear down the driver. Thus far I haven't analyzed what
causes the actual fireworks, but it's not super important as even
if it didn't explode we'd still fail the driver load and the user
would be left with an unusable GPU.
To remedy this (without having to figure out exactly what
ggtt_reserve_guc_top() is trying to achieve) we can attempt to
relocate the BIOS framebuffer to a lower ggtt address. We can do
this at this early point in driver init because nothing else is
supposed to be clobbering the ggtt yet. So we simply change where
in the ggtt we pin the vma, the original PTEs will be left as is,
and the new PTEs will get written with the same dma addresses.
The plane will keep on scanning out from the original PTEs until
we are done with the whole process, and at that point we rewrite
the plane's surface address register to point at the new ggtt
address.
Since we don't need a specific ggtt address for the plane
(apart from needing it to land in the mappable region for
normal stolen objects) we'll just try to pin it without a fixed
offset first. It should end up at the lowest available address
(which really should be 0 at this point in the driver init).
If that fails we'll fall back to just pinning it exactly to the
origianal address.
To make sure we don't accidentlally pin it partially over the
original ggtt range (as that would corrupt the original PTEs)
we reserve the original range temporarily during this process.
v2: Try to pin explicitly to ggtt offset 0 as otherwise DG2 puts it
even higher (atm we have no PIN_LOW flag to force it low)
v3: "fix" xe
Ville Syrjälä [Fri, 2 Feb 2024 22:43:38 +0000 (00:43 +0200)]
drm/i915: Tweak BIOS fb reuse check
Currently we assume that we bind the BIOS fb exactly into the same
ggtt address where the BIOS left it. That is about to change, and
in order to keep intel_reuse_initial_plane_obj() working as intended
we need to compare the original ggtt offset (called 'base' here)
as opposed to the actual vma ggtt offset we selected. Otherwise
the first plane could change the ggtt offset, and then subsequent
planes would no longer notice that they are in fact using the same
ggtt offset that the first plane was already using. Thus the reuse
check will fail and we proceed to turn off these subsequent planes.
TODO: would probably make more sense to do the pure readout first
for all the planes, then check for fb reuse, and only then proceed
to pin the object into the final location in the ggtt...
Ville Syrjälä [Fri, 2 Feb 2024 22:43:37 +0000 (00:43 +0200)]
drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objects
The "io" address of an object is its dma address minus the
region.start. Subtract the latter to make smem_start correct.
The current code happens to work for genuine LMEM objects
as LMEM region.start==0, but for LMEMBAR stolen objects
region.start!=0.
TODO: perhaps just set smem_start=0 always as our .fb_mmap()
implementation no longer depends on it? Need to double check
it's not needed for anything else...
There's no reason the caller of intel_initial_plane_config() should
have to loop over the CRTCs. Pull the loop into the function to
make life simpler for the caller.
projects / users / jedix / linux-maple.git / log