linux.git/drivers/gpu/drm/amd/display/dmub/src, branch v5.6

drm/amd/display: Check hw_init state when determining if DMCUB is initialized

2020-01-22T21:55:28+00:00

[Why]
CW2 may already be programmed when coming back from S4. In this case
we want to unconditionally replace whatever DMCUB version is currently
enabled with the latest.

[How]
Check the hw_init flag to know whether or not we've previously executed
the initliazed routine.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: Reset inbox rptr/wptr when resetting DMCUB

2020-01-22T21:55:28+00:00

[Why]
These logically make sense more to be set after the DMCUB has been
reset rather than when we setup the inbox.

[How]
Move them into the reset callback.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: Add hardware reset interface for DMUB service

2020-01-22T21:55:28+00:00

[Why]
We'll need this to perform a clean shutdown before unloading the driver.

[How]
It will call reset internally and set hw_init to false. It won't do
anything if the hardware isn't initialized.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: Get fb base and fb offset for DMUB from registers

2020-01-22T21:55:27+00:00

[Why]
Under some hardware initialization sequences the fb base/fb offset
provided can be zero or hardwareinit can happen too late.

We want to ensure that we always have the correct fb_base/fb_offset
when performing DMCUB hardware initialization so we can do DMCUB
command table offloading during first dc hardware init.

[How]
Read from the DCN registers. VBIOS already filled these in for us.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Wesley Chalmers 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher

drm/amd/display: Soft reset DMUIF during DMUB reset

2020-01-16T18:51:24+00:00

[Why]
We need to ensure that the DMUIF in MMHUBBUB is also in reset so we
aren't generating requests while the DMCUB is in reset.

[How]
Set DMUIF_SOFT_RESET=1 on reset and DMUIF_SOFT_RESET=0 on reset
release.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Read inst_fb data back during DMUB loading

2020-01-16T18:46:13+00:00

[Why]
The inst firmware isn't necessarily fully flushed to framebuffer
memory and the DMCUB can hang due to invalid inst being parsed.

[How]
Like the fix to flush ringbuffer commands before updating the inbox
write pointer we need to read back inst memory before writing the
CW0 registers.

Add a helper to read 64-byte chunks to avoid a large temporary buffer.
Read the remaining leftover bytes if the inst_fb isn't fully aligned.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Flush framebuffer data before passing to DMCUB

2020-01-16T18:42:16+00:00

[Why]
There's a data race that can occur between when we update the
inbox write pointer vs when the memory for the command actually gets
flushed from the map to the framebuffer.

DMCUB can read stale or partially invalid data when this race occurs.

[How]
Before updating the write pointer we can read back all pending commands
to ensure that we stall for the writes to be flushed to framebuffer.

We don't need to worry about choosing HDP vs VM flush with this
mechanism.

Drop the dmub_srv_cmd_submit() while we're updating this to work
correctly since nothing was actually using this API and the caller
should be explicit about the API flow here - by doing this on execute
we can give some extra time for the flush to finish while
preparing other commands.

We should try to avoid writing single commands
because of this overhead.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Get cache window sizes from DMCUB firmware

2019-12-18T21:09:09+00:00

[Why]
Firmware state and tracebuffer shouldn't be considered stable API
between firmware versions.

Driver shouldn't be querying anything from firmware state or tracebuffer
outside of debugging.

Commands are the stable API for this once we have the outbox.

[How]
Add metadata struct to the end of the data firmware that describes
fw_state_size and some reserved area for future use.

Drop the tracebuffer and firmware state headers since they can differ
per version.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Use physical addressing for DMCUB on both dcn20/21

2019-12-18T21:09:07+00:00

[Why]
CW0 and CW1 need to use physical addressing mode for dcn20 and dcn21.

The current code for dcn20 is using virtual.

[How]
We already program the DMCUB like this on dcn21 so we should just use
the same sequence for both.

Copy the dcn21 sequences into the dmjub_dcn20.c file and rename them.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Get DMUB registers from ASIC specific structs

2019-12-18T21:09:07+00:00

[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 
Reviewed-by: Tony Cheng 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher