The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NThomas Zimmermann <tzimemrmann@suse.de>
Acked-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221019024401.394617-1-zack@kde.org

There is a spelling mistake in a Kconfig description. Fix it.
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/506301/
Link: https://lore.kernel.org/r/20221007202338.2755731-1-colin.i.king@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

Rectify the below smatch warning:
drivers/gpu/drm/msm/msm_gem_submit.c:963 msm_ioctl_gem_submit() warn:
variable dereferenced before check 'submit'

'submit' is normally error pointer or valid, so remove its NULL
initializer as it's confusing and also remove a redundant check for it's
value.
Signed-off-by: NAashish Sharma <shraash@google.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/506653/
Link: https://lore.kernel.org/r/20221011075519.3111928-1-shraash@google.comSigned-off-by: NRob Clark <robdclark@chromium.org>

Technically it worked as it was before, only because it was using the
_safe version of the iterator.  But it is sloppy practice to leave
dangling pointers.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/507017/
Link: https://lore.kernel.org/r/20221013225520.371226-4-robdclark@gmail.com

Some buffers are unused on certain sub-generations of a6xx.  So just
skip them.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/507013/
Link: https://lore.kernel.org/r/20221013225520.371226-3-robdclark@gmail.com

adreno_show_object() is a trap!  It will re-allocate the pointer it is
passed on first call, when the data is ascii85 encoded, using kvmalloc/
kvfree().  Which means the data *passed* to it must be kvmalloc'd, ie.
we cannot use the state_kcalloc() helper.

This partially reverts commit ec8f1813 ("drm/msm/a6xx: Replace
kcalloc() with kvzalloc()"), but adds the missing kvfree() to fix the
memory leak that was present previously.  And adds a warning comment.

Fixes: ec8f1813 ("drm/msm/a6xx: Replace kcalloc() with kvzalloc()")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/20Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/507014/
Link: https://lore.kernel.org/r/20221013225520.371226-2-robdclark@gmail.com

DOWNSPREAD_CTRL (0x107) shall be cleared to 0 upon power-on reset or an
upstream device disconnect. This patch will enforce this rule by always
cleared DOWNSPREAD_CTRL register to 0 before start link training. At rare
case that DP MSA timing parameters may be mis-interpreted by the sink
which causes audio sampling rate be calculated wrongly and cause audio
did not work at sink if DOWNSPREAD_CTRL register is not cleared to 0.

Changes in v2:
1) fix spelling at commit text
2) merge ssc variable into encoding[0]

Changes in v3:
-- correct spelling of DOWNSPREAD_CTRL
-- replace err with len of ssize_t

Changes in v4:
-- split into 2 patches
Signed-off-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: c943b494 ("drm/msm/dp: add displayPort driver support")
Patchwork: https://patchwork.freedesktop.org/patch/502532/
Link: https://lore.kernel.org/r/1662999830-13916-2-git-send-email-quic_khsieh@quicinc.comSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.

This is specifically true for the HDMI IRQ, which will otherwise remain
requested so that the next bind attempt fails when requesting the IRQ a
second time.

Fix this by tying the device-managed lifetime of the HDMI IRQ to the DRM
device so that it is released when bind fails.

Fixes: 067fef37 ("drm/msm/hdmi: refactor bind/init")
Cc: stable@vger.kernel.org      # 3.19
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Tested-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/502666/
Link: https://lore.kernel.org/r/20220913085320.8577-9-johan+linaro@kernel.orgSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.

This can lead resource leaks or failure to bind the aggregate device
when binding is later retried and a second attempt to allocate the
resources is made.

For the DP bridges, previously allocated bridges will leak on probe
deferral.

Fix this by amending the DP parser interface and tying the lifetime of
the bridge device to the DRM device rather than DP platform device.

Fixes: c3bf8e21 ("drm/msm/dp: Add eDP support via aux_bus")
Cc: stable@vger.kernel.org      # 5.19
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Tested-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/502667/
Link: https://lore.kernel.org/r/20220913085320.8577-8-johan+linaro@kernel.orgSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.

This can lead resource leaks or failure to bind the aggregate device
when binding is later retried and a second attempt to allocate the
resources is made.

For the DP aux-bus, an attempt to populate the bus a second time will
simply fail ("DP AUX EP device already populated").

Fix this by tying the lifetime of the EP device to the DRM device rather
than DP controller platform device.

Fixes: c3bf8e21 ("drm/msm/dp: Add eDP support via aux_bus")
Cc: stable@vger.kernel.org      # 5.19
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/502672/
Link: https://lore.kernel.org/r/20220913085320.8577-7-johan+linaro@kernel.orgSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.

This is specifically true for the DP IRQ, which will otherwise remain
requested so that the next bind attempt fails when requesting the IRQ a
second time.

Since commit c3bf8e21 ("drm/msm/dp: Add eDP support via aux_bus")
this can happen when the aux-bus panel driver has not yet been loaded so
that probe is deferred.

Fix this by tying the device-managed lifetime of the DP IRQ to the DRM
device so that it is released when bind fails.

Fixes: c943b494 ("drm/msm/dp: add displayPort driver support")
Cc: stable@vger.kernel.org      # 5.10
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Tested-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/502679/
Link: https://lore.kernel.org/r/20220913085320.8577-6-johan+linaro@kernel.orgSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.

Fixes: a3376e3e ("drm/msm: convert to drm_bridge")
Cc: stable@vger.kernel.org	# 3.12
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Tested-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/502670/
Link: https://lore.kernel.org/r/20220913085320.8577-5-johan+linaro@kernel.orgSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.

Fixes: a689554b ("drm/msm: Initial add DSI connector support")
Cc: stable@vger.kernel.org	# 4.1
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Tested-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/502668/
Link: https://lore.kernel.org/r/20220913085320.8577-4-johan+linaro@kernel.orgSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.

Fixes: 8a3b4c17 ("drm/msm/dp: employ bridge mechanism for display enable and disable")
Cc: stable@vger.kernel.org	# 5.17
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Tested-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/502664/
Link: https://lore.kernel.org/r/20220913085320.8577-3-johan+linaro@kernel.orgSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

The bridge counter was never reset when tearing down the DRM device so
that stale pointers to deallocated structures would be accessed on the
next tear down (e.g. after a second late bind deferral).

Given enough bridges and a few probe deferrals this could currently also
lead to data beyond the bridge array being corrupted.

Fixes: d28ea556 ("drm/msm: properly add and remove internal bridges")
Fixes: a3376e3e ("drm/msm: convert to drm_bridge")
Cc: stable@vger.kernel.org      # 3.12
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Tested-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/502665/
Link: https://lore.kernel.org/r/20220913085320.8577-2-johan+linaro@kernel.orgSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
                                     struct drm_display_mode *mode);

The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition.

The return type of mdp4_lvds_connector_mode_valid should be changed from
int to enum drm_mode_status.
Reported-by: NDan Carpenter <error27@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1703
Cc: llvm@lists.linux.dev
Signed-off-by: NNathan Huckleberry <nhuck@google.com>
Fixes: 3e87599b ("drm/msm/mdp4: add LVDS panel support")
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/502878/
Link: https://lore.kernel.org/r/20220913205551.155128-1-nhuck@google.comSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

DRM commit_tails() will disable downstream crtc/encoder/bridge if
both disable crtc is required and crtc->active is set before pushing
a new frame downstream.

There is a rare case that user space display manager issue an extra
screen update immediately followed by close DRM device while down
stream display interface is disabled. This extra screen update will
timeout due to the downstream interface is disabled but will cause
crtc->active be set. Hence the followed commit_tails() called by
drm_release() will pass the disable downstream crtc/encoder/bridge
conditions checking even downstream interface is disabled.
This cause the crash to happen at dp_bridge_disable() due to it trying
to access the main link register to push the idle pattern out while main
link clocks is disabled.

This patch adds atomic_check to prevent the extra frame will not
be pushed down if display interface is down so that crtc->active
will not be set neither. This will fail the conditions checking
of disabling down stream crtc/encoder/bridge which prevent
drm_release() from calling dp_bridge_disable() so that crash
at dp_bridge_disable() prevented.

There is no protection in the DRM framework to check if the display
pipeline has been already disabled before trying again. The only
check is the crtc_state->active but this is controlled by usermode
using UAPI. Hence if the usermode sets this and then crashes, the
driver needs to protect against double disable.

SError Interrupt on CPU7, code 0x00000000be000411 -- SError
CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19
Hardware name: Google Lazor (rev3 - 8) (DT)
pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __cmpxchg_case_acq_32+0x14/0x2c
lr : do_raw_spin_lock+0xa4/0xdc
sp : ffffffc01092b6a0
x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038
x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000
x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008
x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000
x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0
x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4
x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001
x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0
x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19
Hardware name: Google Lazor (rev3 - 8) (DT)
Call trace:
 dump_backtrace.part.0+0xbc/0xe4
 show_stack+0x24/0x70
 dump_stack_lvl+0x68/0x84
 dump_stack+0x18/0x34
 panic+0x14c/0x32c
 nmi_panic+0x58/0x7c
 arm64_serror_panic+0x78/0x84
 do_serror+0x40/0x64
 el1h_64_error_handler+0x30/0x48
 el1h_64_error+0x68/0x6c
 __cmpxchg_case_acq_32+0x14/0x2c
 _raw_spin_lock_irqsave+0x38/0x4c
 lock_timer_base+0x40/0x78
 __mod_timer+0xf4/0x25c
 schedule_timeout+0xd4/0xfc
 __wait_for_common+0xac/0x140
 wait_for_completion_timeout+0x2c/0x54
 dp_ctrl_push_idle+0x40/0x88
 dp_bridge_disable+0x24/0x30
 drm_atomic_bridge_chain_disable+0x90/0xbc
 drm_atomic_helper_commit_modeset_disables+0x198/0x444
 msm_atomic_commit_tail+0x1d0/0x374
 commit_tail+0x80/0x108
 drm_atomic_helper_commit+0x118/0x11c
 drm_atomic_commit+0xb4/0xe0
 drm_client_modeset_commit_atomic+0x184/0x224
 drm_client_modeset_commit_locked+0x58/0x160
 drm_client_modeset_commit+0x3c/0x64
 __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac
 drm_fb_helper_set_par+0x74/0x80
 drm_fb_helper_hotplug_event+0xdc/0xe0
 __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac
 drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c
 drm_fb_helper_lastclose+0x20/0x2c
 drm_lastclose+0x44/0x6c
 drm_release+0x88/0xd4
 __fput+0x104/0x220
 ____fput+0x1c/0x28
 task_work_run+0x8c/0x100
 do_exit+0x450/0x8d0
 do_group_exit+0x40/0xac
 __wake_up_parent+0x0/0x38
 invoke_syscall+0x84/0x11c
 el0_svc_common.constprop.0+0xb8/0xe4
 do_el0_svc+0x8c/0xb8
 el0_svc+0x2c/0x54
 el0t_64_sync_handler+0x120/0x1c0
 el0t_64_sync+0x190/0x194
SMP: stopping secondary CPUs
Kernel Offset: 0x128e800000 from 0xffffffc008000000
PHYS_OFFSET: 0x80000000
CPU features: 0x800,00c2a015,19801c82
Memory Limit: none

Changes in v2:
-- add more commit text

Changes in v3:
-- add comments into dp_bridge_atomic_check()

Changes in v4:
-- rewording the comment into dp_bridge_atomic_check()

Changes in v5:
-- removed quote x at end of commit text

Changes in v6:
-- removed quote x at end of comment in dp_bridge_atomic_check()

Fixes: 8a3b4c17 ("drm/msm/dp: employ bridge mechanism for display enable and disable")
Reported-by: NLeonard Lausen <leonard@lausen.nl>
Suggested-by: NRob Clark <robdclark@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/17Signed-off-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/505331/
Link: https://lore.kernel.org/r/1664408211-25314-1-git-send-email-quic_khsieh@quicinc.comSigned-off-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>

In adreno_unbind, we should clean up gpu device's drvdata to avoid
accessing a stale pointer during system suspend. Also, check for NULL
ptr in both system suspend/resume callbacks.
Signed-off-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/505075/
Link: https://lore.kernel.org/r/20220928124830.2.I5ee0ac073ccdeb81961e5ec0cce5f741a7207a71@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

In order to reduce chance of allocation failure while capturing a6xx
gpu state, use kvzalloc() instead of kcalloc() in state_kcalloc().

Indirectly, this patch helps to fix leaking memory allocated for
gmu_debug object.

Fixes: b859f9b0 (drm/msm/gpu: Snapshot GMU debug buffer)
Signed-off-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/505074/
Link: https://lore.kernel.org/r/20220928124830.1.I8ea24a8d586b4978823b848adde000f92f74d5c2@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

The introduction of "drm/msm/gem: Evict active GEM objects when necessary"
exposes a problem with "drm/msm/gem: Unpin buffers earlier", in that we
need to keep the object pinned in the time the submit is queued up in the
gpu scheduler.  Otherwise the shrinker will see it as a thing that can be
evicted if we wait for it to be signaled.  But if the shrinker path is
waiting on it with the obj lock held, the job cannot be scheduled, as that
also requires briefly grabbing the obj lock, leading to deadlock.  (Not to
mention, we don't want the shrinker to evict an obj queued up in gpu
scheduler.)

Fixes: f371bcc0 ("drm/msm/gem: Unpin buffers earlier")
Fixes: 025d2723 ("drm/msm/gem: Evict active GEM objects when necessary")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/19Signed-off-by: NRob Clark <robdclark@chromium.org>
Tested-by: NChia-I Wu <olvaffe@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/504528/
Link: https://lore.kernel.org/r/20220923224043.2449152-1-robdclark@gmail.com

9178e3dcb121 ("mm: discard __GFP_ATOMIC") removed __GFP_ATOMIC,
replacing it with a check for not __GFP_DIRECT_RECLAIM.
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NRob Clark <robdclark@chromium.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220929161404.2769414-1-robdclark@gmail.com

On MSM8996 the HDMI PHY provides the PLL clock to the MMCC. As we are
preparing to convert the MSM8996 to use DT clocks properties (rather
than global clock names), register the OF clock provider.

While we are at it, also change the driver to use clk_parent_data rather
parent_names to setup a link to the XO clock.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/492318/
Link: https://lore.kernel.org/r/20220704161148.814510-3-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

Clang warns:

  drivers/gpu/drm/msm/dsi/dsi_host.c:1903:14: error: variable 'device_node' is uninitialized when used here [-Werror,-Wuninitialized]
          of_node_put(device_node);
                      ^~~~~~~~~~~
  drivers/gpu/drm/msm/dsi/dsi_host.c:1870:44: note: initialize the variable 'device_node' to silence this warning
          struct device_node *endpoint, *device_node;
                                                    ^
                                                    = NULL
  1 error generated.

device_node's assignment was removed but not all of its uses. Remove the
call to of_node_put() and the variable declaration to clean up the
warning.

Fixes: 36246dd50225 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")
Link: https://github.com/ClangBuiltLinux/linux/issues/1700Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/500182/
Link: https://lore.kernel.org/r/20220829165450.217628-1-nathan@kernel.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and dropping support for
handling the panel directly.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/493608/
Link: https://lore.kernel.org/r/20220712132258.671263-1-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

Now that struct mipi_dsi_device provides DSC data, fetch it from the
mentioned struct rather than from the struct drm_panel itself. This
would allow supporting MIPI DSI bridges handling DSC on their input
side.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/493307/
Link: https://lore.kernel.org/r/20220711094320.368062-3-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

Return the value msm_dsi_phy_enable() directly instead of storing it in
another redundant variable.
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: Nye xingchen <ye.xingchen@zte.com.cn>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/499621/
Link: https://lore.kernel.org/r/20220826072821.253150-1-ye.xingchen@zte.com.cnSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

It makes no sense to have the HPD worker in the MSM DSI driver anymore.
It is only queued from the dsi_host_attach/detach() callbacks, where
it plays no useful role. Either way the panel or next bridge will be
present and will report it's status directly.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/498740/
Link: https://lore.kernel.org/r/20220822174417.292926-1-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

The dsi_phy_driver_probe() function has a "goto fail" for no
reason. Change it to just always return directly when it sees an
error. Make this simpler by leveraging dev_err_probe() which is
designed to make code like this shorter / simpler.

NOTE: as part of this, we now pass through error codes directly from
msm_ioremap_size() rather than translating to -ENOMEM. This changed
mostly because it's much more convenient when using dev_err_probe()
and also it's usually encouraged not to hide error codes like the old
code was doing unless there is a good reason. I can't see any reason
why we'd need to return -ENOMEM instead of -EINVAL from the probe
function.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/496324/
Link: https://lore.kernel.org/r/20220804073608.v4.6.I969118a35934a0e5007fe4f80e3e28e9c0b7602a@changeidSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

As of the commit 1de452a0 ("regulator: core: Allow drivers to
define their init data as const") we no longer need to do copying of
regulator bulk data from initdata to something dynamic. Let's take
advantage of that.

In addition to saving some code, this also moves us to using
ARRAY_SIZE() to specify how many regulators we have which is less
error prone.

This gets rid of some layers of wrappers which makes it obvious that
we can get rid of an extra error print.
devm_regulator_bulk_get_const() prints errors for you so you don't
need an extra layer of printing.

In all cases here I have preserved the old settings without any
investigation about whether the loads being set are sensible. In the
cases of some of the PHYs if several PHYs in the same file used
exactly the same settings I had them point to the same data structure.

NOTE: Though I haven't done the math, this is likely an overall
savings in terms of "static const" data. We previously always
allocated space for 8 supplies. Each of these supplies took up 36
bytes of data (32 for name, 4 for an int).
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/496325/
Link: https://lore.kernel.org/r/20220804073608.v4.5.I55a9e65cb1c22221316629e98768ff473f47a067@changeidSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

As of commit 6eabfc01 ("regulator: core: Allow specifying an
initial load w/ the bulk API") we can now specify the initial load in
the bulk data rather than having to manually call regulator_set_load()
on each regulator. Let's use it.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/496319/
Link: https://lore.kernel.org/r/20220804073608.v4.4.I7b3c72949883846badb073cfeae985c55239da1d@changeidSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

As of commit 5451781d ("regulator: core: Only count load for
enabled consumers"), a load isn't counted for a disabled
regulator. That means all the code in the DSI driver to specify and
set loads before disabling a regulator is not actually doing anything
useful. Let's remove it.

It should be noted that all of the loads set that were being specified
were pointless noise anyway. The only use for this number is to pick
between low power and high power modes of regulators. Regulators
appear to do this changeover at loads on the order of 10000 uA. You
would need a lot of clients of the same rail for that 100 uA number to
count for anything.

Note that now that we get rid of the setting of the load at disable
time, we can just set the load once when we first get the regulator
and then forget it.

It should also be noted that the regulator functions
regulator_bulk_enable() and regulator_set_load() already print error
messages when they encounter problems so while moving things around we
get rid of some extra error prints.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/496320/
Link: https://lore.kernel.org/r/20220804073608.v4.3.If1f94fbbdb7c1d0fb3961de61483a851ad1971a7@changeidSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

parent_hw pointers are easier to manage and cheaper to use than
repeatedly formatting the parent name and subsequently leaving the clk
framework to perform lookups based on that name.
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/491927/
Link: https://lore.kernel.org/r/20220629225331.357308-12-marijn.suijten@somainline.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

parent_hw pointers are easier to manage and cheaper to use than
repeatedly formatting the parent name and subsequently leaving the clk
framework to perform lookups based on that name.
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/491923/
Link: https://lore.kernel.org/r/20220629225331.357308-11-marijn.suijten@somainline.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

parent_hw pointers are easier to manage and cheaper to use than
repeatedly formatting the parent name and subsequently leaving the clk
framework to perform lookups based on that name.
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/491921/
Link: https://lore.kernel.org/r/20220629225331.357308-10-marijn.suijten@somainline.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

parent_hw pointers are easier to manage and cheaper to use than
repeatedly formatting the parent name and subsequently leaving the clk
framework to perform lookups based on that name.
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/491925/
Link: https://lore.kernel.org/r/20220629225331.357308-9-marijn.suijten@somainline.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

parent_hw pointers are easier to manage and cheaper to use than
repeatedly formatting the parent name and subsequently leaving the clk
framework to perform lookups based on that name.
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/491929/
Link: https://lore.kernel.org/r/20220629225331.357308-8-marijn.suijten@somainline.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

Now that the last DSI PHY PLL driver (dsi_phy_28nm_8960) has been
converted to use a simple stack-local char-array instead of a
devm_kzalloc heap allocation we can safely call sizeof() on every string
variable (that's now a sized array instead of a pointer) passed into
snprintf instead of hardcoding the size.
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/491920/
Link: https://lore.kernel.org/r/20220629225331.357308-7-marijn.suijten@somainline.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

The clock names formatted into the hw_clk's init structure are only used
for the duration of the registration function where they are kstrdup'ed,
making it unnecessary to keep the allocations alive for the duration of
the device (through devm).

Just like the other DSI PHY PLL clock trees, use a stack-local char
array and save on memory outside of the pll_28nm_register function.
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/491917/
Link: https://lore.kernel.org/r/20220629225331.357308-6-marijn.suijten@somainline.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

The commit 613cbd1d ("drm/msm/dsi: use devm_clk_*register to registe
DSI PHY clocks") introduced the devm_ prefix to clk_hw registration
calls, without updating the indentation of the arguments on the
following lines.

Similarly commit e55b3fbb ("drm/msm/dsi: drop PLL accessor
functions") moved from pll_write to dsi_phy_write without updating the
indentation of followup arguments either.

Preparing for a series that heavily touches the clk calls, reflow and
reindent function calls that are adhering to an 80-char column limit by
spanning multiple lines.  Where function names are very long the
arguments are indented with a fixed number of two tab characters instead
of aligning with the opening parenthesis of the function call.
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/491931/
Link: https://lore.kernel.org/r/20220629225331.357308-5-marijn.suijten@somainline.org
[DB: adjusted commit message to make checkpatch happy]
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>

At current implementation there is an extra 0 at 1.62G link rate which
cause no correct pixel_div selected for 1.62G link rate to calculate
mvid and nvid. This patch delete the extra 0 to have mvid and nvid be
calculated correctly.

Changes in v2:
-- fix Fixes tag's text

Changes in v3:
-- fix misspelling of "Reviewed-by"

Fixes: 937f941c  ("drm/msm/dp: Use qmp phy for DP PLL and PHY")
Signed-off-by: NKuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/499328/
Link: https://lore.kernel.org/r/1661372150-3764-1-git-send-email-quic_khsieh@quicinc.com
[DB: rewrapped commit message]
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NRob Clark <robdclark@chromium.org>