Release notes:

1. Fixes for Register noclaims and few restore.

Fixes: c4cf059d ("drm/i915/dmc: Update DG2 DMC firmware to v2.07")
Signed-off-by: NGustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221124162123.16870-1-gustavo.sousa@intel.com
(cherry picked from commit 6ee66925)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The fence is only tracking if the HuC load is in progress or not and
doesn't distinguish between already loaded, not supported or disabled,
so we can always initialize it to completed, no matter the actual
support. We already do that for most platforms, but we skip it on
GTs that lack VCS engines (e.g. MTL root GT), so fix that. Note that the
cleanup is already unconditional.

While at it, move the init/fini to helper functions.

Fixes: 8e5f3782 ("drm/i915/huc: fix leak of debug object in huc load fence on driver unload")
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: NJohn Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123235417.1475709-1-daniele.ceraolospurio@intel.com
(cherry picked from commit 14347a9c)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

intel_dsi->ports contains bitmask of enabled ports and correspondingly
logic for selecting port for VBT packet sending must use port specific
bitmask when deciding appropriate port.

Fixes: 08c59dde ("drm/i915/dsi: fix VBT send packet port selection for ICL+")
Cc: stable@vger.kernel.org
Signed-off-by: NMikko Kovanen <mikko.kovanen@aavamobile.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/DBBPR09MB466592B16885D99ABBF2393A91119@DBBPR09MB4665.eurprd09.prod.outlook.com
(cherry picked from commit 8d58bb79)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

When (size != 0 || ptrs->lvds_ entries != 3), the program tries to
free() the ptrs. However, the ptrs is not created by calling kzmalloc(),
but is obtained by pointer offset operation.
This may lead to memory leaks or undefined behavior.

Fix this by replacing the arguments of kfree() with ptrs_block.

Fixes: a87d0a84 ("drm/i915/bios: Generate LFP data table pointers if the VBT lacks them")
Signed-off-by: NXia Fukun <xiafukun@huawei.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125063428.69486-1-xiafukun@huawei.com
(cherry picked from commit 7674cd0b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Users of intel_gt_retire_requests_timeout() expect 0 return value on
success.  However, we have no protection from passing back 0 potentially
returned by a call to dma_fence_wait_timeout() when it succedes right
after its timeout has expired.

Replace 0 with -ETIME before potentially using the timeout value as return
code, so -ETIME is returned if there are still some requests not retired
after timeout, 0 otherwise.

v3: Use conditional expression, more compact but also better reflecting
    intention standing behind the change.

v2: Move the added lines down so flush_submission() is not affected.

Fixes: f33a8a51 ("drm/i915: Merge wait_for_timelines with retire_request")
Signed-off-by: NJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Cc: stable@vger.kernel.org # v5.5+
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221121145655.75141-3-janusz.krzysztofik@linux.intel.com
(cherry picked from commit f301a29f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Commit b97060a9 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
with GuC") extended the API of intel_gt_retire_requests_timeout() with an
extra argument 'remaining_timeout', intended for passing back unconsumed
portion of requested timeout when 0 (success) is returned.  However, when
request retirement happens to succeed despite an error returned by a call
to dma_fence_wait_timeout(), that error code (a negative value) is passed
back instead of remaining time.  If we then pass that negative value
forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG
will be triggered.

If request retirement succeeds but an error code is passed back via
remaininig_timeout, we may have no clue on how much of the initial timeout
might have been left for spending it on waiting for GuC to become idle.
OTOH, since all pending requests have been successfully retired, that
error code has been already ignored by intel_gt_retire_requests_timeout(),
then we shouldn't fail.

Assume no more time has been left on error and pass 0 timeout value to
intel_uc_wait_for_idle() to give it a chance to return success if GuC is
already idle.

v3: Don't fail on any error passed back via remaining_timeout.

v2: Fix the issue on the caller side, not the provider.

Fixes: b97060a9 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC")
Signed-off-by: NJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: stable@vger.kernel.org # v5.15+
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221121145655.75141-2-janusz.krzysztofik@linux.intel.com
(cherry picked from commit f235dbd5)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The fence is always initialized in huc_init_early, but the cleanup in
huc_fini is only being run if HuC is enabled. This causes a leaking of
the debug object when HuC is disabled/not supported, which can in turn
trigger a warning if we try to register a new debug offset at the same
address on driver reload.

To fix the issue, make sure to always run the cleanup code.
Reported-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reported-by: NBrian Norris <briannorris@chromium.org>
Fixes: 27536e03 ("drm/i915/huc: track delayed HuC load with a fence")
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Tested-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NJohn Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221111005651.4160369-1-daniele.ceraolospurio@intel.com
(cherry picked from commit 02224691)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Add required display hw catalog changes for SM6115.
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NAdam Skladowski <a39.skl@gmail.com>
Reviewed-by: NKonrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/512875/
Link: https://lore.kernel.org/r/20221124001708.25720-3-a39.skl@gmail.comSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Since the commit commit c6122688 ("drm/msm/mdp5: stop overriding
drvdata") reading the MDP5 hw revision on db410c will crash the board
as the MDSS_GDSC is not enabled. Revert a part of the offending commit
(moving rpm enablement) and set priv->kms earlier. This make it possible
to use pm_runtime_get_sync() during read_mdp_hw_revision(), which will
power up both the MDP5 and MDSS devices.

Fixes: c6122688 ("drm/msm/mdp5: stop overriding drvdata")
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/512985/
Link: https://lore.kernel.org/r/20221125000213.252115-1-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

This structure is never used outside the file, so make it locally
scoped.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The symbol is not used outside of the file, so mark it static.

Fixes the following warning:

./drivers/gpu/drm/tegra/submit.c:136:28: warning: symbol 'gather_bo_ops'
was not declared. Should it be static?
Signed-off-by: Nruanjinjie <ruanjinjie@huawei.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the debugfs code for
the status and status_all entries. No functional change.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

devm_gpiod_get_from_of_node() is going away and GPIO consumers should
use generic device/firmware node APIs to fetch GPIOs assigned to them.
Switch the driver to use devm_fwnode_gpiod_get() instead.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add support for the Tegra234 version of NVDEC to the NVDEC driver.
This version sports a RISC-V controller and requires a few additional
clocks. After firmware has been loaded, the behavior is, however,
backwards compatible.
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add helper code for booting RISC-V based engines where firmware is
located in a carveout.
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

NVDEC on Tegra234 requires multiple clocks. Add support for that.
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add entries for NVDEC to the Tegra234 SID table.
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
has been loaded by a bootloader. When booting NVDEC, we need to tell it
the address of this firmware, which we can determine by checking the
starting address of the carveout. As such, add an MC API to query the
bounds of carveouts, and add related information on Tegra234.
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Acked-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Prefer the parsed results for is_hdmi in display info over calling
drm_detect_hdmi_monitor().

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add the missing clk_disable_unprepare() before return from
tegra_dc_probe() in the error handling path.

Fixes: f68ba691 ("drm/tegra: dc: Link DC1 to DC0 on Tegra20")
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This patch fixes the following Coccinelle warning:

drivers/gpu/drm/tegra/submit.c:173: WARNING opportunity for vmemdup_user

Use vmemdup_user() rather than duplicating its implementation.
This is a little bit restricted to reduce false positives.
Signed-off-by: NQing Wang <wangqing@vivo.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

On Tegra234, engines that are programmed through Host1x channels can
be attached to either the NISO0 or NISO1 SMMU. Because of that, when
selecting a context device to use with an engine, we need to select
one that is also attached to the same SMMU.

Add a parameter to host1x_memory_context_alloc to specify which device
we are allocating a context for, and use it to pick an appropriate
context device.
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
[treding@nvidia.com: update !IOMMU_API stub signature]
Signed-off-by: NThierry Reding <treding@nvidia.com>

Engine busyness samples around a 10ms period is failing with busyness
ranging approx. from 87% to 115% as shown below. The expected range is
+/- 5% of the sample period. Fail 10% of the time.

rcs0: reported 11716042ns [91%] busyness while spinning [for 12805719ns]

When determining busyness of active engine, the GuC based engine
busyness implementation relies on a 64 bit timestamp register read. The
latency incurred by this register read causes the failure.

On DG1, when the test fails, the observed latencies range from 900us -
1.5ms.

Optimizing the 2x32 read by acquiring the lock and forcewake prior to
all reg reads reduces the rate of failure to around 2%, but does not
eliminate it.

In order to make the selftest more robust and always account for such
latencies, increase the sample period to 100 ms. This eliminates the
issue as seen in a 1000 runs.

v2: (Ashutosh)
- Add error to commit msg
- Include gitlab bug
- Update commit for inclusion of 2x32 optimized read

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4418Signed-off-by: NUmesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Acked-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221110171913.670286-3-umesh.nerlige.ramappa@intel.com
(cherry picked from commit 529d95a6)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

PMU reads the GT timestamp as a 2x32 mmio read and since upper and lower
32 bit registers are read in a loop, there is a latency involved between
getting the GT timestamp and the CPU timestamp. As part of the
resolution, refactor intel_uncore_read64_2x32 to acquire forcewake and
uncore lock prior to reading upper and lower regs.
Signed-off-by: NUmesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221110171913.670286-2-umesh.nerlige.ramappa@intel.com
(cherry picked from commit e746f84b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The default_lists array should be in rodata.

Fixes: dce2bd54 ("drm/i915/guc: Add Gen9 registers for GuC error state capture.")
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221122141616.3469214-1-jani.nikula@intel.com
(cherry picked from commit 8b7f7a9b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

bigjoiner_pipes() doesn't consider that:
- RKL only has three pipes
- some pipes may be fused off

This means that intel_atomic_check_bigjoiner() won't reject
all configurations that would need a non-existent pipe.
Instead we just keep on rolling witout actually having
reserved the slave pipe we need.

It's possible that we don't outright explode anywhere due to
this since eg. for_each_intel_crtc_in_pipe_mask() will only
walk the crtcs we've registered even though the passed in
pipe_mask asks for more of them. But clearly the thing won't
do what is expected of it when the required pipes are not
present.

Fix the problem by consulting the device info pipe_mask already
in bigjoiner_pipes().

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221118185201.10469-1-ville.syrjala@linux.intel.comReviewed-by: NArun R Murthy <arun.r.murthy@intel.com>
(cherry picked from commit f1c87a94)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

In 36537275 ("drm/i915: Simplify internal helper function signature")
I broke the old platforms by not noticing engine workaround init does not
initialize the list on old platforms. Fix it by always initializing which
already does the right thing by mostly not doing anything if there aren't
any workarounds on the list.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 36537275 ("drm/i915: Simplify internal helper function signature")
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221118115249.2683946-1-tvrtko.ursulin@linux.intel.com
(cherry picked from commit 71feb6f9)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The GT MCR code currently relies on uncore->lock to avoid race
conditions on the steering control register during MCR operations.  The
*_fw() versions of MCR operations expect the caller to already hold
uncore->lock, while the non-fw variants manage the lock internally.
However the sole callsite of intel_gt_mcr_wait_for_reg_fw() does not
currently obtain the forcewake lock, allowing a potential race condition
(and triggering an assertion on lockdep builds).  Furthermore, since
'wait for register value' requests may not return immediately, it is
undesirable to hold a fundamental lock like uncore->lock for the entire
wait and block all other MMIO for the duration; rather the lock is only
needed around the MCR read operations and can be released during the
delays.

Convert intel_gt_mcr_wait_for_reg_fw() to a non-fw variant that will
manage uncore->lock internally.  This does have the side effect of
causing an unnecessary lookup in the forcewake table on each read
operation, but since the caller is still holding the relevant forcewake
domain, this will ultimately just incremenent the reference count and
won't actually cause any additional MMIO traffic.

In the future we plan to switch to a dedicated MCR lock to protect the
steering critical section rather than using the overloaded and
high-traffic uncore->lock; on MTL and beyond the new lock can be
implemented on top of the hardware-provided synchonization mechanism for
steering.

Fixes: 3068bec8 ("drm/i915/gt: Add intel_gt_mcr_wait_for_reg_fw()")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221117173358.1980230-1-matthew.d.roper@intel.com
(cherry picked from commit 192bb40f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

MT8195 ovl driver is similar to MT8183 ovl driver but support
AFBC buffer format.
Signed-off-by: NJustin Green <greenjustin@chromium.org>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20221116193335.36320-1-greenjustin@google.com/Signed-off-by: NChun-Kuang Hu <chunkuang.hu@kernel.org>

Tested on MT8195 and confirmed both correct video output and improved DRAM
bandwidth performance.
Signed-off-by: NJustin Green <greenjustin@chromium.org>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20221116193335.36320-1-greenjustin@google.com/Signed-off-by: NChun-Kuang Hu <chunkuang.hu@kernel.org>

This partially reverts 20543be9.

Calling drm_connector_update_edid_property() in
amdgpu_connector_free_edid() causes a noticeable pause in
the system every 10 seconds on polled outputs so revert this
part of the change.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2257
Cc: Claudio Suarez <cssk@net-c.es>
Acked-by: NLuben Tuikov <luben.tuikov@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The driver is MIT, so add the licenses.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2265Acked-by: NLuben Tuikov <luben.tuikov@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Configure related settings to enable it.
Signed-off-by: NTao Zhou <tao.zhou1@amd.com>
Signed-off-by: NLijo Lazar <lijo.lazar@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Move the topology-locked part of kfd_topology_add_device into a separate
function to simlpify error handling and release the topology lock
consistently.
Reported-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NFelix Kuehling <felix.kuehling@gmail.com>
Signed-off-by: NMa Jun <Jun.Ma2@amd.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Prepare for enableing VCN RAS poison.

v2: move SHIFT and MASK definitions to related sh_mask.h file.
Signed-off-by: NTao Zhou <tao.zhou1@amd.com>
Signed-off-by: NLijo Lazar <lijo.lazar@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

- in device_resume, sriov configure interrupt should be in full access,
  so release_full_gpu should be done after kfd_resume.
- remove the previous workaround solution for sriov.

Fixes: ec4927d4 ("drm/amdgpu: fix for suspend/resume sequence under sriov")
Signed-off-by: NShikang Fan <shikang.fan@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
If the timing generator isnt running, it does not make sense to trigger
a sync on the corresponding OTG. Check this condition before starting.
Otherwise, this will cause error like:

*ERROR* GSL: Timeout on reset trigger!

Fixes: dc55b106 ("drm/amd/display: Disable phantom OTG after enable for plane disable")
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

One-element arrays are deprecated, and we are replacing them with
flexible array members instead. So, replace one-element array with
flexible-array member in struct GOP_VBIOS_CONTENT and refactor the
rest of the code accordingly.

Important to mention is that doing a build before/after this patch
results in no functional binary output differences.

This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].

Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/238
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1]
Signed-off-by: NPaulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 5aa66375.

This causes a blank screen on boot on an Asus G513QY / 6800M laptop.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2259
Cc: Aric Cyr <Aric.Cyr@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Cc: Zhongwei Zhang <Zhongwei.Zhang@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Tested-by: NMike Lothian <mike@fireburn.co.uk>
Reviewed-by: NLuben Tuikov <luben.tuikov@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If CONFIG_DRM_AMDGPU=y and CONFIG_DRM_AMD_DC is not set,
gcc complained about unused-function :

drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1705:13: error: ‘amdgpu_discovery_set_sriov_display’ defined but not used [-Werror=unused-function]
 static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

To fix this error, use CONFIG_DRM_AMD_DC to wrap
the definition of amdgpu_discovery_set_sriov_display().

Fixes: 25263da3 ("drm/amdgpu: rework SR-IOV virtual display handling")
Signed-off-by: NRen Zhijie <renzhijie2@huawei.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>