[WHY]
Some early Raven boards had a bad SBIOS that doesn't play nicely with
the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU
load but that doesn't seem to be the case. We've still seen reports of
users unable to boot their systems at all.
[HOW]
Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso.
v2: Fix ifdef (Alex)
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
[WHY]
Some early Raven boards had a bad SBIOS that doesn't play nicely with
the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU
load but that doesn't seem to be the case. We've still seen reports of
users unable to boot their systems at all.
[HOW]
Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
[WHY]
The resource constructor currently needs num_virtual_links from
init_data but will need access to other items provided by DM.
[HOW]
Pass init_data into DCN create_resource_pool functions.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Acked-by: Hersen Wu <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Powerplay functions called from dm_pp_* functions tend to do a
mutex_lock which isn't safe to do inside a kernel_fpu_begin/end block as
those will disable/enable preemption.
Rearrange the dm_pp_get_clock_levels_by_type_with_voltage calls to make
sure they happen outside of kernel_fpu_begin/end.
Cc: [email protected]
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
In certain configurations, such as PX configs or some Vega20 parts
DC gets created without connectors.
[How]
Drop the dm_error print when no connectors.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Acked-by: Leo Li <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
drm_plane_cleanup does not free the plane.
[How]
Call drm_primary_helper_destroy which will also free the plane.
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
drm_plane_cleanup does not free the plane.
[How]
Call drm_primary_helper_destroy which will also free the plane.
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
This was missed when pushing public patch for 3e3a40b03847 (drm/amd/display:
Updated HDR Static Metadata to directly take info packet raw)
This is currently no problem yet since we're not doing HDR on Linux yet.
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Add code to tear down freesync modules when disabled.
Signed-off-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
VGA sometimes has trouble retrieving the EDID on very long cables, KVM
switches, or old displays.
[How]
Only require EDID read for HDMI and DVI and exempt other types (DP,
VGA). We currently don't support VGA but if anyone adds support in the
future this might get overlooked.
Signed-off-by: Harry Wentland <[email protected]>
Suggested-by: Michel Dänzer <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Some boards seem to have a problem where HPD is high on HDMI even though
no display is connected. We don't want to report these as connected. DP
spec still requires us to report DP displays as connected when HPD is
high but we can't read the EDID in order to go to fail-safe mode.
[How]
If connector_signal is not DP abort detection if we can't retrieve the
EDID.
v2: Add Bugzilla and stable
Bugzilla: https://bugs.freedesktop.org/107390
Bugzilla: https://bugs.freedesktop.org/106846
Cc: [email protected]
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Any Linux kernel code should pass checkpatch.pl with no errors and
little, if any, warning.
[How]
Fixing some spacing errors and warnings.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Leo Li <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Currently we still go through DC code that does error checking, retries,
etc. There's no need for that since DRM already does that for us. This
simplifies the code a bit and makes it easier to debug.
This also ensures we correctly tell DRM how many bytes have actually
been read, as we should. This allows DRM to correctly read the EDID on
the Chamelium DP port.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
DRM's DP helpers take care of dealing with the error code for us. In
order not to step on each other's toes we'll need to be able to simply
read auch channel replies without further logic based on return values.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Sun peng Li <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Access to GPIO needs to be serialized. Aux transactions are already
serialized in DRM but we also need to serialize access to the GPIO pin
for purposes of DP dongle detection.
Call is_dp_sink_present through DM so we can lock correctly. This
follows the same pattern used for DPCD transactions.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Jun Lei <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
This reverts commit cc19514113.
This commit was problematic on other OSes. The real solution is to
leave all the error checking to DRM and don't do it in DC, which is
addressed by "Return aux replies directly to DRM" later in this patchset.
v2: Add reason for revert.
Signed-off-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
This reverts commit 8a61bc085f.
Need to revert "make dm_dp_aux_transfer return payload bytes instead of
size", which this commit is based on. That commit was problematic on
other OSes. The real solution is to leave all the error checking to DRM
and don't do it in DC, which is addressed by "Return aux replies
directly to DRM" later in this patchset.
v2: Add reason for revert.
Signed-off-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
The driver is expecting clock frequency in kHz, while SMU returns
the values in 10kHz, which causes the bandwidth validation to fail
4.18 has the faulty clock assignment in pp_to_dc_clock_levels_with_latency
only, which is only used by Vega. Make sure we multiply these values
by 10 here, as we do for other ASICs as powerplay assigned them
wrong. 4.19 has the proper fix in powerplay.
v2: Add Fixes tag
v3: Fixes -> Bugzilla, with simplified link
Bugzilla: https://bugs.freedesktop.org/107082
Signed-off-by: Mikita Lipski <[email protected]>
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
The previous change wasn't covering smu 7 and 8 and therefore DC was
seeing wrong clock values.
This fixes an issue where the pipes seem to hang with a 4k DP and 1080p
HDMI display.
Fixes: c3df50abc84b ("drm/amd/pp: Convert clock unit to KHz as defined")
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Cc:[email protected]
Signed-off-by: Alex Deucher <[email protected]>
const to avoid hard-to-find bugs where some function overrides a
function pointer.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
We've had a number of users report failures to detect and light up
display with DC with LVDS and VGA. These connector types are not
currently supported with DC. I'd like to add support but unfortunately
don't have a system with LVDS or VGA available.
In order not to cause regressions we should probably fallback to the
non-DC driver for ASICs that support VGA and LVDS.
These ASICs are:
* Bonaire
* Kabini
* Kaveri
* Mullins
ASIC support can always be force enabled with amdgpu.dc=1
v2: Keep Hawaii on DC
v3: Added Mullins to the list
Cc: [email protected]
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
We'd like to use some of them in dc_link_ddc and amdgpu_dm and should
have them available in dc_ddc_types.h.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
DC has an upcoming change that requires these to read the board layout.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Also drop wrong 10kHz comment
Fixes: drm/amd/display: Implement dm_pp_get_clock_levels_by_type_with_latency
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
This is required so we use the correct minimum clocks for Vega. Without
this pplib will never be able to enter the lowest clock states.
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
We are not sure these calculations will never need negative numbers. Use
signed integers and warn and cap at 0 if this ever happens.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
The below commit
"drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2"
introduces a slight behavioral change to rmfb. Instead of disabling a crtc
when the primary plane is disabled, it now preserves it.
Since DC is currently not equipped to handle this we need to fail such
a commit, otherwise we might see a corrupted screen.
This is based on Shirish's previous approach but avoids adding all
planes to the new atomic state which leads to a full update in DC for
any commit, and is not what we intend.
Theoretically DM should be able to deal with states with fully populated planes,
even for simple updates, such as cursor updates. This should still be
addressed in the future.
Signed-off-by: Harry Wentland <[email protected]>
Tested-by: Michel Dänzer <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Cc: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
Some eDP displays use the extra link rate table to advertise link rate
support. If they do that they don't need to provide link rate through
the usual registers. Since we don't currently have support for the extra
link rate table default to HBR2 for the display in this.
Note that this is a HACK. Ultimately we need to teach DC to use the
extra link rate table.
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Even though this is required for degamma since DCE HW only supports a
couple predefined LUTs we can just program the LUT directly for regamma.
This fixes dark screens which occurs when we program regamma to bypass
while degamma is using srgb LUT.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Leo Li <[email protected]>
Cc: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
We enabled this upstream by default now and no longer need the flag.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
We shouldn't attempt to read EDID in atomic_check. We really shouldn't
even be modifying the connector object, or any other non-state object,
but this is a start at least.
Moving EDID cleanup to dm_dp_mst_connector_destroy from
dm_dp_destroy_mst_connector to ensure the EDID is still available for
headless mode.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
The below commit
"drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2"
introduces a slight behavioral change to rmfb. Instead of disabling a crtc
when the primary plane is disabled, it now preserves it.
Since DC is currently not equipped to handle this we need to fail such
a commit, otherwise we might see a corrupted screen.
This is based on Shirish's previous approach but avoids adding all
planes to the new atomic state which leads to a full update in DC for
any commit, and is not what we intend.
Theoretically DM should be able to deal with states with fully populated planes,
even for simple updates, such as cursor updates. This should still be
addressed in the future.
Signed-off-by: Harry Wentland <[email protected]>
Tested-by: Michel Dänzer <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Cc: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
Even though this is required for degamma since DCE HW only supports a
couple predefined LUTs we can just program the LUT directly for regamma.
This fixes dark screens which occurs when we program regamma to bypass
while degamma is using srgb LUT.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Leo Li <[email protected]>
Cc: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
We're an atomic driver and shouldn't access legacy properties. Doing so
will only scare users with stack traces.
Instead save the prop in the state and access it directly. Much simpler.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Reviewed-by: Andrey Grodzovsky <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
We shouldn't attempt to read EDID in atomic_check. We really shouldn't
even be modifying the connector object, or any other non-state object,
but this is a start at least.
Moving EDID cleanup to dm_dp_mst_connector_destroy from
dm_dp_destroy_mst_connector to ensure the EDID is still available for
headless mode.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Even though we default PRE_VEGA support to 'n' upstream in amd-staging
we want to keep it enabled by default.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
They were used by amdgpu_dm at some point but since it has its own
amdgpu_dm_connector now these aren't needed anymore.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
There's no good place in DC to cover all place where stream signal should
be updated. update_stream_signal depends on timing which comes from DM.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
We've got a helper function to call dc_create_stream_for_sink and one
other place that calls it directly. Make sure we call the helper
functions always since we need to update a bunch of things in stream and
don't want to miss that.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Our APUs (Carrizo, Stoney, Raven) don't support it.
v2: Don't use is_apu as other ASICs might also not support it
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
There have been many reports of Ellesmere and Baffin systems not being
able to drive HDMI 4k60 due to the fact that we check the HDMI_6GB_EN
bit from VBIOS table. Windows seems to not have this issue.
On some systems we fail to the encoder cap info from VBIOS. In that case
we should default to enabling HDMI6G support.
This was tested by dwagner on
https://bugs.freedesktop.org/show_bug.cgi?id=102820
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Roman Li <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
There have been many reports of Ellesmere and Baffin systems not being
able to drive HDMI 4k60 due to the fact that we check the HDMI_6GB_EN
bit from VBIOS table. Windows seems to not have this issue.
On some systems we fail to the encoder cap info from VBIOS. In that case
we should default to enabling HDMI6G support.
This was tested by dwagner on
https://bugs.freedesktop.org/show_bug.cgi?id=102820
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Roman Li <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
This is really just a copy of dm_pp_clocks_state, so just use that one.
Thanks to Matthias Kaehlke for spotting this.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Roman Li <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
These should only be non-0 if big hammer w/a is implemented. Currently
DC doesn't implement it, so leave them 0.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Charlene Liu <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
There's no good place in DC to cover all place where stream signal should
be updated. update_stream_signal depends on timing which comes from DM.
Signed-off-by: Harry Wentland <[email protected]>
Reviewed-by: Tony Cheng <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
We're currently not using this.
v2: More files and includes to remove.
Signed-off-by: Harry Wentland <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Harry Wentland