Dave Airlie [Fri, 1 Mar 2024 09:28:13 +0000 (19:28 +1000)]
Merge tag 'drm-msm-next-2024-02-29' of https://gitlab.freedesktop.org/drm/msm into drm-next
Updates for v6.9:
Core:
- Correct bindings for MSM8976 and SM8650 platforms
- Start migration of MDP5 platforms to DPU driver
- X1E80100 MDSS support
DPU:
- Improve DSC allocation, fixing several important corner cases
- Add support for SDM630/SDM660 platforms
- Simplify dpu_encoder_phys_ops
- Apply fixes targeting DSC support with a single DSC encoder
- Apply fixes for HCTL_EN timing configuration
- X1E80100 support
DP:
- Refactor parser and power submodules
DSI:
- Clean up obsolete set_split_display support
- Update DSC documentation
MDP5:
- Clean up obsolete set_split_display support
GPU:
- fix sc7180 UBWC config
- fix a7xx LLC config
- new gpu support: a305B, a750, a702
- machine support: SM7150 (different power levels than other a618)
- a7xx devcoredump support
Maxime Ripard [Fri, 1 Mar 2024 08:02:49 +0000 (09:02 +0100)]
drm/sun4i: hdmi: Add missing drm_atomic header
Commit 358e76fd613a ("drm/sun4i: hdmi: Consolidate atomic_check and
mode_valid") added a call to drm_atomic_get_new_connector_state() but
didn't include drm_atomic.h which defines it.
On some configuration, this leads to a build failure, presumably because
in the common case the header gets included by an intermediate header
but it isn't always the case.
Hsin-Yi Wang [Fri, 23 Feb 2024 21:23:29 +0000 (13:23 -0800)]
drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip
It's possible that mtk_crtc->event is NULL in
mtk_drm_crtc_finish_page_flip().
pending_needs_vblank value is set by mtk_crtc->event, but in
mtk_drm_crtc_atomic_flush(), it's is not guarded by the same
lock in mtk_drm_finish_page_flip(), thus a race condition happens.
Consider the following case:
CPU1 CPU2
step 1:
mtk_drm_crtc_atomic_begin()
mtk_crtc->event is not null,
step 1:
mtk_drm_crtc_atomic_flush:
mtk_drm_crtc_update_config(
!!mtk_crtc->event)
step 2:
mtk_crtc_ddp_irq ->
mtk_drm_finish_page_flip:
lock
mtk_crtc->event set to null,
pending_needs_vblank set to false
unlock
pending_needs_vblank set to true,
step 2:
mtk_crtc_ddp_irq ->
mtk_drm_finish_page_flip called again,
pending_needs_vblank is still true
//null pointer
Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more
efficient to just check if mtk_crtc->event is null before use.
drm/dp: Don't attempt AUX transfers when eDP panels are not powered
If an eDP panel is not powered on then any attempts to talk to it over
the DP AUX channel will timeout. Unfortunately these attempts may be
quite slow. Userspace can initiate these attempts either via a
/dev/drm_dp_auxN device or via the created i2c device.
Making the DP AUX drivers timeout faster is a difficult proposition.
In theory we could just poll the panel's HPD line in the AUX transfer
function and immediately return an error there. However, this is
easier said than done. For one thing, there's no hard requirement to
hook the HPD line up for eDP panels and it's OK to just delay a fixed
amount. For another thing, the HPD line may not be fast to probe. On
parade-ps8640 we need to wait for the bridge chip's firmware to boot
before we can get the HPD line and this is a slow process.
The fact that the transfers are taking so long to timeout is causing
real problems. The open source fwupd daemon sometimes scans DP busses
looking for devices whose firmware need updating. If it happens to
scan while a panel is turned off this scan can take a long time. The
fwupd daemon could try to be smarter and only scan when eDP panels are
turned on, but we can also improve the behavior in the kernel.
Let's let eDP panels drivers specify that a panel is turned off and
then modify the common AUX transfer code not to attempt a transfer in
this case.
Maxime Ripard [Thu, 22 Feb 2024 18:13:50 +0000 (19:13 +0100)]
drm/tests: Add helper to create mock crtc
We're going to need a full-blown, functional, KMS device to test more
components of the atomic modesetting infrastructure.
Let's add a new helper to create a dumb, mocked, CRTC. By default it
will create a CRTC relying only on the default helpers, but drivers are
free to deviate from that.
Maxime Ripard [Thu, 22 Feb 2024 18:13:48 +0000 (19:13 +0100)]
drm/tests: helpers: Add atomic helpers
The mock device we were creating was missing any of the driver-wide
helpers. That was fine before since we weren't testing the atomic state
path, but we're going to start, so let's use the default
implementations.
Shradha Gupta [Fri, 2 Feb 2024 06:43:44 +0000 (22:43 -0800)]
drm: Check polling initialized before enabling in drm_helper_probe_single_connector_modes
In function drm_helper_probe_single_connector_modes() when we enable
polling again, if it is already uninitialized, a warning is reported.
This patch fixes the warning message by checking if poll is initialized
before enabling it.
Thierry Reding [Tue, 27 Feb 2024 11:20:38 +0000 (12:20 +0100)]
drm: Remove drm_num_crtcs() helper
The drm_num_crtcs() helper determines the number of CRTCs by iterating
over the list of CRTCs that have been registered with the mode config.
However, we already keep track of that number in the mode config's
num_crtcs field, so we can simply retrieve the value from that and
remove the extra helper function.
Dan Carpenter [Tue, 13 Feb 2024 18:05:01 +0000 (21:05 +0300)]
drm/imx/dcss: fix resource size calculation
The resource is inclusive of the ->start and ->end addresses so this
calculation is not correct. It should be "res->end - res->start + 1".
Use the resource_size() to do the calculation.
Dave Airlie [Wed, 28 Feb 2024 01:02:54 +0000 (11:02 +1000)]
Merge tag 'drm-intel-next-2024-02-27-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
drm/i915 feature pull #2 for v6.9:
Features and functionality:
- DP tunneling and bandwidth allocation support (Imre)
- Add more ADL-N PCI IDs (Gustavo)
- Enable fastboot also on older platforms (Ville)
- Bigjoiner force enable debugfs option for testing (Stan)
Refactoring and cleanups:
- Remove unused structs and struct members (Jiri Slaby)
- Use per-device debug logging (Ville)
- State check improvements (Ville)
- Hardcoded cd2x divider cleanups (Ville)
- CDCLK documentation updates (Ville, Rodrigo)
Fixes:
- HDCP MST Type1 fixes (Suraj)
- Fix MTL C20 PHY PLL values (Ravi)
- More hardware access prevention during init (Imre)
- Always enable decompression with tile4 on Xe2 (Juha-Pekka)
- Improve LNL package C residency (Suraj)
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]
drm/mediatek: Filter modes according to hardware capability
We found a stability issue on MT8188 when connecting an external monitor
in 2560x1440@144Hz mode. Checked with the designer, there is a function
called "prefetch" which is working during VBP (triggered by VSYNC).
If the duration of VBP is too short, the throughput requirement could
increase more than 3 times and lead to stability issues.
The mode settings that VDOSYS supports are mainly affected by clock
rate and throughput, display driver should filter these settings
according to the SoC's limitation to avoid unstable conditions.
Since currently the mode filter is only available on MT8195 and MT8188
and they share the same compatible name, the reference number (8250)
is hard coded instead of in the driver data.
Jocelyn Falempe [Thu, 8 Feb 2024 09:51:10 +0000 (10:51 +0100)]
drm/mgag200: Add a workaround for low-latency
We found a regression in v5.10 on real-time server, using the
rt-kernel and the mgag200 driver. It's some really specialized
workload, with <10us latency expectation on isolated core.
After the v5.10, the real time tasks missed their <10us latency
when something prints on the screen (fbcon or printk)
The regression has been bisected to 2 commits:
commit 0b34d58b6c32 ("drm/mgag200: Enable caching for SHMEM pages")
commit 4862ffaec523 ("drm/mgag200: Move vmap out of commit tail")
The first one changed the system memory framebuffer from Write-Combine
to the default caching.
Before the second commit, the mgag200 driver used to unmap the
framebuffer after each frame, which implicitly does a cache flush.
Both regressions are fixed by this commit, which restore WC mapping
for the framebuffer in system memory, and add a cache flush.
This is only needed on x86_64, for low-latency workload,
so the new kconfig DRM_MGAG200_IOBURST_WORKAROUND depends on
PREEMPT_RT and X86.
For more context, the whole thread can be found here [1]
Konrad Dybcio [Fri, 23 Feb 2024 21:21:41 +0000 (22:21 +0100)]
drm/msm/adreno: Add A702 support
The A702 is a weird mix of 600 and 700 series.. Perhaps even a
testing ground for some A7xx features with good ol' A6xx silicon.
It's basically A610 that's been beefed up with some new registers
and hw features (like APRIV!), that was then cut back in size,
memory bus and some other ways.
Add support for it, tested with QCM2290 / RB1.
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/579752/ Signed-off-by: Rob Clark <[email protected]>
Connor Abbott [Thu, 25 Jan 2024 13:10:57 +0000 (13:10 +0000)]
drm/msm: More fully implement devcoredump for a7xx
Use the vendor-provided snapshot headers to dump the contextless
registers, shader blocks, and cluster registers. Still unimplemented are
the GMU registers and "external core" registers, which would require
more work because they use register spaces we don't have described in
devicetree and dump registers from multiple spaces in a single list.
Signed-off-by: Connor Abbott <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/575919/ Signed-off-by: Rob Clark <[email protected]>
Connor Abbott [Thu, 25 Jan 2024 13:10:56 +0000 (13:10 +0000)]
drm/msm: Fix snapshotting a7xx indexed regs
We were overwriting the last indexed reg (CP_ROQ) and we were
snapshotting the same CP_MEMPOOL block twice instead of snapshotting
CP_BV_MEMPOOL as intended.
Signed-off-by: Connor Abbott <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/575920/ Signed-off-by: Rob Clark <[email protected]>
Connor Abbott [Thu, 25 Jan 2024 13:10:54 +0000 (13:10 +0000)]
drm/msm: Import a7xx crashdump register lists from kgsl
This imports these files as-is, the following commits will have to make
slight changes to get them to compile because downstream uses
un-namespaced enums that conflict with a6xx. However we should try as
much as possible to stick to downstream's format to make importing new
gens easier.
Signed-off-by: Connor Abbott <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/575921/ Signed-off-by: Rob Clark <[email protected]>
Neil Armstrong [Fri, 16 Feb 2024 11:03:50 +0000 (12:03 +0100)]
dt-bindings: arm-smmu: Document SM8650 GPU SMMU
Document the GPU SMMU found on the SM8650 platform.
Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/578685/ Signed-off-by: Rob Clark <[email protected]>
Neil Armstrong [Fri, 16 Feb 2024 11:03:49 +0000 (12:03 +0100)]
dt-bindings: arm-smmu: fix SM8[45]50 GPU SMMU if condition
The if condition for the SM8[45]50 GPU SMMU is too large,
add the other compatible strings to the condition to only
allow the clocks for the GPU SMMU nodes.
Fixes: 4fff78dc2490 ("dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU") Suggested-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/578686/ Signed-off-by: Rob Clark <[email protected]>
Luca Weiss [Sun, 21 Jan 2024 10:40:39 +0000 (11:40 +0100)]
drm/msm/adreno: Add A305B support
Add support for the Adreno 305B GPU that is found in MSM8226(v2) SoC.
Previously this was mistakenly claimed to be supported but using wrong
a configuration.
In MSM8226v1 there's also a A305B but with chipid 0x03000510 which
should work with the same configuration but due to lack of hardware for
testing this is not added.
Rob Clark [Wed, 17 Jan 2024 20:37:18 +0000 (12:37 -0800)]
drm/msm/adreno: Update generated headers
This updates the GPU headers to latest from mesa, using gen_header.py
(which is used to generate headers at bulid time for mesa), rather than
headergen2 (which doesn't have proper support for A6XX vs A7XX register
variants).
Mostly just uninteresting churn, but there are a couple spots in a7xx
paths which update REG_A6XX_foo to REG_A7XX_foo for registers which are
a7xx specific.
Danila Tikhonov [Sun, 18 Feb 2024 19:50:07 +0000 (22:50 +0300)]
drm/msm/adreno: Add support for SM7150 SoC machine
SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
to zero decimal places.
Also a618 on SM7150 uses a615 zapfw. Add a squashed version (.mbn).
Add this as machine = "qcom,sm7150", because speed-bin values are
different from atoll (sc7180/sm7125).
Dmitry Baryshkov [Tue, 20 Feb 2024 17:12:10 +0000 (19:12 +0200)]
drm/msm/a6xx: specify UBWC config for sc7180
Historically the Adreno driver has not been updating memory
configuration registers on a618 (SC7180 platform) implying that the
default configuration is fine. After the rework performed in the commit 8814455a0e54 ("drm/msm: Refactor UBWC config setting") the function
a6xx_calc_ubwc_config() still contained this shortcut and did not
calculate UBWC configuration. However the function which now actually
updates hardware registers, a6xx_set_ubwc_config(), doesn't contain such
check.
Rather than adding the check to a6xx_set_ubwc_config(), fill in the
UBWC config for a618 (based on readings from SC7180).
Maxime Ripard [Wed, 21 Feb 2024 09:26:36 +0000 (10:26 +0100)]
drm/edid/firmware: Remove built-in EDIDs
The EDID firmware loading mechanism introduced a few built-in EDIDs that
could be forced on any connector, bypassing the EDIDs it exposes.
While convenient, this limited set of EDIDs doesn't take into account
the connector type, and we can end up with an EDID that is completely
invalid for a given connector.
For example, the edid/800x600.bin file matches the following EDID:
Block 0, Base EDID:
EDID Structure Version & Revision: 1.3
Vendor & Product Identification:
Manufacturer: LNX
Model: 0
Made in: week 5 of 2012
Basic Display Parameters & Features:
Analog display
Signal Level Standard: 0.700 : 0.000 : 0.700 V p-p
Blank level equals black level
Sync: Separate Composite Serration
Maximum image size: 27 cm x 20 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
RGB color display
First detailed timing is the preferred timing
Color Characteristics:
Red : 0.6416, 0.3486
Green: 0.2919, 0.5957
Blue : 0.1474, 0.1250
White: 0.3125, 0.3281
Established Timings I & II:
DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz
Standard Timings:
DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz
Detailed Timing Descriptors:
DTD 1: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz (277 mm x 208 mm)
Hfront 40 Hsync 128 Hback 88 Hpol P
Vfront 1 Vsync 4 Vback 23 Vpol P
Display Product Serial Number: 'Linux #0'
Display Range Limits:
Monitor ranges (GTF): 59-61 Hz V, 36-38 kHz H, max dotclock 50 MHz
Display Product Name: 'Linux SVGA'
Checksum: 0xc2
So, an analog monitor EDID. However, if the connector was an HDMI
monitor for example, it breaks the HDMI specification that requires,
among other things, a digital display, the VIC 1 mode and an HDMI Forum
Vendor Specific Data Block in an CTA-861 extension.
We thus end up with a completely invalid EDID, which thus might confuse
HDMI-related code that could parse it.
After some discussions on IRC, we identified mainly two ways to fix
this:
- We can either create more EDIDs for each connector type to provide
a built-in EDID that matches the resolution passed in the name, and
still be a sensible EDID for that connector type;
- Or we can just prevent the EDID to be exposed to userspace if it's
built-in.
Or possibly both.
However, the conclusion was that maybe we just don't need the built-in
EDIDs at all and we should just get rid of them. So here we are.
Daniel Vetter [Mon, 26 Feb 2024 10:41:07 +0000 (11:41 +0100)]
Merge v6.8-rc6 into drm-next
Thomas Zimmermann asked to backmerge -rc6 for drm-misc branches,
there's a few same-area-changed conflicts (xe and amdgpu mostly) that
are getting a bit too annoying.
Daniel Vetter [Mon, 26 Feb 2024 10:06:19 +0000 (11:06 +0100)]
Merge tag 'drm-habanalabs-next-2024-02-26' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next
This tag contains habanalabs driver and accel changes for v6.9.
The notable changes are:
- New features and improvements:
- Configure interrupt affinity according to NUMA nodes for the MSI-X interrupts that are
assigned to the userspace application which acquires the device.
- Move the HBM MMU page tables to reside inside the HBM to minimize latency when doing
page-walks.
- Improve the device reset mechanism when consecutive heartbeat failures occur (firmware
fails to ack on heartbeat message).
- Check also extended errors in the PCIe addr_dec interrupt information.
- Rate limit the error messages that can be printed to dmesg log by userspace actions.
- Firmware related fixes:
- Handle requests from firmware to reserve device memory
- Bug fixes and code cleanups:
- constify the struct device_type usage in accel (accel_sysfs_device_minor).
- Fix the PCI health check by reading uncached register.
- Fix reporting of drain events.
- Fix debugfs files permissions.
- Fix calculation of DRAM BAR base address.
Daniel Vetter [Mon, 26 Feb 2024 09:49:09 +0000 (10:49 +0100)]
Merge tag 'drm-xe-next-2024-02-25' of ssh://gitlab.freedesktop.org/drm/xe/kernel into drm-next
drm/xe feature pull for v6.9:
UAPI Changes:
- New query to the GuC firmware submission version. (José Roberto de Souza)
- Remove unused persistent exec_queues (Thomas Hellström)
- Add vram frequency sysfs attributes (Sujaritha Sundaresan, Rodrigo Vivi)
- Add the flag XE_VM_BIND_FLAG_DUMPABLE to notify devcoredump that mapping
should be dumped (Maarten Lankhorst)
Cross-drivers Changes:
- Make sure intel_wakeref_t is treated as opaque type on i915-display
and fix its type on xe
Driver Changes:
- Drop pre-production workarounds (Matt Roper)
- Drop kunit tests for unsuported platforms: PVC and pre-production DG2 (Lucas De Marchi)
- Start pumbling SR-IOV support with memory based interrupts
for VF (Michal Wajdeczko)
- Allow to map BO in GGTT with PAT index corresponding to
XE_CACHE_UC to work with memory based interrupts (Michal Wajdeczko)
- Improve logging with GT-oriented drm_printers (Michal Wajdeczko)
- Add GuC Doorbells Manager as prep work SR-IOV during
VF provisioning ((Michal Wajdeczko)
- Refactor fake device handling in kunit integration ((Michal Wajdeczko)
- Implement additional workarounds for xe2 and MTL (Tejas Upadhyay,
Lucas De Marchi, Shekhar Chauhan, Karthik Poosa)
- Program a few registers according to perfomance guide spec for Xe2 (Shekhar Chauhan)
- Add error handling for non-blocking communication with GuC (Daniele Ceraolo Spurio)
- Fix remaining 32b build issues and enable it back (Lucas De Marchi)
- Fix build with CONFIG_DEBUG_FS=n (Jani Nikula)
- Fix warnings from GuC ABI headers (Matthew Brost)
- Introduce Relay Communication for SR-IOV for VF <-> GuC <-> PF (Michal Wajdeczko)
- Add mocs reset kunit (Ruthuvikas Ravikumar)
- Fix spellings (Colin Ian King)
- Disable mid-thread preemption when not properly supported by hardware (Nirmoy Das)
- Release mmap mappings on rpm suspend (Badal Nilawar)
- Fix BUG_ON on xe_exec by moving fence reservation to the validate stage (Matthew Auld)
- Fix xe_exec by reserving extra fence slot for CPU bind (Matthew Brost)
- Fix xe_exec with full long running exec queue, now returning
-EWOULDBLOCK to userspace (Matthew Brost)
- Fix CT irq handler when CT is disabled (Matthew Brost)
- Fix VM_BIND_OP_UNMAP_ALL without any bound vmas (Thomas Hellström)
- Fix missing __iomem annotations (Thomas Hellström)
- Fix exec queue priority handling with GuC (Brian Welty)
- Fix setting SLPC flag to GuC when it's not supported (Vinay Belgaumkar)
- Fix C6 disabling without SLPC (Matt Roper)
- Drop -Wstringop-overflow to fix build with GCC11 (Paul E. McKenney)
- Circumvent bogus -Wstringop-overflow in one case (Arnd Bergmann)
- Refactor exec_queue user extensions handling and fix USM attributes
being applied too late (Brian Welty)
- Use circ_buf head/tail convention (Matthew Brost)
- Fail build if circ_buf-related defines are modified with incompatible values
(Matthew Brost)
- Fix several error paths (Dan Carpenter)
- Fix CCS copy for small VRAM copy chunks (Thomas Hellström)
- Rework driver initialization order and paths to account for driver running
in VF mode (Michal Wajdeczko)
- Initialize GuC earlier during probe to handle driver in VF mode (Michał Winiarski)
- Fix migration use of MI_STORE_DATA_IMM to write PTEs (Matt Roper)
- Fix bounds checking in __xe_bo_placement_for_flags (Brian Welty)
- Drop display dependency on CONFIG_EXPERT (Jani Nikula)
- Do not hand-roll kstrdup when creating snapshot (Michal Wajdeczko)
- Stop creating one kunit module per kunit suite (Lucas De Marchi)
- Reduce scope and constify variables (Thomas Hellström, Jani Nikula, Michal Wajdeczko)
- Improve and document xe_guc_ct_send_recv() (Michal Wajdeczko)
- Add proxy communication between CSME and GSC uC (Daniele Ceraolo Spurio)
- Fix size calculation when writing pgtable (Fei Yang)
- Make sure cfb is page size aligned in stolen memory (Vinod Govindapillai)
- Stop printing guc log to dmesg when waiting for GuC fails (Rodrigo Vivi)
- Use XE_CACHE_WB instead of XE_CACHE_NONE for cpu coherency on migration
(Himal Prasad Ghimiray)
- Fix error path in xe_vm_create (Moti Haimovski)
- Fix warnings in doc generation (Thomas Hellström, Badal Nilawar)
- Improve devcoredump content for mesa debugging (José Roberto de Souza)
- Fix crash in trace_dma_fence_init() (José Roberto de Souza)
- Improve CT state change handling (Matthew Brost)
- Toggle USM support for Xe2 (Lucas De Marchi)
- Reduces code duplication to emit PIPE_CONTROL (José Roberto de Souza)
- Canonicalize addresses where needed for Xe2 and add to devcoredump
(José Roberto de Souza)
- Only allow 1 ufence per exec / bind IOCTL (Matthew Brost)
- Move all display code to display/ (Jani Nikula)
- Fix sparse warnings by correctly using annotations (Thomas Hellström)
- Warn on job timeouts instead of using asserts (Matt Roper)
- Prefix macros to avoid clashes with sparc (Matthew Brost)
- Fix -Walloc-size by subclassing instead of allocating size smaller than struct (Thomas Hellström)
- Add status check during gsc header readout (Suraj Kandpal)
- Fix infinite loop in vm_bind_ioctl_ops_unwind() (Matthew Brost)
- Fix fence refcounting (Matthew Brost)
- Fix picking incorrect userptr VMA (Matthew Brost)
- Fix USM on integrated by mapping both mem.kernel_bb_pool and usm.bb_pool (Matthew Brost)
- Fix double initialization of display power domains (Xiaoming Wang)
- Check expected uC versions by major.minor.patch instead of just major.minor (John Harrison)
- Bump minimum GuC version to 70.19.2 for all platforms under force-probe
(John Harrison)
- Add GuC firmware loading for Lunar Lake (John Harrison)
- Use kzalloc() instead of hand-rolled alloc + memset (Nirmoy Das)
- Fix max page size of VMA during a REMAP (Matthew Brost)
- Don't ignore error when pinning pages in kthread (Matthew Auld)
- Refactor xe hwmon (Karthik Poosa)
- Add debug logs for D3cold (Riana Tauro)
- Remove broken TEST_VM_ASYNC_OPS_ERROR (Matthew Brost)
- Always allow to override firmware blob with module param and improve
log when no firmware is found (Lucas De Marchi)
- Fix shift-out-of-bounds due to xe_vm_prepare_vma() accepting zero fences (Thomas Hellström)
- Fix shift-out-of-bounds by distinguishing xe_pt/xe_pt_dir subclass (Thomas Hellström)
- Fail driver bind if platform supports MSIX, but fails to allocate all of them (Dani Liberman)
- Fix intel_fbdev thinking memory is backed by shmem (Matthew Auld)
- Prefer drm_dbg() over dev_dbg() (Jani Nikula)
- Avoid function cast warnings with clang-16 (Arnd Bergmann)
- Enhance xe_bo_move trace (Priyanka Dandamudi)
- Fix xe_vma_set_pte_size() not setting the right gpuva.flags for 4K size (Matthew Brost)
- Add XE_VMA_PTE_64K VMA flag (Matthew Brost)
- Return 2MB page size for compact 64k PTEs (Matthew Brost)
- Remove usage of the deprecated ida_simple_xx() API (Christophe JAILLET)
- Fix modpost warning on xe_mocs live kunit module (Ashutosh Dixit)
- Drop extra newline in from sysfs files (Ashutosh Dixit)
- Implement VM snapshot support for BO's and userptr (Maarten Lankhorst)
- Add debug logs when skipping rebinds (Matthew Brost)
- Fix code generation when mixing build directories (Dafna Hirschfeld)
- Prefer struct_size over open coded arithmetic (Erick Archer)
Maxime Ripard [Thu, 22 Feb 2024 18:14:21 +0000 (19:14 +0100)]
drm/sun4i: hdmi: Consolidate atomic_check and mode_valid
atomic_check and mode_valid do not check for the same things which can
lead to surprising result if the userspace commits a mode that didn't go
through mode_valid. Let's merge the two implementations into a function
called by both.
Tomi Valkeinen [Tue, 13 Feb 2024 08:16:37 +0000 (10:16 +0200)]
drm/tidss: Fix sync-lost issue with two displays
A sync lost issue can be observed with two displays, when moving a plane
from one disabled display to an another disabled display, and then
enabling the display to which the plane was moved to. The exact
requirements for this to trigger are not clear.
It looks like the issue is that the layers are left enabled in the first
display's OVR registers. Even if the corresponding VP is disabled, it
still causes an issue, as if the disabled VP and its OVR would still be
in use, leading to the same VID being used by two OVRs. However, this is
just speculation based on testing the DSS behavior.
Experimentation shows that as a workaround, we can disable all the
layers in the OVR when disabling a VP. There should be no downside to
this, as the OVR is anyway effectively disabled if its VP is disabled,
and it seems to solve the sync lost issue.
However, there may be a bigger issue in play here, related to J721e
erratum i2097 ("DSS: Disabling a Layer Connected to Overlay May Result
in Synclost During the Next Frame"). Experimentation also shows that the
OVR's CHANNELIN field has similar issue. So we may need to revisit this
when we find out more about the core issue.
Tomi Valkeinen [Tue, 13 Feb 2024 08:16:36 +0000 (10:16 +0200)]
drm/tidss: Fix initial plane zpos values
When the driver sets up the zpos property it sets the default zpos value
to the HW id of the plane. That is fine as such, but as on many DSS
versions the driver arranges the DRM planes in a different order than
the HW planes (to keep the non-scalable planes first), this leads to odd
initial zpos values. An example is J721e, where the initial zpos values
for DRM planes are 1, 3, 0, 2.
In theory the userspace should configure the zpos values properly when
using multiple planes, and in that sense the initial zpos values
shouldn't matter, but there's really no reason not to fix this and help
the userspace apps which don't handle zpos perfectly. In particular,
some versions of Weston seem to have issues dealing with the planes
with the current default zpos values.
So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
Another option would be to configure the planes marked as primary planes
to zpos 0. On a two display system this would give us plane zpos values
of 0, 0, 1, 2. The end result and behavior would be very similar in this
option, and I'm not aware that this would actually help us in any way.
So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
Since commit aed65af1cc2f ("drivers: make device_type const"), the driver
core can properly handle constant struct device_type. Move the
accel_sysfs_device_minor variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Ofir Bitton [Mon, 12 Feb 2024 12:35:24 +0000 (14:35 +0200)]
accel/habanalabs: modify pci health check
Today we read PCI VENDOR-ID in order to make sure PCI link is
healthy. Apparently the VENDOR-ID might be stored on host and
hence, when we read it we might not access the PCI bus.
In order to make sure PCI health check is reliable, we will start
checking the DEVICE-ID instead.
Tomer Tayar [Tue, 30 Jan 2024 07:57:32 +0000 (09:57 +0200)]
accel/habanalabs: keep explicit size of reserved memory for FW
The reserved memory for FW is currently saved in an ASIC property in
units of MB, just like the value that comes from FW.
Except the fact that it is not clear from the property's name, it means
also that a calculation to actual size is required everywhere that it is
used.
Modify the property to hold the size in bytes.
Tomer Tayar [Mon, 29 Jan 2024 15:26:17 +0000 (17:26 +0200)]
accel/habanalabs: handle reserved memory request when working with full FW
Currently the reserved memory request from FW is handled when running
with preboot only, but this request is relevant also when running with
full FW.
Modify to always handle this reservation request.
projects / linux.git / log