This can fix the compile errors below:
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function ‘smu_v11_0_baco_set_state’:
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1674:27: error: implicit declaration of function ‘amdgpu_ras_get_context’ [-Werror=implicit-function-declaration]
struct amdgpu_ras *ras = amdgpu_ras_get_context(adev);
^
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1674:27: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1692:19: error: dereferencing pointer to incomplete type ‘struct amdgpu_ras’
if (!ras || !ras->supported) {
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enable baco reset support on Arcturus.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Added bif doorbell interrupt setting and applied different
settings for BACO reset for RAS recovery.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
As we may park the gt during request retirement, we may cancel the
retirement worker only to then program the delayed worker once more.
If we schedule the next delayed retirement worker first, if we then park
the gt, the work will remain cancelled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119162559.3313003-2-chris@chris-wilson.co.uk
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner. A miniscule
optimisation.
References: 7936a22dd4 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119162559.3313003-1-chris@chris-wilson.co.uk
For our current users we don't expect pool objects to be writable from
the gpu.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 4f7af1948a ("drm/i915: Support ro ppgtt mapped cmdparser shadow buffers")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119150154.18249-1-matthew.auld@intel.com
The bspec initially provided a single DKL PHY vswing table for both HDMI
and DP, but was recently updated to include an independent table for
HDMI.
Bspec: 49292
Fixes: 978c3e539b ("drm/i915/tgl: Add dkl phy programming sequences")
Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118180219.9309-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
On zang's Dell XPS 13 9370 after Thunderbolt NVM firmware upgrade the
Thunderbolt controller did not come back as expected. Only after the
system was rebooted it became available again. It is not entirely clear
what happened but I suspect the new NVM firmware image authentication
failed for some reason. Regardless of this the router needs to be power
cycled if NVM authentication fails in order to get it fully functional
again.
This modifies the driver to issue a power cycle in case the NVM
authentication fails immediately when dma_port_flash_update_auth()
returns. We also need to call tb_switch_set_uuid() earlier to be able to
fetch possible NVM authentication failure when DMA port is added.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205457
Reported-by: zang <dump@tzib.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 1d4639567d ("mdio_bus: Fix PTR_ERR applied after initialization
to constant") accidentally changed a check from -ENOTSUPP to -ENOSYS,
causing failures if reset controller support is not enabled. E.g. on
r7s72100/rskrza1:
sh-eth e8203000.ethernet: MDIO init failed: -524
sh-eth: probe of e8203000.ethernet failed with error -524
Seen on r8a7740/armadillo, r7s72100/rskrza1, and r7s9210/rza2mevb.
Fixes: 1d4639567d ("mdio_bus: Fix PTR_ERR applied after initialization to constant")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: YueHaibing <yuehaibing@huawei.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Before returning NULL, put the sock first.
Cc: stable@vger.kernel.org
Fixes: cf1b2326b7 ("nbd: verify socket is supported during setup")
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Sun Ke <sunke32@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This reverts commit 1c42591591.
S/G display is not stable with the IOMMU enabled on some
platforms.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There are still combinations of sbios and firmware that
are not stable.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204689
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When gfxoff is enabled, accessing gfx registers via MMIO
can lead to a hang.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497
Acked-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
So that the setting reflects what the hw supports. This will
be used in a subsequent patch so needs to be correct.
v2: squash in fix from Colin Ian King
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
return errno code to caller when error occur, and meanwhile
remove gcc '-Wunused-but-set-variable' warning.
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c: In function vegam_populate_smc_boot_level:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1364:6: warning: variable result set but not used [-Wunused-but-set-variable]
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Chen Wandun <chenwandun@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c:64:13-31: WARNING: dma_alloc_coherent use in ih -> ring already zeroes out memory, so memset is not needed
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address. This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).
Instead, use the DMA address of the dummy page because it will always
be safe.
Fixes: 27ae10641e ("drm/amdgpu: add interupt handler implementation for si v3")
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address. This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).
Instead, use the DMA address of the dummy page because it will always
be safe.
Fixes: d8f60cfc93 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)")
Fixes: 25a857fbe9 ("drm/radeon/kms: add support for interrupts on SI")
Fixes: a59781bbe5 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_legacy_tv.c: In function radeon_legacy_tv_mode_set:
drivers/gpu/drm/radeon/radeon_legacy_tv.c:538:24: warning: variable tv_pll_cntl1 set but not used [-Wunused-but-set-variable]
It is introduced by commit 4ce001abaf ("drm/radeon/kms:
add initial radeon tv-out support."), but never used,
so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_combios.c: In function radeon_combios_get_power_modes:
drivers/gpu/drm/radeon/radeon_combios.c:2638:10: warning: variable blocks set but not used [-Wunused-but-set-variable]
It is introduced by commit 56278a8eda ("drm/radeon/kms:
pull power mode info from bios tables (v3)"), but never used,
so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_display.c: In function radeon_crtc_scaling_mode_fixup:
drivers/gpu/drm/radeon/radeon_display.c:1685:27: warning: variable radeon_connector set but not used [-Wunused-but-set-variable]
It is not used since commit 377bd8a98d ("drm/radeon:
use a fetch function to get the edid")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/atombios_dp.c: In function radeon_dp_get_panel_mode:
drivers/gpu/drm/radeon/atombios_dp.c:415:36: warning: variable dig_connector set but not used [-Wunused-but-set-variable]
It is not used since commit 379dfc25e2 ("drm/radeon/dp:
switch to the common i2c over aux code")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/si_dpm.c: In function si_program_response_times:
drivers/gpu/drm/radeon/si_dpm.c:3640:29: warning: variable backbias_response_time set but not used [-Wunused-but-set-variable]
It is introduced by commit a9e6141092 ("drm/radeon/kms:
add dpm support for SI (v7)"), but never used, so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/r600_cs.c: In function r600_cs_track_validate_cb:
drivers/gpu/drm/radeon/r600_cs.c:353:22: warning: variable size set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/r600_cs.c: In function r600_cs_track_validate_db:
drivers/gpu/drm/radeon/r600_cs.c:520:27: warning: variable size set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/r600_cs.c: In function r600_dma_cs_next_reloc:
drivers/gpu/drm/radeon/r600_cs.c:2345:26: warning: variable relocs_chunk set but not used [-Wunused-but-set-variable]
The first 'size' is not used since commit f30df2fad0 ("drm/radeon/r600:
fix tiling issues in CS checker.")
The second 'size' is introduced by commit 88f50c8074 ("drm/radeon/kms:
add htile support to the cs checker v3"), but never used, so remove it.
'relocs_chunk' is not used since commit 9305ede6af ("radeon/kms:
fix dma relocation checking")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
For MST connector atomic check we have to check a new CRTC state
instead of an old one, when checking if CRTC is disabled to
release VCPI slots allocated.
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
static analysis throws the error below
Out-of-bounds read (OVERRUN)
Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
(uint64_t *)hdcp->auth.msg.hdcp1.bksv.
var n is going to contain r0p and bcaps. if they are non-zero the count
will be wrong
How]
Use memcpy instead to avoid this.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Currently we share rxstatus between HDMI and DP, so we use 16bits
The drm defines work with 1bytes at a time. So we need to
split the HDMI rxstatus into 2bytes before we can use drm defines
[How]
-create rxstatus for dp and hdmi. rxstatus for hdmi is split into bytes
using arrays.
-use drm_hdcp defines for the remaining structs
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
drm already has this define
[How]
drm Mask is 0x08 vs 0x0800. The reason is because drm mask
works on a byte. ^^
=======||
||
Since the first byte is always zero we can ignore it and only check the
second byte.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
These defines/macros exist already no need to redefine them
[How]
Use the defines/macros from drm_hdcp.h
-we share the rxstatus between HDMI and DP (2 bytes), But upstream
defines/macros for HDMI are for 1 byte. So we need to create a separate
rxstatus for HDMI
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The old way was to poll PSP and update the properties. But due to a
limitation in the PSP interface this doesn't work for MST.
[How]
According to PSP if set_encryption return success, the link is encrypted
and the only way it will not be is if we get a link loss(which we handle
already).
So this method should be good enough to report HDCP status.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Before we had a disable_type1 flag, this forced HDCP 2.2 to type0
There was no way to force type1.
[How]
Remove disable_type1 flag and instead add a flag to force type0/1.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We need to do this to support HDCP over MST
Currently we save a display per link, in a MST case we need to save
multiple displays per link.
[How]
We can create an array per link to cache the displays, but it
complicates the design. Instead we can use the module to cache the
displays.
Now we will always add all the displays to the module, but we use the
adjustment flag to disable hdcp on all of them before they are added.
When we want to enable hdcp we just query the display(cache), remove
it then add it back with different adjustments. Its the similar for
disable.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
HDCP 2.2 uses type0 and type1 content type. This is passed to the receiver
to stream the proper content.
For example, in a MST case if the main
device is HDCP2.2 capable but the secondary device is only 1.4 capabale
we can use Type0
Type0 content: use HDCP 1.4 or HDCP2.2 type0
Type1 content: Only use HDCP 2.2 type1
[How]
We use the "hdcp content type" property in drm. We use the
disable_type1 flag in hdcp module to select the type based on the
properties.
For updating the property we use the same logic as 1.4, but now we
consider content_type as well and update the property if the
requirements are met
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
HDCP 2.2 was disabled, we need to enable it
[How]
-Update display topology to support 2.2
-Unset hdcp2.disable in update_config
-Change logic of event_update_property, now we set the property to be
ENABLED for any level of encryption (2.2 or 1.4).
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
HDCP is a bit finicky so we try it 3 times, this leads to a case where
if we fail the first time and pass the second time the error is still
shown in dmesg for the first failed attempt.
This leads to false positive errors.
[How]
Change the logging from ERROR to WARNING. Warnings are still shown in dmesg
to know what went wrong.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We need to log the state changes for 2.2
This patch extends the existing logging functions to handle
HDCP2.2.
[How]
We do this by adding if/else in the defines, and output the log
based on the hdcp version
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The module works like a state machine
+-------------+
------> | Execution.c | ------
| +-------------+ |
| V
+----+ +--------+ +--------------+
| DM | -----> | Hdcp.c | <------------ | Transition.c |
+----+ <----- +--------+ +--------------+
This patch adds the execution and transition files for 2.2
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We need these to read and write to aux/i2c, during
authentication
[How]
Create read/write functions for all the steps
(Eg, h_prime, paring_info etc)
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
All the HDCP transactions should be verified using PSP
[How]
This patch adds the psp calls we need to verify the steps
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We need some extra dmub_cmd_type for NV10
[How]
Add command table functions in DMUB firmware.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Xiong Yan <Xiong.Yan@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-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]
Need to be able to enable native 422 for debugging purposes.
[How]
Add new dc_debug_options bool and check it in the get_dsc_enc_caps
function.
Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
When updating DSC config, a new config has to be validated before proceeding
with applying the update. Validation, however, modifies the current state.
This means DSC config validation would affect pipe re-assignment, causing
intermittent screen corruption issues when ODM is required for DSC.
[how]
- Use a copy of the current state for modified DSC config validation
- Set the update type to FULL_UPDATE to correctly validate and set the
actual state used for committing the streams
Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DCN will hang if we access registers before PHY init is done.
So we need to spin or abort.
[How]
On hardware with DMCUB running and working we shouldn't time out
waiting for this to finish and we shouldn't hit the spin cycle.
If there's no hardware support then we should exit out of the function
early assuming that PHY init was already done elsewhere.
If we hit the timeout then there's likely a bug in firmware or software
and we need to debug - add errors and asserts as appropriate.
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]
Need validation that we are programming the expected values (rq, ttu, dlg)
from DML. This debug feature will output logs if we are programming
incorrect values and may help differentiate DAL issues from HW issues.
[How]
Dump relevant registers for each pipe with active stream. Compare current
reg values with the converted DML output. Log mismatches when found.
Signed-off-by: Jaehyun Chung <jaehyun.chung@amd.com>
Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
It is becoming increasingly hard to figure out which
function is called on the different DCN versions
[How]
1. Make function pointer table init in its own init.c file
2. Remove other scenarios in hwseq.c file that need to
include headers of other DCN versions. (If needed,
it should have been done via the function pointers)
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
It's an interface violation to use infinite loops within DMUB
service functions and we'll lock up the kernel by doing so.
[How]
Revert the function back to its intended functionality.
Move the infinite loops into DC/DM as necessary.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
There can be a conflict between OS HDR multiplier and 3dlut HDR
multiplier, which are both sent to DC.
[HOW]
Instead of having dc determine which HDR multiplier to use, make the
decision in dm and send only the intended value in a surface update.
Store the current OS HDR multiplier and determine whether to use it or
the 3dlut's multiplier before sending the surface update to dc. Send
multiplier to dc in fixed31_32 format, dc then converts it to hw format.
Signed-off-by: Michael Strauss <michael.strauss@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
