Entity init should after ring init, as the entity's sched_rq's initialization
is in ring init.

SWDEV-161495
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>

Setup psp firmware loading for VCN, and make VCN block
booting from tmr mac address.
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Add VCN support in PSP driver
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Add the new firmware id for VCN into the enum
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Update tmr mc address with firmware loading address
which is returned from PSP firmware
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

amdgpu IP blocks booting need Trust Memory Region(tmr) mc address
of its firmware which is loaded by PSP
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NLikun Gao <likun.gao@amd.com>
Signed-off-by: NLikun Gao <Likun.Gao@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Extend the timeout for recovering vram bos from shadows on sr-iov
to cover the worst case scenario for timeslices and VFs

Under runtime, the wait fence time could be quite long when
other VFs are in exclusive mode. For example, for 4 VF, every
VF's exclusive timeout time is set to 3s, then the worst case is
9s. If the VF number is more than 4,then the worst case time will
be longer.
The 8s is the test data, with setting to 8s, it will pass the TDR
test for 1000 times.

SWDEV-161490
Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
Signed-off-by: NEmily Deng <Emily.Deng@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We no longer have sched parameter so remove its description
as well
Signed-off-by: NNayan Deshmukh <nayan26deshmukh@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The serializer PLL divider is a power-of-two divider, so our calculation
which assumes that it's a numerical divider is incorrect.  Replace it
with one that results in a power-of-two divider value instead.

Tested with all supported modes with a Samsung S24C750.
Tested-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

We can achieve the same effect via the get_modes() method, rather than
wrapping the fill_modes helper.
Tested-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Move the mode_valid() implementation to the bridge instead of the
connector, as we're checking the bridge's capabilities.
Tested-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Register the bridge outside of the component helper as we have
drivers that wish to use the tda998x without its encoder.
Tested-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Cleanup the code a little from the effects of the previous changes:
- Move tda998x_destroy() to be above tda998x_create()
- Use 'dev' directly in tda998x_create() where appropriate.
Tested-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Move the tda998x_priv allocation inside tda998x_create() and simplify
the tda998x_create()'s arguments.  Pass the same to tda998x_destroy().
Tested-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Convert tda998x to a bridge driver with built-in encoder support for
compatibility with existing component drivers.
Tested-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

drm_sched_job_finish() is a work item scheduled for each finished job on
a unbound system workqueue. This means the workers can execute out of order
with regard to the real hardware job completions.

If this happens queueing a timeout worker for the first job on the ring
mirror list is wrong, as this may be a job which has already finished
executing. Fix this by reorganizing the code to always queue the worker
for the next job on the list, if this job hasn't finished yet. This is
robust against a potential reordering of the finish workers.

Also move out the timeout worker cancelling, so that we don't need to
take the job list lock twice. As a small optimization list_del is used
to remove the job from the ring mirror list, as there is no need to
reinit the list head in the job we are about to free.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
for vega, dp set_panel_mode is
handled by psp firmware. dal should not program the
register again.

[how]
dal does not program panel mode.
Signed-off-by: NHersen Wu <hersenxs.wu@amd.com>
Reviewed-by: NCharlene Liu <Charlene.Liu@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
When programming tonga's connector's backend we didn't take
in account that HDMI's colour depth might be more than 8bpc
therefore we need to add a switch statement that would adjust
the pixel clock accordingly.

[how]
Add a switch statement updating clock by its appropriate
coefficient.
Signed-off-by: NMikita Lipski <mikita.lipski@amd.com>
Reviewed-by: NCharlene Liu <Charlene.Liu@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

[Why]
We seem to have an issue where high enough display clock
will not get set properly during S3 resume if we only
call vbios once

[How]
Expand condition of display clock programming to happen
even when cached display clock matches requested display
clock
Signed-off-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

The pointer for integrated_info can be NULL which causes the system to
do a null pointer deference and hang on boot.

[How]

Add a check to ensure that integrated_info is not null before enabling
DP ss.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@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: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
Prevent clock source sharing between HDMI and DP connectors.
DP shouldn't be sharing its ref clock with phy clock,
which caused an issue of older ASICS booting up with multiple
diplays plugged in.

[how]
Add an extra check that would prevent HDMI and DP sharing clk.
Signed-off-by: NMikita Lipski <mikita.lipski@amd.com>
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

[why] dp hbr2 eye diagram pattern for raven asic is not stabled.
workaround is to use tp4 pattern. But this should not be
applied to asic before raven.

[how] add new bool varilable in asic caps. for raven asic,
use the workaround. for carrizo, vega, do not use workaround.
Signed-off-by: NHersen Wu <hersenxs.wu@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

The calculated values for actual disp_clk_khz were ignored when
notifying pplib of the new display requirements. In order to honor DFS
bypass clocks from the hardware, the calculated value should be used.

[How]

The return value for set_dispclk is now assigned back into new_clocks
and correctly carried through into dccg->clks.phyclk_khz. When notifying
pplib of new display requirements dccg->clks.phyclk_khz is used
instead of dce.dispclk_khz. The value of dce.dispclk_khz was never
explicitly set to anything before.

A 15% higher display clock value than calculated is no longer requested
for dce110 since it now makes use of the calculated value.

Since dce112 makes use of dce110's set_bandwidth but not its
update_clocks it needs to have the value correctly carried through.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Reviewed-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Custom degamma lut functions are a feature we would
like to support on compatible hardware

[How]
In atomic check, convert from array of drm_color_lut to
dc_transfer_func.  On hardware commit, allow for possibility
of custom degamma.  Both are based on the equivalent
regamma pipeline.
Signed-off-by: NDavid Francis <David.Francis@amd.com>
Reviewed-by: NKrunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
In the dce112 function to destroy the resource pool, engines
(the aux engines) is destroyed twice.  This has no ill effects
but is a tad redundant.

[How]
Remove the redundant call
Signed-off-by: NDavid Francis <David.Francis@amd.com>
Reviewed-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
If there is no program explicitly setting the backlight
brightness (for example, during a minimal install of linux), the
hardware defaults to maximum brightness but the backlight_device
defaults to 0 value.  Thus, settings displays the wrong brightness
value.

[How]
When creating the backlight device, set brightness to max
Signed-off-by: NDavid Francis <David.Francis@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
This hook that is supposed to read the actual backlight value
is used in a few places throughout the kernel to setup or force
update on backlight

[How]
Create a dc function that calls the existing abm function, and
call that function from amdgpu
Signed-off-by: NDavid Francis <David.Francis@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
400.1.1 is failing because we are not performing link training when
we get an HPD pulse for the same display. This is breaking DP
compliance

[How]
Always perform link training after HPD pulse if the detection
reason is not  DETECT_REASON_HPDRX.
Signed-off-by: Nabdoulaye berthe <abdoulaye.berthe@amd.com>
Reviewed-by: NWenjing Liu <Wenjing.Liu@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
The DRM mode's HDMI picture aspect ratio field was never saved in
dc_stream's timing struct. This causes us to mistake a new stream to
have the same timings as the old, even though the user has requested a
different aspect ratio.

[How]
Save DRM's aspect ratio field within dc_stream's timing struct.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107153Signed-off-by: NLeo (Sunpeng) Li <sunpeng.li@amd.com>
Reviewed-by: NMikita Lipski <Mikita.Lipski@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality:
commit 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages")

And yet, part of it was reintroduced in:
commit 39b4cbad ("drm/i915/kvmgt: Check the pfn got from vfio_pin_pages")

Causing kvmgt part to no longer build. Let's remove it.
Reported-by: NTomasz Lis <tomasz.lis@intel.com>
Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
Cc: Changbin Du <changbin.du@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712155330.32055-1-michal.winiarski@intel.com
(cherry picked from commit 4eaf317a60fbea0555b936035002ca9bd9b9105d)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The LPE audio is a child device of i915, it is powered up and down
alongside the igfx and presents no independent runtime interface. This
aptly fulfils the description of a "No-Callback" Device, so mark it
thus.

Fixes: 183c0035 ("drm/i915: Fix runtime PM for LPE audio")
Testcase: igt/pm_rpm/basic-pci-d3-state
Testcase: igt/pm_rpm/basic-rte
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802140416.6062-1-chris@chris-wilson.co.uk
(cherry picked from commit 46e831abe864a6b59fa3de253a681c0f2ee1bf2f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The register for 0xe420 is unable to hold any value, including
this bit. The documentation is also mixed between having a
register bit for toggle and having a state command setup
for it. Apparently the register toggle is deprecated.

Remove the register toggle as evidence shows it's futile.

The thing remaining is an apology and humble request for
Mesa folks to resurrect their state setup for this as they
were on right track from start.

This reverts commit 0bf059f3.

Fixes: 0bf059f3 ("drm/i915/icl: WaEnableFloatBlendOptimization")
References: HSDES#1406393558
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180730120636.26958-1-mika.kuoppala@linux.intel.com
(cherry picked from commit c358514ba8da9e235876db1628cedd19a35803c6)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

RPS provides a feedback loop where we use the load during the previous
evaluation interval to decide whether to up or down clock the GPU
frequency. Our responsiveness is split into 3 regimes, a high and low
plateau with the intent to keep the gpu clocked high to cover occasional
stalls under high load, and low despite occasional glitches under steady
low load, and inbetween. However, we run into situations like kodi where
we want to stay at low power (video decoding is done efficiently
inside the fixed function HW and doesn't need high clocks even for high
bitrate streams), but just occasionally the pipeline is more complex
than a video decode and we need a smidgen of extra GPU power to present
on time. In the high power regime, we sample at sub frame intervals with
a bias to upclocking, and conversely at low power we sample over a few
frames worth to provide what we consider to be the right levels of
responsiveness respectively. At low power, we more or less expect to be
kicked out to high power at the start of a busy sequence by waitboosting.

Prior to commit e9af4ea2 ("drm/i915: Avoid waitboosting on the active
request") whenever we missed the frame or stalled, we would immediate go
full throttle and upclock the GPU to max. But in commit e9af4ea2, we
relaxed the waitboosting to only apply if the pipeline was deep to avoid
over-committing resources for a near miss. Sadly though, a near miss is
still a miss, and perceptible as jitter in the frame delivery.

To try and prevent the near miss before having to resort to boosting
after the fact, we use the pageflip queue as an indication that we are
in an "interactive" regime and so should sample the load more frequently
to provide power before the frame misses it vblank. This will make us
more favorable to providing a small power increase (one or two bins) as
required rather than going all the way to maximum and then having to
work back down again. (We still keep the waitboosting mechanism around
just in case a dramatic change in system load requires urgent uplocking,
faster than we can provide in a few evaluation intervals.)

v2: Reduce rps_set_interactive to a boolean parameter to avoid the
confusion of what if they wanted a new power mode after pinning to a
different mode (which to choose?)
v3: Only reprogram RPS while the GT is awake, it will be set when we
wake the GT, and while off warns about being used outside of rpm.
v4: Fix deferred application of interactive mode
v5: s/state/interactive/
v6: Group the mutex with its principle in a substruct

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111
Fixes: e9af4ea2 ("drm/i915: Avoid waitboosting on the active request")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk
(cherry picked from commit 60548c554be2830d29d2533dad0ac8133347ee51)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

First of all don't try to read dpcd if PSR is not even supported.

But also, if read failed return -EIO instead of reporting via a
backchannel.

v2: fix dev_priv: At this level m->private is the connector. (CI/DK)
    don't convert dpcd read errors to EIO. (DK)

Fixes: 5b7b3086 ("drm/i915/psr: Split sink status into a separate debugfs node")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180720003155.16290-1-rodrigo.vivi@intel.com
(cherry picked from commit 7a72c78bdd0a1ea1d879610542679cc680398220)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

When the suballocator was unable to provide a suitable buffer for the MMUv1
linear window, we roll back the GPU initialization. As the GPU is runtime
resumed at that point we need to clear the kernel cmdbuf suballoc entry to
properly skip any attempt to manipulate the cmdbuf when the GPU gets shut
down in the runtime suspend later on.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

Ref- commit 1c8f4220 ("mm: change return type to vm_fault_t")

Previously vm_insert_page() returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_page() will replace this inefficiency by
returning VM_FAULT_* type.

vmf_error() is the newly introduce inline function
in 4.17-rc6.
Signed-off-by: NSouptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: NMatthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

The documentation of drm_sched_job_init and drm_sched_entity_push_job has
been clarified. Both functions should be called under a shared lock, to
avoid jobs getting pushed into the scheduler queue in a different order
than their sched_fence seqnos, which will confuse checks that are looking
at the seqnos to infer information about completion order.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

Replace the open-coded scratch page initialization loop with memset32
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

[Why]
VGA sometimes has trouble retrieving the EDID on very long cables, KVM
switches, or old displays.

[How]
Only require EDID read for HDMI and DVI and exempt other types (DP,
VGA). We currently don't support VGA but if anyone adds support in the
future this might get overlooked.
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Suggested-by: NMichel Dänzer <michel@daenzer.net>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>