linux.git/drivers/gpu/drm/amd/display/dc/bios, branch v5.6 Linux kernel source tree drm/amd/display: Don't map ATOM_ENABLE to ATOM_INIT 2020-02-11T20:38:27+00:00 Nicholas Kazlauskas nicholas.kazlauskas@amd.com 2020-01-20T19:56:31+00:00 1094c34ec53bc147e53f52ed9fe50899ad075632 [Why] In DCN hardware sequencer we do actually call ATOM_INIT correctly per pipe. The workaround is not necessary for command table offloading. [How] Drop the workaround since it's not needed. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
In DCN hardware sequencer we do actually call ATOM_INIT correctly per
pipe. The workaround is not necessary for command table offloading.

[How]
Drop the workaround since it's not needed.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Chris Park <Chris.Park@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Call ATOM_INIT instead of ATOM_ENABLE for DMCUB 2020-01-22T21:55:28+00:00 Nicholas Kazlauskas nicholas.kazlauskas@amd.com 2020-01-11T18:43:39+00:00 cc934031dc2a0be9535477dbef4b0e94c9f06ecd [Why] DMCUB command table doesn't support ATOM_ENABLE/ATOM_DISABLE anymore so we never end up calling the DCN init path in DMCUB. [How] Map ATOM_ENABLE to ATOM_INIT only for DMCUB command table offloading. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
DMCUB command table doesn't support ATOM_ENABLE/ATOM_DISABLE anymore
so we never end up calling the DCN init path in DMCUB.

[How]
Map ATOM_ENABLE to ATOM_INIT only for DMCUB command table offloading.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Fallback to DMCUB when command table is missing 2020-01-22T21:55:27+00:00 Nicholas Kazlauskas nicholas.kazlauskas@amd.com 2020-01-06T18:21:48+00:00 830821a64db63026a8b7414b2b539f262821ad23 [Why] If the command table isn't available then we can fallback to DMCUB offloading if it's enabled and available. [How] Instead of assigning NULL for supported command table functions we can fallback to the DMCUB when it's available. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
If the command table isn't available then we can fallback to DMCUB
offloading if it's enabled and available.

[How]
Instead of assigning NULL for supported command table functions we can
fallback to the DMCUB when it's available.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Split DMUB cmd type into type/subtype 2019-12-05T21:30:35+00:00 Nicholas Kazlauskas nicholas.kazlauskas@amd.com 2019-11-12T20:33:37+00:00 d4bbcecb596296834aeafb93008474671c7988cf [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]
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>
drm/amd/display: fix dprefclk and ss percentage reading on RN 2019-12-05T21:28:57+00:00 Eric Yang Eric.Yang2@amd.com 2019-11-10T17:08:02+00:00 e6d9a93c141e0bcc3a40671b2338c093d04ab14b [Why] Before was using HW counter value to determine the dprefclk. Which take into account ss, but has large variation, not good enough for generating audio dto. Also, the bios parser code to get the ss percentage was not working. [How] After this change, dprefclk is hard coded, same as on RV. We don't expect this to change on Renoir. Modified bios parser code to get the right ss percentage. Signed-off-by: Eric Yang <Eric.Yang2@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]
Before was using HW counter value to determine the dprefclk. Which
take into account ss, but has large variation, not good enough for
generating audio dto. Also, the bios parser code to get the ss
percentage was not working.

[How]
After this change, dprefclk is hard coded, same as on RV. We don't
expect this to change on Renoir. Modified bios parser code to get
the right ss percentage.

Signed-off-by: Eric Yang <Eric.Yang2@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>
drm/amd/display: populate bios integrated info for renoir 2019-12-05T21:28:30+00:00 Joseph Gravenor joseph.gravenor@amd.com 2019-11-08T00:20:00+00:00 01290a5766e1be38ee9f114d261bee263b168ab4 [Why] When video_memory_type bw_params->vram_type is assigned, wedistinguish between Ddr4MemType and LpDdr4MemType. Because of this we will never report that we are using LpDdr4MemType and never re-purpose WM set D [How] populate bios integrated info for renoir by adding the revision number for renoir and use that integrated info table instead of of asic_id to get the vram type Signed-off-by: Joseph Gravenor <joseph.gravenor@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]
When video_memory_type bw_params->vram_type
is assigned, wedistinguish between Ddr4MemType and LpDdr4MemType.
Because of this we will never report that we are using
LpDdr4MemType and never re-purpose WM set D

[How]
populate bios integrated info for renoir by adding the
revision number for renoir and use that integrated info
table instead of of asic_id to get the vram type

Signed-off-by: Joseph Gravenor <joseph.gravenor@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>
drm/amd/display: Remove unneeded semicolon in bios_parser2.c 2019-12-02T22:55:08+00:00 zhengbin zhengbin13@huawei.com 2019-11-28T02:31:38+00:00 c09f5e000d1e96de95da1aae2ce7ba25d3d207a7 Fixes coccicheck warning: drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c:995:2-3: Unneeded semicolon Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Fixes coccicheck warning:

drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c:995:2-3: Unneeded semicolon

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Remove unneeded semicolon in bios_parser.c 2019-12-02T22:55:08+00:00 zhengbin zhengbin13@huawei.com 2019-11-28T02:31:37+00:00 4c56feac0d47b0cf620a8f2e62c1c9cda8e22e54 Fixes coccicheck warning: drivers/gpu/drm/amd/display/dc/bios/bios_parser.c:2192:2-3: Unneeded semicolon Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Fixes coccicheck warning:

drivers/gpu/drm/amd/display/dc/bios/bios_parser.c:2192:2-3: Unneeded semicolon

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: cleanup of construct and destruct funcs 2019-11-19T15:12:52+00:00 Anthony Koo Anthony.Koo@amd.com 2019-11-01T01:39:39+00:00 d9e32672a1285d6c5e06bedaabb465441c172aa8 [Why] Too many construct functions which makes searching difficult, especially on some debuggers. [How] Append all construct and destruct functions with dcn number and object type to make each construct function name unique 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]
Too many construct functions which makes searching
difficult, especially on some debuggers.

[How]
Append all construct and destruct functions with dcn
number and object type to make each construct function
name unique

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>
drm/amd/display: remove set but not used variable 'bp' in bios_parser.c 2019-11-19T15:12:51+00:00 zhengbin zhengbin13@huawei.com 2019-11-14T12:36:26+00:00 7e30402bed151fc6222baafe5aa1abe3e65c3065 Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/display/dc/bios/bios_parser.c: In function bios_get_board_layout_info: drivers/gpu/drm/amd/display/dc/bios/bios_parser.c:2743:22: warning: variable bp set but not used [-Wunused-but-set-variable] It is introduced by commit 1eeedbcc20d6 ("drm/amd/display: get board layout for edid emulation"), but never used, so remove it. Reviewed-by: Harry Wentland <harry.wentland@amd.com> 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/amd/display/dc/bios/bios_parser.c: In function bios_get_board_layout_info:
drivers/gpu/drm/amd/display/dc/bios/bios_parser.c:2743:22: warning: variable bp set but not used [-Wunused-but-set-variable]

It is introduced by commit 1eeedbcc20d6 ("drm/amd/display:
get board layout for edid emulation"), but never used,
so remove it.

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>