sdma2.4 is only for iceland. For Vi, we don't maintain the
direct fw loading.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Remove the warning message:
"-1 is not supported on VI"
the -1 is the default fw load type, mean auto.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Extract the function of fw loading out of powerplay.
Do fw loading between hw_init/resuem_phase1 and phase2
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We need to do some IPs earlier to deal with ordering issues
similar to how resume is split into two phases.

Will do fw loading via smu/psp between the two phases.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The variable clean is unnecessary.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

1. one is for create/free bo when init/fini
2. one is for fill the bo before fw loading

the ucode bo only need to be created when load driver
and free when driver unload.

when resume/reset, driver only need to re-fill the bo
if the bo is allocated in vram.

Suggested by Christian.

v2: Return error when bo create failed.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fix cg/pg unexpected set in hw init failed case.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

1. only call late_init when hw_init successful,
   so check status.hw instand of status.valid in late_init.
2. set status.late_initialized true if late_init was not implemented.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

initialize gfx/sdma before dpm features enabled.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

initialize gfx/sdma before dpm features enabled.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For the vram_start is 0 case, the gart range will be from 0x0000FFFF00000000
to 0x0000FFFF1FFFFFFF, which will cause the engine hang.

So to avoid the hole, limit the max mc address to AMDGPU_GMC_HOLE_START.:wq
Signed-off-by: NEmily Deng <Emily.Deng@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fix CPDMA hang in PRT mode, set CPF_INT_DMA in reg CP_MECx_F32_INT_DIS for Compute and set DISABLE_GFX_HALT_ON_UTCL1_ERROR in reg CP_DEBUG for GFX

Affected ASICs: Vega10 Vega12 Raven
Signed-off-by: NTao Zhou <tao.zhou1@amd.com>
Tested-by: NYukun.Li <yukun1.li@amd.com>
Tested-by: NMaciej.Jesionowski <maciej.jesionowski@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add CP_DEBUG register definition.
Signed-off-by: NTao Zhou <tao.zhou1@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

RV2 resource is limit to 3 pipes. Limitation should apply to all HW
blocks instead of front pipe.
Signed-off-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Wrong index for pstate debug test register

[How]
Add correct index value for dcn1_01 in hubbub1_construct()
Signed-off-by: NHersen Wu <hersenxs.wu@amd.com>
Signed-off-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

initialize gfx/sdma before dpm features enabled.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

gfx and sdma can be initialized before smu.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

with this interface, gfx/sdma can be initialized
before smu.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

ucode bo is needed by request_smu_load_fw,
the request_smu_load_fw maybe called by gfx/sdma
before smu hw init.
so move amdgpu_ucode_bo_init to request_smu_lowd_fw
from smu hw init.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

driver don't release the ucode memory when suspend. so don't
need to allocate bo when resume back.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

AMDGPU_FW_LOAD_DIRECT is used for bring up.
Now it don't work any more. so remove the support.

v2: Add warning message if user select
   AMDGPU_FW_LOAD_DIRECT/AMDGPU_FW_LOAD_PSP on VI.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Correct VCN cache window definition. The old one
is reused from UVD, and it is not fully correct.
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Acked-by: NLeo Liu <leo.liu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Replace value with defined macro to make
code more readable
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Acked-by: NLeo Liu <leo.liu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use mmUVD_SCRATCH2 tracking decode write point.
It will help avoid dpg pause mode hang issue.
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Acked-by: NLeo Liu <leo.liu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The following WREG32_SOC15_DPG_MODE will overwrite register
mmUVD_CGC_CTRL. This code can be removed.
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NLeo Liu <leo.liu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

So a few days ago I started getting sprays of these warnings --
sorry, but because it was a few days ago I'm not sure what I was
running at the time (but it was probably either Stellaris or Chromium).

Sep 25 22:06:34 mutilate err: : [  544.718905] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc
Sep 25 22:06:34 mutilate err: : [  544.718909] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
Sep 25 22:06:34 mutilate err: : [  544.719710] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc
Sep 25 22:06:34 mutilate err: : [  544.719714] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
Sep 25 22:06:34 mutilate err: : [  544.719862] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc
Sep 25 22:06:34 mutilate err: : [  544.719865] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
Sep 25 22:06:34 mutilate err: : [  544.720772] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc
Sep 25 22:06:34 mutilate err: : [  544.720778] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
Sep 25 22:06:34 mutilate warning: : [  544.721415] radeon 0000:01:00.0: vbo resource seems too big for the bo

followed by a massive stream of "vbo resource seems too big for the bo".

The most extreme flood ran from 23:01:58 to 23:02:47 and emitted 91,000
lines of log in that time.  This... seems excessive, given that each log
message after the first contains more or less no information.

So ratelimit these messages. (We probably want to see at least *some* so
that the underlying bug can be fixed -- always assuming the bug isn't in
unfixable closed-source game code somewhere.)
Signed-off-by: NNick Alcock <nick.alcock@oracle.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Adding a second irq source because of a different src_id is actually a
bug.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

That also simplifies handling quite a bit.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
1. we never submit IBs to the KIQ
2. there seems to be ~500ms delay during amdgpu resume spent in KIQ,
   hence pointing toward interrupts are not working correctly.

[How]
remove interrupt handling for KIQ.
Signed-off-by: NShirish S <shirish.s@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>i
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This mm_struct pointer should never be dereferenced. If running in
a user thread, just use current->mm. If running in a kernel worker
use get_task_mm to get a safe reference to the mm_struct.
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
1. We never submit IBs to KIQ.
2. Ring test pass without KIQ's ring also.
3. By skipping we see an improvement of around 500ms
   in the amdgpu's resume time.

[How]
skip IB tests for KIQ ring type.
Signed-off-by: NShirish S <shirish.s@amd.com>
Signed-off-by: NPratik Vishwakarma <Pratik.Vishwakarma@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Clang generates a warning when it sees a logical not followed by a
conditional operator like ==, >, or <.

drivers/gpu/drm/scheduler/sched_entity.c:470:6: warning: logical not is
only applied to the left hand side of this comparison
[-Wlogical-not-parentheses]
        if (!spsc_queue_count(&entity->job_queue) == 0 ||
            ^                                     ~~
drivers/gpu/drm/scheduler/sched_entity.c:470:6: note: add parentheses
after the '!' to evaluate the comparison first
        if (!spsc_queue_count(&entity->job_queue) == 0 ||
            ^
             (                                        )
drivers/gpu/drm/scheduler/sched_entity.c:470:6: note: add parentheses
around left hand side expression to silence this warning
        if (!spsc_queue_count(&entity->job_queue) == 0 ||
            ^
            (                                    )
1 warning generated.

It assumes the author might have made a mistake in their logic:

if (!a == b) -> if (!(a == b))

Sometimes that is the case; other times, it's just a super convoluted
way of saying 'if (a)' when b = 0:

if (!1 == 0) -> if (0 == 0) -> if (true)

Alternatively:

if (!1 == 0) -> if (!!1) -> if (1)

Simplify this comparison so that Clang doesn't complain.

Fixes: 35e160e7 ("drm/scheduler: change entities rq even earlier")
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The request_smu_load_fw of VI is used to load gfx/sdma
ip's firmware.

Check whether the gfx/sdma firmware have been loaded successfully
in this callback function.
if failed, driver can exit to avoid gpu hard hung.
if successful, clean the flag reload_fw to avoid duplicated fw load.
when suspend/resume, driver need to reload fw.
so in suspend, reset the reload_fw flag to true to enable load fw when
resume.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

need to know SoftRegsStart value to visit the register
UcodeLoadStatus to check fw loading state.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

if upload firmware failed, no matter how many times
the function runs again, the same error will be encountered.
so remove the duplicated code.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Move in_suspend flag to adev from gfx, so
can be used in other ip blocks, also keep
consistent with gpu_in_reset flag.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

On CI/AI, fw was not loaded by smu, but
smu's fw still need to be released
when driver fini.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

the struct was not in use any more.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

don't need to set fan1_enable to read fan sensors.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Following lm-sensors 3.0.0,
Only enable pwm1 sysfs when fan control mode(pwm1_enable)
in manual
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>