HMM provides new APIs and helps in kernel 5.2-rc1 to simplify driver
path. The old hmm APIs are deprecated and will be removed in future.
Below are changes in driver:
1. Change hmm_vma_fault to hmm_range_register and hmm_range_fault which
supports range with multiple vmas, remove the multiple vmas handle path
and data structure.
2. Change hmm_vma_range_done to hmm_range_unregister.
3. Use default flags to avoid pre-fill pfn arrays.
4. Use new hmm_device_ helpers.
Signed-off-by: Philip Yang <[email protected]>
Reviewed-by: Felix Kuehling <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
The "block" variable can be set by the user through debugfs, so it can
be quite large which leads to shift wrapping here. This means we report
a "block" as supported when it's not, and that leads to array overflows
later on.
This bug is not really a security issue in real life, because debugfs is
generally root only.
Fixes: 36ea1bd2d0 ("drm/amdgpu: add debugfs ctrl node")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
We have the rest of the support in the kerne, but we don't actually boot KFD
on the device without this change
Signed-off-by: Kent Russell <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
For SR-IOV VF, powerplay may not be supported, in this case,
error '-EINVAL' should not be returned.
Signed-off-by: Trigger Huang <[email protected]>
Reviewed-by: Prike Liang <[email protected]>
Reviewed-by: Huang Rui <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Found issue in EDID Emulation where if we connect a display using
a passive HDMI-DP dongle, disconnect it and then try to emulate
a display using DP, we could not see 4K modes. This was because
on a disconnect, dongle_max_pix_clk was still set so when we
emulate using DP, in dc_link_validate_mode_timing(), it would
think we were still using a dongle and limit the modes we support.
[How]
In dc_link_detect(), set dongle_max_pix_clk to 0 when we detect
a hotplug out ( if new_connection_type = dc_connection_none ).
Signed-off-by: Samson Tam <[email protected]>
Reviewed-by: Jun Lei <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
refactor a code so we will call clk_mgr's enable_pme_wa function so we
can use pme_wa for future asics. This way we don't need to worry about
different ASIC since clk_mgr already have that information
Signed-off-by: Su Sung Chung <[email protected]>
Reviewed-by: Eric Yang <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Description]
The spec does not allow POST_LT_ADJ_GRANTED to be set when TPS4 is used.
Signed-off-by: abdoulaye berthe <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
We incorrectly began powering down the display at boot/resume whenever
fast boot was not possible. This should not be done in the case where there
exists a stream for the eDP since this implies that we want to turn it on.
[How]
Add check for eDP stream to decide whether to power off edp.
Signed-off-by: SivapiriyanKumarasamy <[email protected]>
Reviewed-by: Anthony Koo <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Acked-by: Reza Amini <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[WHY]
By the time output csc matrix is being programmed, stream connection to
OPP has been established, but this information has not been relayed back
to HUBP.
Signed-off-by: Wesley Chalmers <[email protected]>
Reviewed-by: Anthony Koo <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Acked-by: Krunoslav Kovac <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Our existing logic in deciding whether to use RAM or ROM
depends on whether we are dealing with an identity gamma ramp.
[How]
In addition to the is_identity flag
a new is_logical_identity flag has been
added. The is_identity flag now denotes
whether the OS gamma is an RGB256 identity
and the new logical identity will inidicate
that the given gamma ramp regardless of its
type is identity.
Signed-off-by: Harmanprit Tatla <[email protected]>
Reviewed-by: Krunoslav Kovac <[email protected]>
Acked-by: Anthony Koo <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
For debugging underflow issues it can be useful to have asserts when the
underflow initially occurs.
[How]
Read the underflow status registers after actions that have a high risk
of causing underflow and assert that no underflow occurred. If underflow
occurred, clear the bit.
Signed-off-by: Thomas Lim <[email protected]>
Reviewed-by: Eric Yang <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Currently vmid is decided internally inside dc. This makes it
difficult to use vmid use with external components.
This change moves vmid logic outside dc and allowing vmid to be
passed in as a parameter to DC.
Signed-off-by: Dmytro Laktyushkin <[email protected]>
Reviewed-by: Charlene Liu <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
VBios sometimes reports incorrect object type as encoder instead of
connector
[How]
Change error message to debug message
Signed-off-by: Jordan Lazare <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Using this logic breaks driver unload, this is a temporary fix
a followup patch will properly fix this
Signed-off-by: Krunoslav Kovac <[email protected]>
Reviewed-by: Aric Cyr <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
HPD not going to be high if Panel VDD is off
And all AUX transaction will fail :(
[How]
1. Power on VDD before attempting detection if it isn't already on
2. Improve the robustness by having a retry mechanism on the
first DPCD read after VDD on. If a particular board always holds
HPD high incorrectly, the AUX access may fail, so we can retry
in those scenarios. This change would only improve logic
since it prevents AUX failure leading to bad resolution on internal
panel.
3. We should never need to re-detect internal panel, so logic
is re-arranged a bit to skip earlier.
Signed-off-by: Anthony Koo <[email protected]>
Reviewed-by: Jun Lei <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
To prepare for the upcoming DRM plane color management properties
we need to correct a lot of wrong behavior and assumptions made for
CRTC color management.
The documentation added by this commit in amdgpu_dm_color explains
how the HW color pipeline works and its limitations with the DRM
interface.
The current implementation does the following wrong:
- Implicit sRGB DGM when no CRTC DGM is set
- Implicit sRGB RGM when no CRTC RGM is set
- No way to specify a non-linear DGM matrix that produces correct output
- No way to specify a correct RGM when a linear DGM is used
We had workarounds for passing kms_color tests but not all of the
behavior we had wrong was covered by these tests (especially when
it comes to non-linear DGM). Testing both DGM and RGM at the same time
isn't something kms_color tests well either.
[How]
The specifics for how color management works in AMDGPU and the new
behavior can be found by reading the documentation added to
amdgpu_dm_color.c from this patch.
All of the incorrect cases from the old implementation have been
addressed for the atomic interface, but there still a few TODOs for
the legacy one.
Note: this does cause regressions for kms_color@pipe-a-ctm-* over HDMI.
The result looks correct from visual inspection but the CRC no longer
matches. For reference, the test was previously doing the following:
linear degamma -> CTM -> sRGB regamma -> RGB to YUV (709) -> ...
Now the test is doing:
linear degamma -> CTM -> linear regamma -> RGB to YUV (709) -> ...
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: Sun peng Li <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[WHY]
This is meant to make it clearer that 0xf is not a valid OPP ID, and
that code making use of OPP IDs should not accept this value.
Signed-off-by: Wesley Chalmers <[email protected]>
Reviewed-by: Charlene Liu <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
1. Add i2c_hw_Status check to make sure when HW i2c is in use.
2. Don't reset HW engine in is_hw_busy() and instead do this in
process_transaction() because SW i2c does not check if hw i2c is in use
Signed-off-by: Derek Lai <[email protected]>
Reviewed-by: Charlene Liu <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Almost every function in DC that works with stream state expects that
the current state on the stream is the one that it should be writing
out. These functions are typically triggered by specifying a particular
stream update - but the actual contents of the stream update itself
are ignored, leaving it to the DM to actually update the stream state
itself.
The problem with doing this in DM is a matter of timing. On Linux
most of this is incorrectly done in atomic check, when we actually want
it to be done during atomic commit tail while access to DC is locked.
To give an example, a commit requesting to modify color management
state for DM could come in, be rejected, but still have modified
the actual system state for the stream since it's shared memory. The
next time color management gets programmed it'll use the rejected
color management info - which might not even still be around if it's
a custom transfer function.
So a reasonable place to perform this is within DC itself and this is
the model that's currently in use for surface updates. DC can even
compare the current system state to the incoming surface update to
determine update level, something that can't currnetly be done with the
framework for stream updates.
[How]
Duplicate the framework used for surface updates for stream updates
as well. Copy all the updates after checking the update type.
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[WHY]
Some panels return a link rate of 0 (unknown) in DPCD 0. In this case,
an appropriate mode cannot be set, and certain panels will show
corruption as they are forced to use a mode they do not support.
[HOW]
Read DPCD 10 in the case where supported link rate from DPCD 0 is
unknown, and pass that value on to the reported link rate.
This re-introduces behaviour present in previous versions that appears
to have been accidentally removed.
Signed-off-by: Wesley Chalmers <[email protected]>
Reviewed-by: Anthony Koo <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
The module parameter to specify the default ABM level is now defined,
so hook it up in DM.
[How]
On connector reset specify the default level. DC will program this as
part of the modeset since it gets passed onto the stream in
dm_update_crtc_state.
It's only set for eDP connectors, but it doesn't matter if this is
specified for connectors or hardware that doesn't support ABM.
It's DC's responsibility to check that ABM can be set or adjusted, and
DC does check that the DMCU firmware is running and if there's backlight
control available.
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: David Francis <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
It's non trivial to configure or specify an ABM reduction level for
userspace outside of X. There is also no method to specify the default
ABM value at boot time.
A parameter should be added to configure this.
[How]
Expose a module parameter that can specify the default ABM level to
use for eDP connectors on DC enabled hardware that loads the DMCU
firmware.
The default is still disabled (0), but levels can range from 1-4. Levels
control how much the backlight can be reduced, with being the least
amount of reduction and four being the most reduction.
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: David Francis <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
It's incorrect to do soft reset for SRIOV, when GFX
hang the WREG would stuck there becuase it goes KIQ way.
the GPU reset counter is incorrect: always increase twice
for each timedout
Signed-off-by: Monk Liu <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Since Hardware bug, GDS exist ECC error after cold boot up,
adding GDS clearing workaround in later init for gfx9.
Signed-off-by: James Zhu <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Whenever the a modeset is allowed (but not neccessarily required) we
currently recreate all the planes in the state. Most IGT tests and
legacy IOCTLs create atomic commits with this flag set, so the pipes
are often unnecessarily reprogrammed.
Poor performance and stuttering can occur when many of these commits
are frequently issued.
This flag was needed when the appropriate conditions for checking
whether the planes needed a reset were not in place, but
should_reset_plane should cover everything needed now.
[How]
Drop the check for state->allow_modeset in should_reset_plane.
All planes on a CRTC should reset in the following conditions:
- The CRTC needs a modeset
- The CRTC degamma changes
- Planes are added or removed to the CRTC
These conditions are all covered in should_reset_plane.
We still can't drop the format change check in should_reset_plane since
fill_dc_plane_info_and_addr isn't called when validating the state, so
we can't tell if a FULL update is needed or not.
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: David Francis <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
The old logic for checking which output depth to use relied on using
the current connector state rather than the new proposed state. This
was a problem when performing atomic commits since we weren't verifying
it against the incoming max_requested_bpc.
But switching this to only use the new state and not the current state
breaks filtering modes - it'll always assume that the maximum bpc
supported by the display is in use, which will cause certain modes
like 1440p@144Hz to be filtered even when using 8bpc.
[How]
Still use the connector->state if we aren't passed an explicit state.
This will respect the max_bpc the user currently has when filtering
modes.
Also remember to reset the default max_requested_bpc to 8 whenever
connector reset is called to retain old behavior when using the new
property.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110845
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
This option is no longer needed. The default code paths
are now the only option.
v2: Add HPAGE support and a default for non contiguous maps
v3: Misread 512 pages as MiB ...
Signed-off-by: Tom St Denis <[email protected]>
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Unlike our regular connectors, MST connectors don't start off with
an initial connector state. This causes a NULL pointer dereference to
occur when attaching the bpc property since it tries to modify the
connector state.
We need an initial connector state on the connector to avoid the crash.
[How]
Use our reset helper to allocate an initial state and reset the values
to their defaults. We were already doing this before, just not for
MST connectors.
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: Leo Li <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
This will be useful for verifying whether we enter the correct output
color depth from IGT.
[How]
Locks the connector and associated CRTC if available and outputs
the current and maximum output bpc values.
Example:
cat /sys/kernel/debug/dri/0/DP-1/output_bpc
Current: 8
Maximum: 10
v2: Drop unneeded connector status check
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: David Francis <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Under Vega10 SR-IOV VF, L1 register access mode should be enabled by
default as the non-security VF will no longer be supported.
Signed-off-by: Trigger Huang <[email protected]>
Reviewed-by: Emily Deng <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[What]
readptr read always returns zero, since most likely
these blocks are either power or clock gated.
[How]
fetch rptr after amdgpu_ring_alloc() which informs
the power management code that the block is about to be
used and hence the gating is turned off.
Signed-off-by: Louis Li <[email protected]>
Signed-off-by: Shirish S <[email protected]>
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[What]
vce ring test fails consistently during resume in s3 cycle, due to
mismatch read & write pointers.
On debug/analysis its found that rptr to be compared is not being
correctly updated/read, which leads to this failure.
Below is the failure signature:
[drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed
[drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110
[drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110).
[How]
fetch rptr appropriately, meaning move its read location further down
in the code flow.
With this patch applied the s3 failure is no more seen for >5k s3 cycles,
which otherwise is pretty consistent.
V2: remove reduntant fetch of rptr
Signed-off-by: Louis Li <[email protected]>
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Translate queue priority into pipe priority and write to MQDs.
The priority values are used to perform queue and pipe arbitration.
Signed-off-by: Oak Zeng <[email protected]>
Reviewed-by: Felix Kuehling <[email protected]>
Signed-off-by: Felix Kuehling <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Always mark evicted queues with q->properties.is_evicted = true, even
queues that are inactive for other reason. This simplifies maintaining
the eviction state as it doesn't require updating is_evicted when other
queue activation conditions change.
On the other hand, we now need to check those other queue activation
conditions whenever an evicted queues is restored. To minimize code
duplication, move the queue activation check into a macro so it can be
maintained in one central place.
Signed-off-by: Felix Kuehling <[email protected]>
Reviewed-by: Philip Cox <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
EDC counts are related to instance and se. They are not the same
for different type of EDC. EDC clearing are changed to base on
individual EDC's instance and SE number.
Signed-off-by: James Zhu <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
DCN_VERSION_1_01 is no longer handled in the dal_hw_translate_init
switch since it was inadvertently dropped in the patch that removed the
unnecessary DCN1_01 guards.
This caused numerous regressions on DCN1_01 when loading the driver.
[How]
Add it back.
Fixes: 97df424fe7 ("drm/amd/display: Drop DCN1_01 guards")
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
When switching from vt to desktop with EDID emulation we can receive
an atomic commit such that we have a crtc where mode_changed = true.
During the dm_update_crtc_state disable pass we remove the stream from
the context and free it on the dm_new_crtc_state.
During the enable pass we compare the new provisional stream to the
dm_old_crtc_state->stream and determine that the stream is unchanged
and no scaling has been changed.
Following this, new_crtc_state->mode_changed is then set to false.
The connectors haven't changed and the CRTC active state hasn't changed
so drm_atomic_crtc_needs_modeset returns false, so we jump to
skip_modeset and we hit:
BUG_ON(dm_new_crtc_state->stream == NULL);
...since the old stream is gone from the context and the new stream is
also still NULL.
[How]
Ensure that we still a stream to reuse before checking if we can reuse
the old stream without a full modeset.
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Chunming Zhou <[email protected]>
Tested-by: Pierre-Eric Pelloux-Prayer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
