To avoid preventing the display from coming up before the rootfs is
mounted, without resorting to packing fw in the initrd, the GPU has
this limbo state where the device is probed, but we aren't ready to
start sending commands to it.  This is particularly problematic for
a6xx, since the GMU (which requires fw to be loaded) is the one that
is controlling the power/clk/icc votes.

So defer enabling runpm until we are ready to call gpu->hw_init(),
as that is a point where we know we have all the needed fw and are
ready to start sending commands to the coproc's.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489337/
Link: https://lore.kernel.org/r/20220613182036.2567963-1-robdclark@gmail.com

The only reason we grabbed the lock was to satisfy a bunch of places
that WARN_ON() if called without the lock held.  But this angers lockdep
which doesn't realize no one else can be holding the lock by the time we
end up destroying the object (and sees what would otherwise be a locking
inversion between reservation_ww_class_mutex and fs_reclaim).

Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/14Signed-off-by: NRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489364/
Link: https://lore.kernel.org/r/20220613205032.2652374-1-robdclark@gmail.com

Remove unused dp_display_en/disable prototypes. While we are at it,
remove extra 'data' argument that is unused.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/490104/
Link: https://lore.kernel.org/r/20220617232434.1139950-3-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

To follow up recent changes, rename (and change type of) second
dp_display_enable()'s argument from generic u32 data to bool
force_link_train, which is later passed to dp_ctrl_on_stream().
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/490102/
Link: https://lore.kernel.org/r/20220617232434.1139950-2-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

Refactoring DP code transformed several functions into empty stubs.
Remove them.
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/490100/
Link: https://lore.kernel.org/r/20220617232434.1139950-1-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

With sparse ("make C=2"), lots of

  error: return expression in void function

messages are seen.

Fix this by removing the return statements to propagate void return
values.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Patchwork: https://patchwork.freedesktop.org/patch/492529/
Link: https://lore.kernel.org/r/0083bc7e23753c19902580b902582ae499b44dbf.1657113388.git.geert@linux-m68k.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

When trying to understand an iova fault devcore, once you figure out
which buffer we accessed beyond the end of, it is useful to see the
buffer's debug label.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/491910/
Link: https://lore.kernel.org/r/20220629211919.563585-3-robdclark@gmail.com

It is useful to know what buffers userspace thinks are associated with
the submit, even if we don't care to capture their content.  This brings
things more inline with $debugfs/rd cmdstream dumping.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/491908/
Link: https://lore.kernel.org/r/20220629211919.563585-2-robdclark@gmail.com

Change msm_kms_init_aspace() to use generic function
device_iommu_mapped() instead of the fwnode-specific interface
dev_iommu_fwspec_get(). While we are at it, stop referencing
platform_bus_type directly and use the bus of the IOMMU device.
Suggested-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489703/
Link: https://lore.kernel.org/r/20220616081106.350262-6-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

MDP5 and DPU drivers have the same piece of code now to initialize
IOMMU and GEM address space. Move it to the msm_drv.c
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489701/
Link: https://lore.kernel.org/r/20220616081106.350262-5-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.

On Qualcomm platforms the IOMMU can be specified either for the MDP/DPU
device or for its parent MDSS device depending on the actual platform.
Check both of them, since that is how both DPU and MDP5 drivers work.
Co-developed-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/489699/
Link: https://lore.kernel.org/r/20220616081106.350262-4-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained from the pre-DT days.
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489695/
Link: https://lore.kernel.org/r/20220616081106.350262-3-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

Follow the lead of MDP5 driver and check both DPU and MDSS devices for
the IOMMU specifiers.

Historically DPU devices had IOMMU specified in the MDSS device tree
node, but as some of MDP5 devices are being converted to the supported
by the DPU driver, the driver should adapt and check both devices.
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489696/
Link: https://lore.kernel.org/r/20220616081106.350262-2-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

In debugging fence rollover, I noticed that GPU state capture and
devcore dumps were showing me negative fence numbers.  Let's fix that
and some related signed vs unsigned confusion.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489621/
Link: https://lore.kernel.org/r/20220615163532.3013035-1-robdclark@gmail.com

There is little point in having a separate header just for a single
opaque struct definition. Drop it now and move the struct to the
dpu_hw_util.h header.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/488016/
Link: https://lore.kernel.org/r/20220601161349.1517667-5-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

There is little point in keeping a separate MDP address and block offset
in this struct. Merge them to form a new blk_addr field used for all
register access.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/488017/
Link: https://lore.kernel.org/r/20220601161349.1517667-4-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

We (nearly) do not use the length field from struct dpu_hw_blk_reg_map,
so we can drop it safely.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/488013/
Link: https://lore.kernel.org/r/20220601161349.1517667-3-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

Drop the unused field xin_id.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/488011/
Link: https://lore.kernel.org/r/20220601161349.1517667-2-dmitry.baryshkov@linaro.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

The restriction to 4G was strictly to work around 64b math bug in some
versions of SQE firmware.  This appears to be fixed in a650+ SQE fw, so
allow a larger address space size on these devices.

Also, add a modparam override for debugging and igt.

v2: Send the right version of the patch (ie. the one that actually
    compiles)
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/487601/
Link: https://lore.kernel.org/r/20220529180428.2577832-1-robdclark@gmail.com

Leading spaces are not something checkpatch likes, and it says so when
they are present. Use tabs consistently to indent function body and
unwrap a 83-char-long line, as 100 is cool nowadays.
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487592/
Link: https://lore.kernel.org/r/20220528160353.157870-4-konrad.dybcio@somainline.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

There are various SKUs of A619, ranging from 565 MHz to 850 MHz, depending
on the bin. Add support for distinguishing them, so that proper frequency
ranges can be applied, depending on the HW.
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487590/
Link: https://lore.kernel.org/r/20220528160353.157870-3-konrad.dybcio@somainline.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350),
480 (SM4350) and 750G (SM7225).
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487588/
Link: https://lore.kernel.org/r/20220528160353.157870-2-konrad.dybcio@somainline.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

This BUG_ON will never be reached, and there is a comment 20 above
explaining why.
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487586/
Link: https://lore.kernel.org/r/20220528160353.157870-1-konrad.dybcio@somainline.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately the current a6xx_gpu_busy() grabs a
reference to the GMU's "struct device".

The fact that we were grabbing the wrong reference was easily seen to
cause crashes that happen if we change the GPU's pm_runtime usage to
not use autosuspend. It's also believed to cause some long tail GPU
crashes even with autosuspend.

We could look at changing it so that we do pm_runtime_get_if_in_use()
on the GPU's "struct device", but then we run into a different
problem. pm_runtime_get_if_in_use() will return 0 for the GPU's
"struct device" the whole time when we're in the "autosuspend
delay". That is, when we drop the last reference to the GPU but we're
waiting a period before actually suspending then we'll think the GPU
is off. One reason that's bad is that if the GPU didn't actually turn
off then the cycle counter doesn't lose state and that throws off all
of our calculations.

Let's change the code to keep track of the suspend state of
devfreq. msm_devfreq_suspend() is always called before we actually
suspend the GPU and msm_devfreq_resume() after we resume it. This
means we can use the suspended state to know if we're powered or not.

NOTE: one might wonder when exactly our status function is called when
devfreq is supposed to be disabled. The stack crawl I captured was:
  msm_devfreq_get_dev_status
  devfreq_simple_ondemand_func
  devfreq_update_target
  qos_notifier_call
  qos_max_notifier_call
  blocking_notifier_call_chain
  pm_qos_update_target
  freq_qos_apply
  apply_constraint
  __dev_pm_qos_update_request
  dev_pm_qos_update_request
  msm_devfreq_idle_work

Fixes: eadf7928 ("drm/msm: Check for powered down HW in the devfreq callbacks")
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/489124/
Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

And while we are at it, let's start the fence counter close to the
rollover point so that if issues slip in, they are more obvious.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Fixes: fde5de6c ("drm/msm: move fence code to it's own file")
Fixes: 5f3aee4c ("drm/msm: Handle fence rollover")
Patchwork: https://patchwork.freedesktop.org/patch/489619/
Link: https://lore.kernel.org/r/20220615162435.3011793-1-robdclark@gmail.com
[DB: fixed the conflict while applying the patch]
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Fix following coccicheck warning:
drivers/gpu/drm/msm/msm_gpu_devfreq.c:72:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_ul instead.

Use div64_ul instead of do_div to avoid a possible truncation.
Signed-off-by: NWan Jiabing <wanjiabing@vivo.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Patchwork: https://patchwork.freedesktop.org/patch/483499/
Link: https://lore.kernel.org/r/20220426132126.686447-1-wanjiabing@vivo.comSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Similar to AMD commit
87444254 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.

Example output:

	# cat /proc/`pgrep glmark2`/fdinfo/6
	pos:	0
	flags:	02400002
	mnt_id:	21
	ino:	162
	drm-driver:	msm
	drm-client-id:	7
	drm-engine-gpu:	1734371319 ns
	drm-cycles-gpu:	1153645024
	drm-maxfreq-gpu:	800000000 Hz

See also: https://patchwork.freedesktop.org/patch/468505/

v2: Add dev-maxfreq-$engine and update drm-usage-stats.rst
v3: spelling and compiler warning
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Patchwork: https://patchwork.freedesktop.org/patch/488906/
Link: https://lore.kernel.org/r/20220609174213.2265938-2-robdclark@gmail.comSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Misc small cleanup I noticed.  Not called from another object file since
commit 3c9edd9c ("drm/msm: Introduce GEM object funcs")
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489362/
Link: https://lore.kernel.org/r/20220613204910.2651747-1-robdclark@gmail.comSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Add destination side post processing hw block support in sc7280.

This hwblock enablement is necessary to support color features
like CT Matix (Ex: Night Light feature)
Signed-off-by: NKalyan Thota <quic_kalyant@quicinc.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/490382/
Link: https://lore.kernel.org/r/1655802387-15275-1-git-send-email-quic_kalyant@quicinc.comSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Add the perf data for the mdp found in msm8953.
Signed-off-by: NVladimir Lypak <vladimir.lypak@gmail.com>
Signed-off-by: NLuca Weiss <luca@z3ntu.xyz>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489153/
Link: https://lore.kernel.org/r/20220610225304.267508-1-luca@z3ntu.xyzSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Struct mdp4_platform_config is a relict from the DT-conversion time.
Move the max_clk field to the mdp4_kms_init(), the place where it is
used and drop the struct mdp4_platform_config and the mdp4_get_config()
function.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/485050/
Link: https://lore.kernel.org/r/20220505135008.1351533-3-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop it from struct mdp4_cfg_platform which
remained from the pre-DT days.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/485049/
Link: https://lore.kernel.org/r/20220505135008.1351533-2-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

There might be a chain of bridges attached to the HDMI node
(including but not limited to the display-connector bridge). Add support
for attaching them right to the HDMI bridge chain.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489709/
Link: https://lore.kernel.org/r/20220616085057.432353-1-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Drop empty callbacks msm_hdmi_bridge_enable() and
msm_hdmi_bridge_disable().
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489707/
Link: https://lore.kernel.org/r/20220616085054.432317-1-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Declare that 8x60 HDMI PHY uses the core-vdda regulator and slave_iface
clock (this is the same config as is used by the 8960).
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/488863/
Link: https://lore.kernel.org/r/20220609122350.3157529-13-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

MSM8660 requires the same set of clocks and regulators as MSM8960. Reuse
MSM8960's config for the MSM8660 (8x60).
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/488864/
Link: https://lore.kernel.org/r/20220609122350.3157529-12-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Since there is no more difference between the HDMI platform data
between MSM8974/APQ8084/MSM8994/MSM8996, merge these configs into a
single entry.
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/488868/
Link: https://lore.kernel.org/r/20220609122350.3157529-11-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

The MSM HDMI driver has support for hpd_regs on 8x74/8084: supply
regulators that are to be enabled for HPD to work. Currently these
regulators contain the hpd_gdsc, which was replaced by the power-domains
support and hpd-5v/hpd-5v-en, which are not used by the chip itself.
They power up the ESD bridge.
However it is a separate device which should be represented separately
in the device tree.
None of upstreamed devices support these properties. Thus drop support
for them from the HDMI driver.
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/488860/
Link: https://lore.kernel.org/r/20220609122350.3157529-10-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

Several platform configs use empty 'none' regulator arrays. They are not
necessary, as the code will use corresponding _cnt field and skip the
array completely. Drop them now.
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/488861/
Link: https://lore.kernel.org/r/20220609122350.3157529-9-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>

DB820c makes use of core-vcc-supply and core-vdda-supply, however the
driver code doesn't support these regulators. Enable them for HDMI on
8996 platform.

Fixes: 0afbe59e ("drm/msm/hdmi: Add basic HDMI support for msm8996")
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/488857/
Link: https://lore.kernel.org/r/20220609122350.3157529-8-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>