[Why]
In some usecases, like tiled display, the stream and plane configuration
can be setup in a way where the caller expects DAL to perform the
clipping, eg:
P0:
src_rect(0, 0, w, h)
dst_rect(0, 0, w, h)
P1:
src_rect(w, 0, w, h)
dst_rect(0, 0, w, h)
Cursor is enabled on both streams with the same position.
This can result in double cursor on tiled display, even though this
behavior is technically correct from the DC interface point of view.
We need a mechanism to control this dynamically.
[How]
This is something that should live in the DM layer based on detection
of the specified configuration but it's not something that we really
have enough information to deal with today.
Add a flag to the cursor position state that specifies whether we
want DC to do the translation or not and make it opt-in and let
the DM decide when to do it.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Cursor pos is correctly adjusted from DC side for source rect offset
on DCN ASIC, but only on the overlay.
This is because DM places offsets the cursor for primary planes only
to workaround missing code in DCE for the adjustment we're now correctly
doing in DC for DCN ASIC.
[How]
Drop the adjustment for source rect from the DM side of things and put
the code where it actually belongs - in DC on the pipe level.
This matches what we do for DCN now.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Zhan Liu <Zhan.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Prop are created at boot stage, and not allowed to create new prop
after device registration.
[How]
Reuse the connector property from SST if exist.
Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Pankaj Bharadiya started cleaning up the MST connector callbacks a while
ago, as I pointed out that they are the same across every driver and
don't serve much purpose. There was one callback that was left over
though from amdgpu, that we delayed removing due to not being completely
sure as to whether or not it was needed.
So, I've read through said callback and can confirm it's not at all
needed. Pretty much all of the work that is done in
dm_dp_destroy_mst_connector() can be done in
dm_dp_mst_connector_destroy(). Additionally, I've removed some bits that
didn't actually do anything:
* Removed DRM_INFO message we were printing, this shouldn't be info
level and there's more appropriate drm debugging flags that should be
used instead
* Removed amdgpu_dm_update_freesync_caps() - reading into this function,
it doesn't actually do anything important and I'm not sure why it was
ever being called here
* Stop clearing aconnector->dc_sink - this also doesn't do anything
* Stop clearing link settings in dc_link - this also doesn't do anything
* Also, use shorter variable
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200331205740.135525-3-lyude@redhat.com
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
We already trace DPCD reads/writes on both MST and SST, there's no
reason to have this code here (plus, toggling these things with a
define at the top of the file isn't how we do things in the kernel).
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Some displays have an issue where the hdcp chips are initialized after the
display has already lit up. This means we can sometimes authentication too early
and cause authentication failures.
This happens when HDCP is enabled and the display is power cycled. Normally we
will authenticate 2 seconds after the display is lit, but some displays need a
bit more time.
[How]
Increase delay to 3 second before we start authentication.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
-We need to cancel future callbacks/watchdogs events when a callback/watchdog event happens
[How]
-fix typo in event_callback()
-cancel callback, not watchdog
-cancel watchdog events in event_watchdog_timer().
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When content type property is set to 1. We should enable hdcp2.2 and if we cant
then stop. Currently the way it works in DC is that if we fail hdcp2, we will
try hdcp1 after.
[How]
Use link config to force disable hdcp1.4 when type1 is set.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
BT2020 is not supported in COLOR_ENCODING property of planes. Only
BT601 and BT709 was available.
[How]
Allow BT2020 as legit value in setting COLOR_ENCODING property.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
events at vsartup for DCN")' introduces a new way of pageflip
completion handling for DCN, and some trouble.
The current implementation introduces a race condition, which
can cause pageflip completion events to be sent out one vblank
too early, thereby confusing userspace and causing flicker:
prepare_flip_isr():
1. Pageflip programming takes the ddev->event_lock.
2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED
3. Releases ddev->event_lock.
--> Deadline for surface address regs double-buffering passes on
target pipe.
4. dc_commit_updates_for_stream() MMIO programs the new pageflip
into hw, but too late for current vblank.
=> pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete
in current vblank due to missing the double-buffering deadline
by a tiny bit.
5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires,
dm_dcn_crtc_high_irq() gets called.
6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the
pageflip has been completed/will complete in this vblank and
sends out pageflip completion event to userspace and resets
pflip_status = AMDGPU_FLIP_NONE.
=> Flip completion event sent out one vblank too early.
This behaviour has been observed during my testing with measurement
hardware a couple of time.
The commit message says that the extra flip event code was added to
dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events
in case the pflip irq doesn't fire, because the "DCH HUBP" component
is clock gated and doesn't fire pflip irqs in that state. Also that
this clock gating may happen if no planes are active. This suggests
that the problem addressed by that commit can't happen if planes
are active.
The proposed solution is therefore to only execute the extra pflip
completion code iff the count of active planes is zero and otherwise
leave pflip completion handling to the pflip irq handler, for a
more race-free experience.
Note that i don't know if this fixes the problem the original commit
tried to address, as i don't know what the test scenario was. It
does fix the observed too early pageflip events though and points
out the problem introduced.
Fixes: 16f17eda8b ("drm/amd/display: Send vblank and user events at vsartup for DCN")
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We should check MST BU support capability on output port before building
vsc info packet.
[How]
Add a new definition for port and sink capability check.
Signed-off-by: Martin Tsai <martin.tsai@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The PSR enablement was dependent on swizzle as a workaround for
non-pageflipping fb console. It's no longer required.
[How]
Remove PSR-enable dependency on swizzle mode.
Signed-off-by: Roman Li <roman.li@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
This is enabled by default on Renoir but there's userspace/API support
to actually make use of this.
Since we're not passing this down through surface updates, let's
explicitly disable this for now.
This fixes "dcn20_program_front_end_for_ctx" warnings associated with
incorrect/unexpected programming sequences performed while this is
enabled.
[How]
Disable it at the topmost level in DM in case anyone tries to flip this
to enabled for any of the other ASICs like Navi10/14.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
drm_connector->display_info is not passed to amdgpu_dm right way after
read edid.
[How]
display_info is parsed from edid and saved into drm_connector by
drm_connector_update_edid_proerty which is called within
amdgpu_dm_update_connector_after_detect. call this function after read
edid to update drm_connector->display_info
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These are some very loud debug statements that get printed on every
vblank when driver level debug printing is enabled in DRM, and doesn't
really tell us anything that isn't related to vblanks. So let's move
this over to the proper debug flag to be a little less spammy with our
debug output.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amd-drm-next-5.7-2020-03-10:
amdgpu:
- SR-IOV fixes
- Fix up fallout from drm load/unload callback removal
- Navi, renoir power management watermark fixes
- Refactor smu parameter handling
- Display FEC fixes
- Display DCC fixes
- HDCP fixes
- Add support for USB-C PD firmware updates
- Pollock detection fix
- Rework compute ring priority handling
- RAS fixes
- Misc cleanups
amdkfd:
- Consolidate more gfx config details in amdgpu
- Consolidate bo alloc flags
- Improve code comments
- SDMA MQD fixes
- Misc cleanups
gpu scheduler:
- Add suport for modifying the sched list
uapi:
- Clarify comments about GEM_CREATE flags that are not used by userspace.
The kernel driver has always prevented userspace from using these.
They are only used internally in the kernel driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310212748.4519-1-alexander.deucher@amd.com
drm_dp_mst_port_add_connector() directly calls the
drm_connector_register() now and
drm_dp_mst_topology_mgr_cbs.register_connector callback is not getting
called anymore.
Hence remove all drm_dp_mst_topology_mgr_cbs.register_connector
callbacks.
This is the preparatory step for removing the
drm_dp_mst_topology_mgr_cbs.register_connector callback hook.
The removal is done with below sementic patch:
@r1@
identifier func, E;
@@
struct drm_dp_mst_topology_cbs E = {
...,
- .register_connector = func
};
@delete depends on r1@
identifier r1.func;
@@
- static void func(...){...}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-3-pankaj.laxminarayan.bharadiya@intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
[why]
FEC capability query should not be affected by debugging decision on
whether to disable FEC. We should not determine if display supports FEC
by checking debug option.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
It is possible even if sink signal is MST but driver enables SST stream.
We should not determine if we should do MST authentication based on
sink's capability.
Instead we should determine whether to do MST authentication based on
what we have enabled in stream.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This interface is for dGPU Navi1x. Linux dc-pplib interface depends
on window driver dc implementation.
For Navi1x, clock settings of dcn watermarks are fixed. the settings
should be passed to smu during boot up and resume from s3.
boot up: dc calculate dcn watermark clock settings within dc_create,
dcn20_resource_construct, then call pplib functions below to pass
the settings to smu:
smu_set_watermarks_for_clock_ranges
smu_set_watermarks_table
navi10_set_watermarks_table
smu_write_watermarks_table
For Renoir, clock settings of dcn watermark are also fixed values.
dc has implemented different flow for window driver:
dc_hardware_init / dc_set_power_state
dcn10_init_hw
notify_wm_ranges
set_wm_ranges
For Linux
smu_set_watermarks_for_clock_ranges
renoir_set_watermarks_table
smu_write_watermarks_table
dc_hardware_init -> amdgpu_dm_init
dc_set_power_state --> dm_resume
therefore, linux dc-pplib interface of navi10/12/14 is different
from that of Renoir.
v2: add missing unlock in error case
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This interface is for dGPU Navi1x. Linux dc-pplib interface depends
on window driver dc implementation.
For Navi1x, clock settings of dcn watermarks are fixed. the settings
should be passed to smu during boot up and resume from s3.
boot up: dc calculate dcn watermark clock settings within dc_create,
dcn20_resource_construct, then call pplib functions below to pass
the settings to smu:
smu_set_watermarks_for_clock_ranges
smu_set_watermarks_table
navi10_set_watermarks_table
smu_write_watermarks_table
For Renoir, clock settings of dcn watermark are also fixed values.
dc has implemented different flow for window driver:
dc_hardware_init / dc_set_power_state
dcn10_init_hw
notify_wm_ranges
set_wm_ranges
For Linux
smu_set_watermarks_for_clock_ranges
renoir_set_watermarks_table
smu_write_watermarks_table
dc_hardware_init -> amdgpu_dm_init
dc_set_power_state --> dm_resume
therefore, linux dc-pplib interface of navi10/12/14 is different
from that of Renoir.
v2: add missing unlock in error case
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Typo in amdgpu_dm error message:
"Failed to found connector for link!"
[How]
1. Replace with:
"Failed to find connector for link!"
2. Fix indentation checkpatch warnings.
Signed-off-by: Roman Li <roman.li@amd.com>
Reviewed-by: Zhan Liu <Zhan.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Nothing else calls it. Not sure it's necessary.
v2: remove unused port variable.
Reviewed-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Split into init and register functions to avoid a segfault
in some configs when the load/unload callbacks are removed.
v2:
- add back accidently dropped has_aux setting
- set dev in late_register
v3:
- fix dp cec ordering
v4:
- squash in kdev reference fix
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for display.
v2: add config guard for DC
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Harry Wentland <harry.wentland@amd.com> (v1)
Acked-by: Christian König <christian.koenig@amd.com> (v1)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use the existence of the workqueue itself to determine when to
enable HDCP features rather than sprinkling asic checks all over
the code. Also add a check for the existence of the hdcp
workqueue in the irq handling on the off chance we get and HPD
RX interrupt with the CP bit set. This avoids a crash if
the driver doesn't support HDCP for a particular asic.
Fixes: 96a3b32e67 ("drm/amd/display: only enable HDCP for DCN+")
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206519
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Firmware state helps to debug sequence issues and hangs for DMCUB
commands and we don't have an easy mechanism to dump it from the driver.
[How]
Add a debugfs entry to dump the current firmware state.
Example usage:
cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_fw_state
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
If we're doing backdoor load then do it entirely ourselves without
invoking any of the frontdoor path to avoid potential issues with
outdated tOS.
[How]
Check the load type and don't pass it to base if we don't want it
loaded.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use the existence of the workqueue itself to determine when to
enable HDCP features rather than sprinkling asic checks all over
the code. Also add a check for the existence of the hdcp
workqueue in the irq handling on the off chance we get and HPD
RX interrupt with the CP bit set. This avoids a crash if
the driver doesn't support HDCP for a particular asic.
Fixes: 96a3b32e67 ("drm/amd/display: only enable HDCP for DCN+")
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206519
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Lyude needs some patches in 5.6-rc2 and we didn't bring drm-misc-next
forward yet, so it looks like a good occasion.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
