Enabling panfrost GPU OPP with dynamic regulator will make OPP
responsible to enable and configure it.

Unfortunately OPP configure and enable the regulator when an OPP
is asked to be set, which is not the case during
panfrost_devfreq_init().

This leave the regulator unconfigured and if no GPU load is
triggered, no OPP is asked to be set which make the regulator framework
switching it off during regulator_late_cleanup() without
noticing and therefore make the board hang as any access to GPU
memory space make bus locks up.

Call dev_pm_opp_set_opp() with the recommend OPP in
panfrost_devfreq_init() to enable the regulator, this will properly
configure and enable the regulator and will avoid any switch off
by regulator_late_cleanup().
Suggested-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NClément Péron <peron.clem@gmail.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NSteven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220906153034.153321-5-peron.clem@gmail.com

Otherwise lockdep will complain about cleaning up the bulk_move.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220907100051.570641-1-christian.koenig@amd.com
Fixes: d91c411c ("drm/ttm: update bulk move object of ghost BO")

It's missed in psp fini.
Signed-off-by: NGuchun Chen <guchun.chen@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

current function mixes CSDMA_DOORBELL_RANGE and SDMA0_DOORBELL_RANGE
range/size manipulation, while these 2 registers have difference size
field mask. Remove range/size manipulation for SDMA0_DOORBELL_RANGE.
Signed-off-by: NYifan Zhang <yifan1.zhang@amd.com>
Reviewed-by: NXiaojian Du <Xiaojian.Du@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Addresses should be printed in hex format.
Signed-off-by: NYifan Zhang <yifan1.zhang@amd.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time.  Fix this up by properly
calling dput().

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: hersen wu <hersenxs.wu@amd.com>
Cc: Wenjing Liu <wenjing.liu@amd.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Thelford Williams <tdwilliamsiv@gmail.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Yongzhi Liu <lyz_cs@pku.edu.cn>
Cc: Mikita Lipski <mikita.lipski@amd.com>
Cc: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Cc: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: stable@vger.kernel.org
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Missing SetMGpuFanBoostLimitRpm mapping leads to loading failure for SMU
13.0.7.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add missing structure to avoid incorrect size and version check.
Signed-off-by: NChengming Gui <Jack.Gui@amd.com>
Reviewed-by: NFeifei Xu <Feifei.Xu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Just move the HAS_FLAT_CCS() check into needs_ccs_pages. This also then
fixes i915_ttm_memcpy_allowed() which was incorrectly reporting true on
DG1, even though it doesn't have small-BAR or flat-CCS.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6605
Fixes: efeb3caf ("drm/i915/ttm: disallow CPU fallback mode for ccs pages")
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: NNirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220905105329.41455-1-matthew.auld@intel.com
(cherry picked from commit 873fef88)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

A lot of modern laptops use the Parade PS8461E MUX for eDP
switching. The MUX can operate in jitter cleaning mode or
redriver mode, the first one resulting in higher link
quality. The jitter cleaning mode needs to know the link
rate used and the MUX achieves this by snooping the
LINK_BW_SET, LINK_RATE_SELECT and SUPPORTED_LINK_RATES
DPCD accesses.

When the MUX is powered down (seems this can happen whenever
the display is turned off) it loses track of the snooped
link rates so when we do the LINK_RATE_SELECT write it no
longer knowns which link rate we're selecting, and thus it
falls back to the lower quality redriver mode. This results
in unstable high link rates (eg. usually 8.1Gbps link rate
no longer works correctly).

In order to avoid all that let's re-snoop SUPPORTED_LINK_RATES
from the sink at the start of every link training.

Unfortunately we don't have a way to detect the presence of
the MUX. It looks like the set of laptops equipped with this
MUX is fairly large and contains devices from multiple
manufacturers. It may also still be growing with new models.
So a quirk doesn't seem like a very easily maintainable
option, thus we shall attempt to do this unconditionally on
all machines that use LINK_RATE_SELECT. Hopefully this extra
DPCD read doesn't cause issues for any unaffected machine.
If that turns out to be the case we'll need to convert this
into a quirk in the future.

Cc: stable@vger.kernel.org
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220902070319.15395-1-ville.syrjala@linux.intel.comTested-by: NAaron Ma <aaron.ma@canonical.com>
Tested-by: NJason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
(cherry picked from commit 25899c59)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

We need to inform PCODE of a desired ring frequencies so PCODE update
the memory frequencies to us. rps->min_freq and rps->max_freq are the
frequencies used in that request. However they were unset when SLPC was
enabled and PCODE never updated the memory freq.

v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right
   frequencies from the get_ia_constants instead of the fake init of
   rps' min and max.

v3: don't forget the max <= min return

v4: Move all the freq conversion to intel_rps.c. And the max <= min
    check to where it belongs.

v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining
    the "raw format"

Fixes: 7ba79a67 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled")
Cc: <stable@vger.kernel.org> # v5.15+
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Tested-by: NSushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220831214538.143950-1-rodrigo.vivi@intel.com
(cherry picked from commit 018a7bdb)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Turns out the MIPI sequence block version number and
new block size fields are considered part of the block
header and are not included in the reported new block size
field itself. Bump up the block size appropriately so that
we'll copy over the last five bytes of the block as well.

For this particular machine those last five bytes included
parts of the GPIO op for the backlight on sequence, causing
the backlight no longer to turn back on:

 		Sequence 6 - MIPI_SEQ_BACKLIGHT_ON
 			Delay: 20000 us
-			GPIO index 0, number 0, set 0 (0x00)
+			GPIO index 1, number 70, set 1 (0x01)

Cc: stable@vger.kernel.org
Fixes: e163cfb4 ("drm/i915/bios: Make copies of VBT data blocks")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6652Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220829135834.8585-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
(cherry picked from commit a06289f3)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

[Why]
Ghost BO is released with non-empty bulk move object. There is a
warning trace:
WARNING: CPU: 19 PID: 1582 at ttm/ttm_bo.c:366 ttm_bo_release+0x2e1/0x2f0 [amdttm]
Call Trace:
  amddma_resv_reserve_fences+0x10d/0x1f0 [amdkcl]
  amdttm_bo_put+0x28/0x30 [amdttm]
  amdttm_bo_move_accel_cleanup+0x126/0x200 [amdttm]
  amdgpu_bo_move+0x1a8/0x770 [amdgpu]
  ttm_bo_handle_move_mem+0xb0/0x140 [amdttm]
  amdttm_bo_validate+0xbf/0x100 [amdttm]

[How]
The resource of ghost BO should be moved to LRU directly, instead of
using bulk move. The bulk move object of ghost BO should set to NULL
before function ttm_bo_move_to_lru_tail_unlocked.

v2: set bulk move to NULL manually if no resource associated with ghost BO

Fixed: 5b951e487fd6bf5f ("drm/ttm: fix bulk move handling v2")
Signed-off-by: NZhenGuo Yin <zhenguo.yin@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220906084619.2545456-1-zhenguo.yin@amd.com

EDID 1.4 introduced some extra flags in the range
descriptor to support min/max h/vfreq >= 255. Consult them
to correctly parse the vfreq limits.

Note that some combinations of the flags are documented
as "reserved" (as are some other values in the descriptor)
but explicitly checking for those doesn't seem particularly
worthwile since we end up with bogus results whether we
decode them or not.

v2: Increase the storage to u16 to make it work (Jani)
    Note the "reserved" values situation (Jani)
v3: Document the EDID version number in the defines
    Drop some bogus (u8) casts

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6519
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6484Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220826213501.31490-2-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

Restrict the ucode loading check to avoid frontdoor loading error.
Signed-off-by: NChengming Gui <Jack.Gui@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Not all the gfx10 variants need to integrate
global tap_delay and per se tap_delay firmwares

Only init tap_delay ucode when it does include in
rlc ucode binary so driver doesn't send a null buffer
to psp for firmware loading
Signed-off-by: NHawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: NJack Gui <Jack.Gui@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
On secondary display hotplug we switch primary
stream from ODM2to1 to ODMBypass mode. Current
logic will trigger disabling front end for this
stream.

[How]
We need to check if prev_odm_pipe is equal to NULL
in order to disable dangling planes in this scenario.
Reviewed-by: NAriel Bernstein <Eric.Bernstein@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NVladimir Stempen <vladimir.stempen@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[WHY]
Function wasn't returning false when it had a no stream

[HOW]
Made it return false when it had no stream.
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NEthan Wellenreiter <Ethan.Wellenreiter@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Pipes get merged in preparation for SubVP but if they don't get used, and
are in ODM or some other multi pipe config, it would calculate the
voltage level with a viewport of just one pipe from when they were split
resulting in too low of a voltage level.

[How]
Made it so that the viewport and other timing settings get rebuilt and re-
initialized after the pipe merge, before calculating the voltage level so it
would calculate it correctly.
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NEthan Wellenreiter <Ethan.Wellenreiter@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
plane and stream variables used for cursor size allocation calculation
were stale from previous iteration. Redo the iteration to find the
correct cursor plane for the calculation.
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why] Devices with CPU XGMI iolink do not support PCIe peer access.
Signed-off-by: NAlex Sierra <alex.sierra@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

To suppress the warning about version mismatch with
the latest 78.54.0 PMFW.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NKenneth Feng <kenneth.feng@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For those SMU13.0.7 unsecure SKUs, the vbios carried pptable is ready to go.
Use that one instead of hardcoded softpptable.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NKenneth Feng <kenneth.feng@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For some SMU13.0.0 SKUs, the vbios carried pptable is ready to go.
Use that one instead of hardcoded softpptable.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NKenneth Feng <kenneth.feng@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
fw version check was for release branch.
for staging, it has a chance to enter wrong code path.
Reviewed-by: NHansen Dsouza <hansen.dsouza@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NCharlene Liu <Charlene.Liu@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
When calculating allocation for cursor size, get the real cursor through
the HUBP instead of using the maximum cursor size for more optimal
allocation
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
When using a 4k monitor when cursor caching is not supported due to
framebuffer being on an uncacheable address, enabling display refresh
from MALL would trigger corruption if SS is enabled.

Prevent entering SS if we are on the edge case and cursor caching is not
possible. Do this only if cursor size larger than a 64x64@4bpp. Pull the
cursor size calculation out of if condition since cursor address may not
be set on all platforms
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For calculating cursor size allocation, surface size was used, resulting
in over allocation
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why & How]
Number of encoder is set to 4 but only 3 instances are created.
Reviewed-by: NCharlene Liu <Charlene.Liu@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NLeo Chen <sancchen@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
DIG_FIFO_ERROR = 1 caused mst daisy chain 2nd monitor black.

[How]
We need to set dig fifo read start level = 7 before dig fifo reset during dig
fifo enable according to hardware designer's suggestion. If it is zero, it will
cause underflow or overflow and DIG_FIFO_ERROR = 1.
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NWang Fudong <Fudong.Wang@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
In amdgpu_cs_ioctl, amdgpu_job_free could be performed ealier if there
is -ERESTARTSYS error. In this case, job->hw_fence could be not
initialized yet. Putting hw_fence during amdgpu_job_free could lead to a
use-after-free warning.

[How]
Check if drm_sched_job_init is performed before job_free by checking
s_fence.

v2: Check hw_fence.ops instead since it could be NULL if fence is not
initialized. Reverse the condition since !=NULL check is discouraged in
kernel.
Signed-off-by: NYuBiao Wang <YuBiao.Wang@amd.com>
Reviewed-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
When ODM is enabled, H timing control register reset
to 0. Div mode manual field get overwritten causing
no display on certain modes for dcn314.

[How]
Use REG_UPDATE instead of REG_SET to set div_mode
field.
Reviewed-by: NCharlene Liu <Charlene.Liu@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NDuncan Ma <duncan.ma@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Each index in the DPSTREAMCLK_CNTL register
phyiscally maps 1-to-1 with HPO stream encoder
instance. On the other hand, each index in
DTBCLK_P_CNTL physically maps 1-to-1 with OTG
instance.

Current DCN32 DPSTREAMCLK_CLK programing assumes
that OTG instance always maps 1-to-1 with
HPO stream encoder instance. This is not always
guaranteed and can result in blackscreen.

[How]
Program the correct dpstreamclk instance with
the correct dtbclk_p source.
Reviewed-by: NAriel Bernstein <Eric.Bernstein@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NGeorge Shen <george.shen@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

New GFX11 MES FW adds the trap_en bit. For now hardcode to 1 (traps
enabled).
Signed-off-by: NGraham Sider <Graham.Sider@amd.com>
Acked-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: NHarish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Below driver load error will be printed, not friendly to end user.

amdgpu: ATOM BIOS: 113-D603GLXE-077
[drm] FRU: Failed to get size field
[drm:amdgpu_fru_get_product_info [amdgpu]] *ERROR* Failed to read FRU Manufacturer, ret:-5
Signed-off-by: NGuchun Chen <guchun.chen@amd.com>
Reviewed-by: NKent Russell <kent.russell@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The stuff programmed into the wm/ddb registers of planes
on disabled pipes doesn't matter. So during readout just
leave our software state tracking for those zeroed.

This should avoid us trying too hard to clean up after
whatever mess the VBIOS/GOP left in there. The actual
hardware state will get cleaned up if/when we enable
the pipe anyway.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5711Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220617195948.24007-1-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
(cherry picked from commit b183db8f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The quirk added in upstream commit 90c3e219 ("drm/i915/glk: Add
Quirk for GLK NUC HDMI port issues.") is also required on the ECS Liva
Q2.

Note: Would be nicer to figure out the extra delay required for the
retimer without quirks, however don't know how to check for that.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1326Signed-off-by: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220616124137.3184371-1-jani.nikula@intel.com
(cherry picked from commit 08e9505f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
The root cause is null pointer defeference of bi_next
in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.

BUG: kernel NULL pointer dereference, address: 000000000000002e
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G     U            5.17.0-rc1
Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021
RIP: 0010:tgl_get_bw_info+0x2de/0x510
...
[    2.554467] Call Trace:
[    2.554467]  <TASK>
[    2.554467]  intel_bw_init_hw+0x14a/0x434
[    2.554467]  ? _printk+0x59/0x73
[    2.554467]  ? _dev_err+0x77/0x91
[    2.554467]  i915_driver_hw_probe+0x329/0x33e
[    2.554467]  i915_driver_probe+0x4c8/0x638
[    2.554467]  i915_pci_probe+0xf8/0x14e
[    2.554467]  ? _raw_spin_unlock_irqrestore+0x12/0x2c
[    2.554467]  pci_device_probe+0xaa/0x142
[    2.554467]  really_probe+0x13f/0x2f4
[    2.554467]  __driver_probe_device+0x9e/0xd3
[    2.554467]  driver_probe_device+0x24/0x7c
[    2.554467]  __driver_attach+0xba/0xcf
[    2.554467]  ? driver_attach+0x1f/0x1f
[    2.554467]  bus_for_each_dev+0x8c/0xc0
[    2.554467]  bus_add_driver+0x11b/0x1f7
[    2.554467]  driver_register+0x60/0xea
[    2.554467]  ? mipi_dsi_bus_init+0x16/0x16
[    2.554467]  i915_init+0x2c/0xb9
[    2.554467]  ? mipi_dsi_bus_init+0x16/0x16
[    2.554467]  do_one_initcall+0x12e/0x2b3
[    2.554467]  do_initcall_level+0xd6/0xf3
[    2.554467]  do_initcalls+0x4e/0x79
[    2.554467]  kernel_init_freeable+0xed/0x14d
[    2.554467]  ? rest_init+0xc1/0xc1
[    2.554467]  kernel_init+0x1a/0x120
[    2.554467]  ret_from_fork+0x1f/0x30
[    2.554467]  </TASK>
...
Kernel panic - not syncing: Fatal exception

Fixes: c64a9a7c ("drm/i915: Update memory bandwidth formulae")
Signed-off-by: NŁukasz Bartosik <lb@semihalf.com>
Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220201153354.11971-1-lukasz.bartosik@semihalf.com
(cherry picked from commit c247cd03)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Pps power hook seems to be problematic for backlight controlled via
aux channel. Disable it for such cases.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3657
Cc: stable@vger.kernel.org
Signed-off-by: NJouni Högander <jouni.hogander@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220822140836.534432-1-jouni.hogander@intel.com
(cherry picked from commit 869e3bb7)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Commit 20f85ef8 ("drm/i915/backlight: use unique backlight device
names") added support for multiple backlight devices on dual panel
systems, but did so with error handling on -EEXIST from
backlight_device_register(). Unfortunately, that triggered a warning in
dmesg all the way down from sysfs_add_file_mode_ns() and
sysfs_warn_dup().

Instead of optimistically always attempting to register with the default
name ("intel_backlight", which we have to retain for backward
compatibility), check if a backlight device with the name exists first,
and, if so, use the card and connector based name.

v2: reworked on top of the patch commit 20f85ef8
("drm/i915/backlight: use unique backlight device names")
v3: fixed the ref count leak(Jani N)

Fixes: 20f85ef8 ("drm/i915/backlight: use unique backlight device names")
Signed-off-by: NArun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220808035750.3111046-1-arun.r.murthy@intel.com
(cherry picked from commit 4234ea30)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>