A recent bspec update removed the LPDDR4 single channel entry from the
buddy register table, but added a new four-channel entry.

Workaround 1409767108 hasn't been updated with any guidance for four
channel configurations, so we leave that alternate table unchanged for
now.

Bspec 49218
Fixes: 3fa01d64 ("drm/i915/tgl: Program BW_BUDDY registers during display init")
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200612204734.3674650-1-matthew.d.roper@intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit ecb40d08)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Avoid a GPF at

<1>[   20.177320] BUG: kernel NULL pointer dereference, address: 000000000000007c
<1>[   20.177322] #PF: supervisor read access in kernel mode
<1>[   20.177323] #PF: error_code(0x0000) - not-present page
<6>[   20.177324] PGD 0 P4D 0
<4>[   20.177327] Oops: 0000 [#1] PREEMPT SMP PTI
<4>[   20.177328] CPU: 1 PID: 944 Comm: debugfs_test Not tainted 5.8.0-rc7-CI-CI_DRM_8814+ #1
<4>[   20.177330] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018
<4>[   20.177372] RIP: 0010:i915_lpsp_capability_show+0x44/0xc0 [i915]
<4>[   20.177374] Code: 0f b6 81 ca 0d 00 00 3c 0b 74 77 76 19 3c 0c 75 44 83 7e 7c 01 7e 2f 48 c7 c6 d7 b9 47 a0 e8 43 df 06 e1 31 c0 c3 3c 09 72 2b <8b> 46 7c 85 c0 75 e6 8b 82 e4 00 00 00 89 c2 83 e2 fb 83 fa 0a 74
<4>[   20.177376] RSP: 0018:ffffc90000cebe38 EFLAGS: 00010246
<4>[   20.177377] RAX: 0000000000000009 RBX: ffff888267fe6a58 RCX: ffff888252d10000
<4>[   20.177378] RDX: ffff88824a9a4000 RSI: 0000000000000000 RDI: ffff888267fe6a30
<4>[   20.177379] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
<4>[   20.177380] R10: 0000000000000001 R11: 0000000000000000 R12: ffffc90000cebf08
<4>[   20.177381] R13: 00000000ffffffff R14: 0000000000000001 R15: ffff888267fe6a30
<4>[   20.177383] FS:  00007f6f9c6b5e40(0000) GS:ffff888276480000(0000) knlGS:0000000000000000
<4>[   20.177384] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[   20.177385] CR2: 000000000000007c CR3: 0000000255f04006 CR4: 00000000003606e0
<4>[   20.177386] Call Trace:
<4>[   20.177390]  seq_read+0xcb/0x420

which is presumably from having no encoder attached at that time.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2175
Fixes: 8806211f ("drm/i915: Add i915_lpsp_capability debugfs")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200729130912.30093-1-chris@chris-wilson.co.ukSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit a22b1a9b)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Since we use the module parameters stored inside the drm_i915_device
itself, we need to ensure the mock i915_device also sets up the right
defaults.

Fixes: 8a25c4be ("drm/i915/params: switch to device specific parameters")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200728150600.4509-1-chris@chris-wilson.co.ukSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit 98ef0674)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Rather than manually implement our own module reference counting for perf
pmu events, finally realise that there is a module parameter to struct
pmu for this very purpose.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716094643.31410-1-chris@chris-wilson.co.ukSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit 27e897be)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NJuergen Gross <jgross@suse.com>

Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://lore.kernel.org/r/20200813062113.11030-4-andr2000@gmail.comSigned-off-by: NJuergen Gross <jgross@suse.com>

The patch c575b7ee: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:

	drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
	warn: passing zero to 'ERR_CAST'

drivers/gpu/drm/xen/xen_drm_front_gem.c
   133  struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
   134                                                  size_t size)
   135  {
   136          struct xen_gem_object *xen_obj;
   137
   138          xen_obj = gem_create(dev, size);
   139          if (IS_ERR_OR_NULL(xen_obj))
   140                  return ERR_CAST(xen_obj);

Fix this and the rest of misused places with IS_ERR_OR_NULL in the
driver.

Fixes:  c575b7ee: "drm/xen-front: Add support for Xen PV display frontend"
Signed-off-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200813062113.11030-3-andr2000@gmail.comSigned-off-by: NJuergen Gross <jgross@suse.com>

After the cleanup of page fault accounting, gup does not need to pass
task_struct around any more.  Remove that parameter in the whole gup
stack.
Signed-off-by: NPeter Xu <peterx@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Reviewed-by: NJohn Hubbard <jhubbard@nvidia.com>
Link: http://lkml.kernel.org/r/20200707225021.200906-26-peterx@redhat.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 2ddef176.

As it turned out VMWGFX needs a much wider audit to fix this.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200811092400.188124-1-christian.koenig@amd.com

There is a spelling mistake in a DRM_ERROR message. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

There is a spelling mistake in a DRM_ERROR message. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

Same problem as in stdu, same fix.

Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset")
Acked-by: NCharmaine Lee <charmainel@vmware.com>
Reviewed-by: NZack Rusin <zackr@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

Same problem as in stdu, same fix.

Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset")
Acked-by: NCharmaine Lee <charmainel@vmware.com>
Reviewed-by: NZack Rusin <zackr@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

When converting to atomic the state reset was done by directly calling
the functions, and before the modeset object was fully initialized.
This means the various ->dev pointers weren't set up.

After

commit 51f644b4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jun 12 18:00:49 2020 +0200

    drm/atomic-helper: reset vblank on crtc reset

this started to oops because now we're trying to derefence
drm_crtc->dev. Fix this up by entirely switching over to
drm_mode_config_reset, called once everything is set up.

Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset")
Reported-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Tested-by: NRoland Scheidegger <sroland@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

These if statements are supposed to be true if we ended the
list_for_each_entry() loops without hitting a break statement but they
don't work.

In the first loop, we increment "i" after the "if (i == unit)" condition
so we don't necessarily know that "i" is not equal to unit at the end of
the loop.

In the second loop we exit when mode is not pointing to a valid
drm_display_mode struct so it doesn't make sense to check "mode->type".

Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

The "entry" pointer is an offset from the list head and it doesn't
point to a valid vmw_legacy_display_unit struct.  Presumably the
intent was to point to the last entry.

Also the "i++" wasn't used so I have removed that as well.

Fixes: d7e1958d ("drm/vmwgfx: Support older hardware.")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.

This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

Reproducing bug report here:
After hibernating and resuming, DPM is not enabled. This remains the case
even if you test hibernate using the steps here:
https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html

I debugged the problem, and figured out that in the file hardwaremanager.c,
in the function, phm_enable_dynamic_state_management(), the check
'if (!hwmgr->pp_one_vf && smum_is_dpm_running(hwmgr) && !amdgpu_passthrough(adev) && adev->in_suspend)'
returns true for the hibernate case, and false for the suspend case.

This means that for the hibernate case, the AMDGPU driver doesn't enable DPM
(even though it should) and simply returns from that function.
In the suspend case, it goes ahead and enables DPM, even though it doesn't need to.

I debugged further, and found out that in the case of suspend, for the
CIK/Hawaii GPUs, smum_is_dpm_running(hwmgr) returns false, while in the case of
hibernate, smum_is_dpm_running(hwmgr) returns true.

For CIK, the ci_is_dpm_running() function calls the ci_is_smc_ram_running() function,
which is ultimately used to determine if DPM is currently enabled or not,
and this seems to provide the wrong answer.

I've changed the ci_is_dpm_running() function to instead use the same method that
some other AMD GPU chips do (e.g Fiji), which seems to read the voltage controller.
I've tested on my R9 390 and it seems to work correctly for both suspend and
hibernate use cases, and has been stable so far.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208839Signed-off-by: NSandeep Raghuraman <sandy.8925@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

As VCN related dpm table setup needs VCN be in PG ungate state. Same logics
applies to JPEG.

V2: fix paste typo
V3: code cosmetic
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Tested-by: NMatt Coffin <mcoffin13@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add lock protections and avoid unnecessary actions
if the PG state is already the same as required.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Tested-by: NMatt Coffin <mcoffin13@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Swith default gpu reset method for sienna_cichlid to MODE1 reset.
Signed-off-by: NLikun Gao <Likun.Gao@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The i2c init/fini functions just register the i2c adapter.
There is no need to call them during hw init/fini.  They only
need to be called once per driver init/fini.  The previous
behavior broke runtime pm because we unregistered the i2c
adapter during suspend.
Tested-by: NTom St Denis <tom.stdenis@amd.com>
Reviewed-by: NKevin Wang <kevin1.wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
Display goes blank after driver installation.
Aux tuning parameters must be used for 2.x only.
Wrong dc_golden_table offset was used.

[How]
Implement a new enc3_hw_init function without VBIOS constants usage to
be called for 3.x
Calculate dc_golden_table offset using sum of
base dce_info offset and golden table offset
Signed-off-by: NIgor Kravchenko <Igor.Kravchenko@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
During SetPathMode and UpdatePlanes, the plane state can be null. We default
to linear swizzle mode when plane state is null. This resulted in bandwidth
validation failing when trying to set 8K60 mode (which previously passed validation
during rebuild timing list).

[How]
Change the default swizzle mode from linear to 4kb_s and update pitch accordingly.
Signed-off-by: NGeorge Shen <george.shen@amd.com>
Reviewed-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[How]
Use dc_is_hdmi_signal to determine signal type.
Signed-off-by: NJinZe.Xu <JinZe.Xu@amd.com>
Reviewed-by: NCharlene Liu <Charlene.Liu@amd.com>
Acked-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Sink OUI supported cap is not set so driver skips programming it.

[How]
Revert the change the skips OUI programming if the cap is not set
Signed-off-by: NAric Cyr <aric.cyr@amd.com>
Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com>
Acked-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
use correct logger context
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: NEric Bernstein <Eric.Bernstein@amd.com>
Acked-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
For ver.4.4 and higher VBIOS contains default setting table.

{How]
Read Golden Settings Table from VBIOS, apply Aux tuning parameters.
Signed-off-by: NIgor Kravchenko <Igor.Kravchenko@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NEric Bernstein <eric.bernstein@amd.com>
Reviewed-by: NChris Park <Chris.Park@amd.com>
Acked-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Enable GFXOFF for navy_flounder.
Signed-off-by: NJiansong Chen <Jiansong.Chen@amd.com>
Reviewed-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

1. For Navi12, CHIP_SIENNA_CICHLID, skip tmr load operation;
2. Check pointer before release firmware.

v2: use CHIP_SIENNA_CICHLID instead
v3: remove local "bool ret"; fix grammer issue
v4: use my name instead of "root"
v5: fix grammer issue and indent issue
Signed-off-by: NLiu ChengZhe <ChengZhe.Liu@amd.com>
Reviewed-by: NLuben Tuikov <luben.tuikov@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Assigning false to block->status.hw overwrites PSP's previous
hardware status, which causes the PSP to Resume operation after
hardware init.

Remove this assignment and let the PSP execute Resume operation
when it is told to.

v2: Remove the braces.
v3: Modify the description.
Signed-off-by: NLiu ChengZhe <ChengZhe.Liu@amd.com>
Reviewed-by: NLuben Tuikov <luben.tuikov@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Update GC golden setting for navy_flounder.
Signed-off-by: NJiansong Chen <Jiansong.Chen@amd.com>
Reviewed-by: NTao Zhou <tao.zhou1@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's in accordance with pmfw 65.5.0 for navy_flounder.
Signed-off-by: NJiansong Chen <Jiansong.Chen@amd.com>
Reviewed-by: NTao Zhou <tao.zhou1@amd.com>
Reviewed-by: NKenneth Feng <kenneth.feng@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It doesn't expose PPTable descriptor on APU platform. So max/min
temperature values cannot be got from APU platform.

v2: Stoney needs to skip crit temperature as well.
Signed-off-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NKevin Wang <kevin1.wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Test expects that we also read HPD_IRQ_VECTOR when checking for
symbol loss as well lane status.

[How]
Read bytes 0x200-0x205 instead of just 0x202-0x205
Signed-off-by: NAric Cyr <aric.cyr@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NEryk Brol <eryk.brol@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Feature requires synchronization of dig, pipe, and cursor locking
between driver and fw.

[How]
Set flag to force psr to use hw lock mgr.
Signed-off-by: NWyatt Wood <wyatt.wood@amd.com>
Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com>
Acked-by: NEryk Brol <eryk.brol@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
ramp_up_dispclk_with_dpp is to change dispclk, dppclk and dprefclk
according to bandwidth requirement. call stack: rv1_update_clocks -->
update_clocks --> dcn10_prepare_bandwidth / dcn10_optimize_bandwidth
--> prepare_bandwidth / optimize_bandwidth. before change dcn hw,
prepare_bandwidth will be called first to allow enough clock,
watermark for change, after end of dcn hw change, optimize_bandwidth
is executed to lower clock to save power for new dcn hw settings.

below is sequence of commit_planes_for_stream:
step 1: prepare_bandwidth - raise clock to have enough bandwidth
step 2: lock_doublebuffer_enable
step 3: pipe_control_lock(true) - make dchubp register change will
not take effect right way
step 4: apply_ctx_for_surface - program dchubp
step 5: pipe_control_lock(false) - dchubp register change take effect
step 6: optimize_bandwidth --> dc_post_update_surfaces_to_stream
for full_date, optimize clock to save power

at end of step 1, dcn clocks (dprefclk, dispclk, dppclk) may be
changed for new dchubp configuration. but real dcn hub dchubps are
still running with old configuration until end of step 5. this need
clocks settings at step 1 should not less than that before step 1.
this is checked by two conditions: 1. if (should_set_clock(safe_to_lower
, new_clocks->dispclk_khz, clk_mgr_base->clks.dispclk_khz) ||
new_clocks->dispclk_khz == clk_mgr_base->clks.dispclk_khz)
2. request_dpp_div = new_clocks->dispclk_khz > new_clocks->dppclk_khz

the second condition is based on new dchubp configuration. dppclk
for new dchubp may be different from dppclk before step 1.
for example, before step 1, dchubps are as below:
pipe 0: recout=(0,40,1920,980) viewport=(0,0,1920,979)
pipe 1: recout=(0,0,1920,1080) viewport=(0,0,1920,1080)
for dppclk for pipe0 need dppclk = dispclk

new dchubp pipe split configuration:
pipe 0: recout=(0,0,960,1080) viewport=(0,0,960,1080)
pipe 1: recout=(960,0,960,1080) viewport=(960,0,960,1080)
dppclk only needs dppclk = dispclk /2.

dispclk, dppclk are not lock by otg master lock. they take effect
after step 1. during this transition, dispclk are the same, but
dppclk is changed to half of previous clock for old dchubp
configuration between step 1 and step 6. This may cause p-state
warning intermittently.

[How]
for new_clocks->dispclk_khz == clk_mgr_base->clks.dispclk_khz, we
need make sure dppclk are not changed to less between step 1 and 6.
for new_clocks->dispclk_khz > clk_mgr_base->clks.dispclk_khz,
new display clock is raised, but we do not know ratio of
new_clocks->dispclk_khz and clk_mgr_base->clks.dispclk_khz,
new_clocks->dispclk_khz /2 does not guarantee equal or higher than
old dppclk. we could ignore power saving different between
dppclk = displck and dppclk = dispclk / 2 between step 1 and step 6.
as long as safe_to_lower = false, set dpclk = dispclk to simplify
condition check.

CC: Stable <stable@vger.kernel.org>
Signed-off-by: NHersen Wu <hersenxs.wu@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NEryk Brol <eryk.brol@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Each asic can optimize best based on its capabilities

[How]
Optimizing timing for a new pixel clock
Signed-off-by: NReza Amini <Reza.Amini@amd.com>
Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com>
Acked-by: NEryk Brol <eryk.brol@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>