| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[Why]
These values can differ per ASIC and should follow the full DC style
register programming model.
[How]
Define a common list and fill in the common list separately for
dcn20 and dcn21.
Unlike DC we're not using designated initializers for better compiler
compatibility since this resides in the DMUB service.
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]
Scratch registers are limited on the DMCUB and we have an expanding
list of state to track between driver and DMCUB.
[How]
Place shared state in cache window 6. The cache window size is aligned
to the size of the cache line on the DMCUB to make it easy to
invalidate.
The shared state is intended to be read only from driver side so
it's been marked as const.
The use of volatile is intentional. The memory for the shared firmware
state is memory mapped from the framebuffer memory. The DMCUB will
flush its cache after modifying the region. There's no way for x86
to known whether this data is stale or not so we want to intentionally
disable optimization to force the read at every access.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Commands will be considered a stable ABI between driver and firmware.
Commands are also split between DC commands, DAL feature commands,
and VBIOS commands.
Commands are currently not designated to a specific ID and the enum
does not provide a stable ABI.
We currently group all of these into a single command type of 8-bits.
With the stable ABI consideration in mind it's not unreasonable to
run out of command IDs.
For cleaner separation and versioning split the commands into a main
type and a subtype.
[How]
For commands where performance matters (like reg sequences) these
are still considered main commands.
Sub commands will be split by ownership/feature.
Update existing command sequences to reflect new changes.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
On dcn21 this is programmed for tracebuffer support but isn't being
programmed on dcn20.
DMCUB execution hits an undefined address 65000000 on tracebuffer
access.
[How]
Program CW5.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Not having support for autoload isn't an error. If the DMUB firmware
doesn't support it then don't return DMUB_STATUS_INVALID.
[How]
Return DMUB_STATUS_OK when ->is_auto_load_done is NULL.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
The wait for PHY init won't finish if the firmware doesn't support it.
[How]
Only hook this functionality up on DCN21 and move it out of DCN20.
For ASIC without support then this should return OK so we don't hang
while waiting in DC.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@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]
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 & How]
1. Add trace code enum for easy debugging.
2. Add trace during uC boot up, including loading phy FW
and dmcu FW.
3. Change cache memory type back to write back,
since write through has issue when resume from S0i3 100% hang after
3.2ms.
4. Change CW3 base address to hard code value to avoid memory overlap
with cw1.
5. Change polling phy init done to infinite loop to avoid dcn hang when
dmcub uC stalled.
6. Add dmcub FW dis-assembly file to repositatory for debug purpose.
Signed-off-by: Yongqiang Sun <yongqiang.sun@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]
By default we shouldn't be trying to write secure registers during
DMUB hardware init.
[How]
Add a parameter to control whether we put the DMCUB into secure reset
and attempt to load CW0/CW1.
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]
We want to avoid reprogramming the cache window when possible.
We don't need to worry about it for S3 but we *do* need to worry about
it for S4 resume.
DM can check whether hardware should be reinitialized or store software
state when going to S4 to know whether we need to reprogram hardware.
[How]
Add helpers to the DMUB service to check hardware initialization state.
DM will hook it up later.
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>
|
|
There are spelling mistakes in a DC_ERROR message and a comment.
Fix these.
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Support for DMUB only depends on support for DC. It doesn't use floating
point so we don't need to guard it by any specific DCN revision.
[How]
Drop the guards and cleanup the newlines around each one.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The DMUB service is the interface to the DMCUB.
It's required to support Renoir features so it will be enabled and
compiled automatically when the Renoir display engine is enabled via
CONFIG_DRM_AMD_DC_DCN2_1.
DMUB code will initially be guarded by CONFIG_DRM_AMD_DC_DMUB and later
switched to CONFIG_DRM_AMD_DC_DCN2_1 with the config option dropped.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
