-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJil/W4AAoJEJMTUIYYBUIppm4H/1lqhAzQhbMSM8TDA5LUI2+2
e09mvq7KsZo30uHazCRwnci8AahDWFenfQ78LVOosQHGSXtSYpsgVs0czMWXvRlE
fPNlo75eAwPENNzux2Uo1K3uT32N0oeia0yYJqTzYuZg0Lmkx2cDPd4alUokXqaK
8J+6xJsY2d3YM0xl5gIFmM9gifd+jGFYrVsiEY8Dwr59zkdmoMD9/QIi5ZsWXH7G
LCJA6NUqr31TLrGA7hV/GAME9IFjxNWNotYLjxsoAUn5FPhwHY7EeJsloLJEl4HP
UCDJ47SfLfvYjUHeBXvUDbzTD2FPpWuDhharEqyLtStcVQjnpJCOZOO2e52qqMo=
=PgRN
-----END PGP SIGNATURE-----
Merge tag 'msm-next-5.19-fixes-06-01' of https://gitlab.freedesktop.org/abhinavk/msm into drm-next
5.19 fixes for msm-next
- Fix to add minimum ICC vote in the msm_mdss pm_resume path to address
bootup splats
- Fix to avoid dereferencing without checking in WB encoder
- Fix to avoid crash during suspend in DP driver by ensuring interrupt
mask bits are updated
- Remove unused code from dpu_encoder_virt_atomic_check()
- Fix to remove redundant init of dsc variable
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/927b201e-a734-a29d-b9fb-b9889e1f7795@quicinc.com
In commit a670ff578f ("drm/msm/dpu: always use mdp device to scale
bandwidth") we fully moved interconnect stuff to the DPU driver. This
had no change for sc7180 but _did_ have an impact for other SoCs. It
made them match the sc7180 scheme.
Unfortunately, the sc7180 scheme seems like it was a bit broken.
Specifically the interconnect needs to be on for more than just the
DPU driver's AXI bus. In the very least it also needs to be on for the
DSI driver's AXI bus. This can be seen fairly easily by doing this on
a ChromeOS sc7180-trogdor class device:
set_power_policy --ac_screen_dim_delay=5 --ac_screen_off_delay=10
sleep 10
cd /sys/bus/platform/devices/ae94000.dsi/power
echo on > control
When you do that, you'll get a warning splat in the logs about
"gcc_disp_hf_axi_clk status stuck at 'off'".
One could argue that perhaps what I have done above is "illegal" and
that it can't happen naturally in the system because in normal system
usage the DPU is pretty much always on when DSI is on. That being
said:
* In official ChromeOS builds (admittedly a 5.4 kernel with backports)
we have seen that splat at bootup.
* Even though we don't use "autosuspend" for these components, we
don't use the "put_sync" variants. Thus plausibly the DSI could stay
"runtime enabled" past when the DPU is enabled. Techncially we
shouldn't do that if the DPU's suspend ends up yanking our clock.
Let's change things such that the "bare minimum" request for the
interconnect happens in the mdss driver again. That means that all of
the children can assume that the interconnect is on at the minimum
bandwidth. We'll then let the DPU request the higher amount that it
wants.
It should be noted that this isn't as hacky of a solution as it might
initially appear. Specifically:
* Since MDSS and DPU individually get their own references to the
interconnect then the framework will actually handle aggregating
them. The two drivers are _not_ clobbering each other.
* When the Qualcomm interconnect driver aggregates it takes the max of
all the peaks. Thus having MDSS request a peak, as we're doing here,
won't actually change the total interconnect bandwidth (it won't be
added to the request for the DPU). This perhaps explains why the
"average" requested in MDSS was historically 0 since that one
_would_ be added in.
NOTE also that in the downstream ChromeOS 5.4 and 5.15 kernels, we're
also seeing some RPMH hangs that are addressed by this fix. These
hangs are showing up in the field and on _some_ devices with enough
stress testing of suspend/resume. Specifically right at suspend time
with a stack crawl that looks like this (from chromeos-5.15 tree):
rpmh_write_batch+0x19c/0x240
qcom_icc_bcm_voter_commit+0x210/0x420
qcom_icc_set+0x28/0x38
apply_constraints+0x70/0xa4
icc_set_bw+0x150/0x24c
dpu_runtime_resume+0x50/0x1c4
pm_generic_runtime_resume+0x30/0x44
__genpd_runtime_resume+0x68/0x7c
genpd_runtime_resume+0x12c/0x20c
__rpm_callback+0x98/0x138
rpm_callback+0x30/0x88
rpm_resume+0x370/0x4a0
__pm_runtime_resume+0x80/0xb0
dpu_kms_enable_commit+0x24/0x30
msm_atomic_commit_tail+0x12c/0x630
commit_tail+0xac/0x150
drm_atomic_helper_commit+0x114/0x11c
drm_atomic_commit+0x68/0x78
drm_atomic_helper_disable_all+0x158/0x1c8
drm_atomic_helper_suspend+0xc0/0x1c0
drm_mode_config_helper_suspend+0x2c/0x60
msm_pm_prepare+0x2c/0x40
pm_generic_prepare+0x30/0x44
genpd_prepare+0x80/0xd0
device_prepare+0x78/0x17c
dpm_prepare+0xb0/0x384
dpm_suspend_start+0x34/0xc0
We don't completely understand all the mechanisms in play, but the
hang seemed to come and go with random factors. It's not terribly
surprising that the hang is gone after this patch since the line of
code that was failing is no longer present in the kernel.
Fixes: a670ff578f ("drm/msm/dpu: always use mdp device to scale bandwidth")
Fixes: c33b7c0389 ("drm/msm/dpu: add support for clk and bw scaling for display")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # RB3 (sdm845) and
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/487884/
Link: https://lore.kernel.org/r/20220531160059.v2.1.Ie7f6d4bf8cce28131da31a43354727e417cae98d@changeid
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Commit 58dca98107 ("drm/msm/disp/dpu1: Add support for DSC in
encoder") added dsc_common_mode variable which was set to zero but then
again programmed, so drop the superfluous init.
Fixes: 58dca98107 ("drm/msm/disp/dpu1: Add support for DSC in encoder")
Reported-by: kernel test robot <yujie.liu@intel.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/487208/
Link: https://lore.kernel.org/r/20220525073912.2706505-1-vkoul@kernel.org
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJihZ6hAAoJEJMTUIYYBUIphx8IAJZ+8FJ+qjCne0GaVFGczjFr
cz1PVE7CAXWlgA+1V/xSw7Awt0oPhrB400SRh/2bea8awHkKZxtcnBIA1apEoDjo
+qyhHMpwcItCHQM5xOKKGZb0KU+MCK9/6PH5VjD8k1gX52OoxQ4e0uUng7ljVgCe
F/LBBpW6oY6ZAiZxaxieXSD36bNkwhYXdYGWdJFQPQF+N4gYPmSWOmijaRnkJtnv
o4VS5HnTN3FMgKu+h2Rr7r4A5s7WygVJM7K+sbJZI/F+OCFv3lftkU2JOXGtS2oc
5sInJB972aafkD3lOzTPyARiHrtvLpsSGPXok24b3suRN0pHRYtvAOdrI0m/sUg=
=y6Lb
-----END PGP SIGNATURE-----
Merge tag 'msm-next-5.19-fixes' of https://gitlab.freedesktop.org/abhinavk/msm into drm-next
5.19 fixes for msm-next
- Limiting WB modes to max sspp linewidth
- Fixing the supported rotations to add 180 back for IGT
- Fix to handle pm_runtime_get_sync() errors to avoid unclocked access
in the bind() path for dpu driver
- Fix the irq_free() without request issue which was a big-time
hitter in the CI-runs.
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b011d51d-d634-123e-bf5f-27219ee33151@quicinc.com
If there are errors while trying to enable the pm in the
bind path, it will lead to unclocked access of hw revision
register thereby crashing the device.
This will not address why the pm_runtime_get_sync() fails
but at the very least we should be able to prevent the
crash by handling the error and bailing out earlier.
changes in v2:
- use pm_runtime_resume_and_get() instead of
pm_runtime_get_sync()
Fixes: 25fdd5933e ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/486721/
Link: https://lore.kernel.org/r/20220518223407.26147-1-quic_abhinavk@quicinc.com
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
DRM_MODE_ROTATE_180 was previously marked as supported even
for devices not supporting inline rotation.
This is true because the SSPPs can always flip the image.
After inline rotation support changes, this bit was removed
and kms_rotation_crc IGT test starts skipping now whereas
it was previously passing.
Restore DRM_MODE_ROTATE_180 bit to the supported rotations
list.
Fixes: dabfdd89ea ("add inline rotation support for sc7280")
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # Trogdor (SC8170)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/485928/
Link: https://lore.kernel.org/r/20220511222710.22394-1-quic_abhinavk@quicinc.com
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Writeback modes were being added according to mode_config.max_width
but this is assigned to double of max_mixer_width.
For compositors/clients using a single SSPP, this will fail
the dpu_plane's atomic check as it checks for max_linewidth.
Limit writeback modes according to max_linewidth to allow
even compositors/clients which use only a single SSPP to
use writeback.
Fixes: 77b001acdc ("drm/msm/dpu: add the writeback connector layer")
Reported-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # Trogdor (SC8170)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/486176/
Link: https://lore.kernel.org/r/20220513225959.19004-1-quic_abhinavk@quicinc.com
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo
needs to be put when msm_gem_get_and_pin_iova fails.
Fixes: e172d10a9c ("drm/msm/mdp5: Add hardware cursor support")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Link: https://lore.kernel.org/r/20220509061125.18585-1-hbh25y@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
- Fourcc modifier for tiled but not compressed layouts
- Support for userspace allocated IOVA (GPU virtual address)
- Devfreq clamp_to_idle fix
- DPU: DSC (Display Stream Compression) support
- DPU: inline rotation support on SC7280
- DPU: update DP timings to follow vendor recommendations
- DP, DPU: add support for wide bus (on newer chipsets)
- DP: eDP support
- Merge DPU1 and MDP5 MDSS driver, make dpu/mdp device the master
component
- MDSS: optionally reset the IP block at the bootup to drop
bootloader state
- Properly register and unregister internal bridges in the DRM framework
- Complete DPU IRQ cleanup
- DP: conversion to use drm_bridge and drm_bridge_connector
- eDP: drop old eDP parts again
- DPU: writeback support
- Misc small fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvJCr_1D8d0dgmyQC5HD4gmXeZw=bFV_CNCfceZbpMxRw@mail.gmail.com
There is no need to check that kfree() argument is not NULL. Remove
extra check and call kfree() unconditionally.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220507114009.1696278-1-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
When rebooting on my sc7280-herobrine based device, I got a
crash. Upon debugging, I found that I was in msm_drv_shutdown() and my
"pdev" was the one associated with mdss_probe().
From source, I found that mdss_probe() has the line:
platform_set_drvdata(pdev, mdss);
...where "mdss" is of type "struct msm_mdss *".
Also from source, I saw that in msm_drv_shutdown() we have the line:
struct msm_drm_private *priv = platform_get_drvdata(pdev);
This is a mismatch and is the root of the problem.
Further digging made it apparent that msm_drv_shutdown() is only
supposed to be used for parts of the msm display framework that also
call msm_drv_probe() but mdss_probe() doesn't call
msm_drv_probe(). Let's remove the shutdown functon from msm_mdss.c.
Digging a little further, code inspection found that two drivers that
use msm_drv_probe() weren't calling msm_drv_shutdown(). Let's add it
to them.
Fixes: 6874f48bb8 ("drm/msm: make mdp5/dpu devices master components")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/484975/
Link: https://lore.kernel.org/r/20220504163900.v2.1.Iaebd35e60160fc0f2a50fac3a0bf3b298c0637c8@changeid
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
There is a possibility for mdp5_get_global_state to return
-EDEADLK when acquiring the modeset lock, but currently global_state in
mdp5_mixer_release doesn't check for if an error is returned.
To avoid a NULL dereference error, let's have mdp5_mixer_release
check if an error is returned and propagate that error.
Reported-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Fixes: 7907a0d77c ("drm/msm/mdp5: Use the new private_obj state")
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/485181/
Link: https://lore.kernel.org/r/20220505214051.155-2-quic_jesszhan@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
the modeset lock, but currently mdp5_pipe_release doesn't check for if
an error is returned. Because of this, there is a possibility of
mdp5_pipe_release hitting a NULL dereference error.
To avoid this, let's have mdp5_pipe_release check if
mdp5_get_global_state returns an error and propogate that error.
Changes since v1:
- Separated declaration and initialization of *new_state to avoid
compiler warning
- Fixed some spelling mistakes in commit message
Changes since v2:
- Return 0 in case where hwpipe is NULL as this is considered normal
behavior
- Added 2nd patch in series to fix a similar NULL dereference issue in
mdp5_mixer_release
Reported-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Fixes: 7907a0d77c ("drm/msm/mdp5: Use the new private_obj state")
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/485179/
Link: https://lore.kernel.org/r/20220505214051.155-1-quic_jesszhan@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Due to MSM8998 support having been stuck in review for so long,
another struct was added nearby, which confused git and resulted
in the definitions not being sorted alphabetically. Fix it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/484296/
Link: https://lore.kernel.org/r/20220430161529.605843-3-konrad.dybcio@somainline.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Move the initializer for the mode variable to the declaration point to
remove unitialized variable access from the DEBUG_DPU macro. This fixes
the following warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:250:37: note: initialize the variable 'mode' to silence this warning
Fixes: d7d0e73f7d ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/484346/
Link: https://lore.kernel.org/r/20220502082420.48409-1-dmitry.baryshkov@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
While there's a comment pointing from dpu_intr_set to dpu_hw_intr_reg
and vice-versa, an array initializer using indices makes it so that the
indices between the enum and array cannot possibly get out of sync even
if they're accidentially ordered wrongly. It is still useful to keep
the comment to be made aware where the register offset mapping resides
while looking at dpu_hw_intr_reg.
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/476358/
Link: https://lore.kernel.org/r/20220226194633.204501-1-marijn.suijten@somainline.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Currently, dpu_hw_lm_collect_misr returns EINVAL if CRC is disabled.
This causes a lot of spam in the DRM debug logs as it's called for every
vblank.
Instead of returning EINVAL when CRC is disabled in
dpu_hw_lm_collect_misr, let's return ENODATA and add an extra ENODATA check
before the debug log in dpu_crtc_get_crc.
Changes since V1:
- Added reported-by and suggested-by tags
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Suggested-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # RB5 (qrb5165)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/484274/
Link: https://lore.kernel.org/r/20220430005210.339-1-quic_jesszhan@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Set mdp clock to max clock rate during probe/bind sequence from the
opp table so that rails are not at undetermined state. Since we do not
know what will be the rate set in boot loader, it would be ideal to
vote at max frequency. There could be a firmware display programmed
in bootloader and we want to transition it to kernel without underflowing.
The clock will be scaled down later when framework sends an update.
Fixes: 25fdd5933e ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/479090/
Link: https://lore.kernel.org/r/1647919631-14447-2-git-send-email-quic_vpolimer@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Remove the unused local variable refcount for encoder_phys_wb
as the one part of wb_enc is used directly.
changes in v2:
- remove usage of ret variable also
- remove the if (ret) code as it was dead-code anyway
Fixes: d7d0e73f7d ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483919/
Link: https://lore.kernel.org/r/1651169759-29760-1-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Add wb_idx to existing DRM prints in dpu_encoder and also
print the intf_mode so that its clear that for any INTF_CMD/VID
there will be a valid intf_idx and any INTF_WB_* there will be a
valid wb_idx.
Update the debugfs to add the same information. Here is a sample
output with this change:
root:/sys/kernel/debug/dri/0/encoder31# cat status
intf:1 wb:-1 vsync: 31 underrun: 0 mode: INTF_MODE_VIDEO
root:/sys/kernel/debug/dri/0/encoder33# cat status
intf:-1 wb:2 vsync: 7 underrun: 0 mode: INTF_MODE_WB_LINE
Also remove DPU_DEBUG_PHYS macros as its unused because the
respective dpu_encoder_phys_* files have their own macros.
changes in v2:
- use switch case instead of if/else-if for get_intf_type
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483530/
Link: https://lore.kernel.org/r/1650984096-9964-19-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while closing the fb which results in the
callback to drm_atomic_helper_dirtyfb() which internally
triggers a commit.
Add protection in the dpu driver to ensure that commits for
writeback encoders without a valid fb are gracefully skipped.
changes in v2:
- rename dpu_encoder_has_valid_fb to dpu_encoder_is_valid_for_commit
changes in v3:
- none
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483522/
Link: https://lore.kernel.org/r/1650984096-9964-17-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
changes in v2:
- start initialing the encoder for writeback since we
have migrated to using drm_writeback_connector_init_with_encoder()
- instead of checking for WB_2 inside _dpu_kms_initialize_writeback
call it only when its WB_2
- rebase on tip of msm-next and remove usage of priv->encoders
changes in v3:
- none
changes in v4:
- fix copyright years order
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483526/
Link: https://lore.kernel.org/r/1650984096-9964-16-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.
This module manages the connector related operations for
dpu writeback.
changes in v2:
- start using drm_writeback_connector_init_with_encoder()
- drop unnecessary arguments from dpu_writeback_init()
- rebase on msm-next tip and remove usage of priv->connectors
changes in v3:
- none
changes in v4:
- none
changes in v5:
- store the drm_enc in the dpu_wb_conn to be used while
using dpu_encoder APIs
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483520/
Link: https://lore.kernel.org/r/1650984096-9964-15-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
_dpu_plane_get_qos_lut() is not specific to just dpu_plane.
It can take any fill level and return the LUT matching it.
This can be used even for other modules like dpu_writeback.
Move _dpu_plane_get_qos_lut() to the common dpu_hw_util file
and rename it to _dpu_hw_get_qos_lut().
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483518/
Link: https://lore.kernel.org/r/1650984096-9964-13-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
add dpu encoder APIs to prepare and cleanup writeback job
for the writeback encoder. These shall be invoked from the
prepare_wb_job/cleanup_wb_job hooks of the drm_writeback
framework.
changes in v3:
- none
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483516/
Link: https://lore.kernel.org/r/1650984096-9964-12-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all interfaces.
changes in v4:
- none
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483512/
Link: https://lore.kernel.org/r/1650984096-9964-10-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
changes in v3:
- start using the common struct dpu_hw_cdp_cfg
- leave a comment about DPU non-DPU_WB_QOS_8LVL chipsets
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483505/
Link: https://lore.kernel.org/r/1650984096-9964-7-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Rename dpu_hw_pipe_cdp_cfg to dpu_hw_cdp_cfg and move it
to dpu_hw_utils file so that other modules in addition to
SSPP such as writeback can use it as all the fields can
be used by writeback as well.
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483503/
Link: https://lore.kernel.org/r/1650984096-9964-6-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Add writeback blocks to the sm8250 DPU hardware catalog. Other
chipsets support writeback too but add it to sm8250 to prototype
the feature so that it can be easily extended to other chipsets.
changes in v4:
- fix the copyright year order
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/483510/
Link: https://lore.kernel.org/r/1650984096-9964-4-git-send-email-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
The irq_of_parse_and_map() function returns 0 on failure, and does not
return a negative value anyhow, so never enter this conditional branch.
Fixes: 25fdd5933e ("drm/msm: Add SDM845 DPU support")
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/483291/
Link: https://lore.kernel.org/r/20220425090947.3498897-1-lv.ruyi@zte.com.cn
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.
Co-developed-by: Kalyan Thota <quic_kalyant@quicinc.com>
Signed-off-by: Kalyan Thota <quic_kalyant@quicinc.com>
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/481672/
Link: https://lore.kernel.org/r/1649695021-19132-3-git-send-email-quic_vpolimer@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
As per the specification of DPU_CTL_ACTIVE_CFG the configuration of
active blocks should be proactively specified, and the pingpong block is
no different.
The downstream display driver [1] confirms this by also calling
bind_pingpong_blk on CTL_ACTIVE_CFG. Note that this else-if is always
entered, as setup_intf_cfg - unlike this mainline dpu driver that
combines both behind the same function pointer - is left NULL in favour
of using setup_intf_cfg_v1 when CTL_ACTIVE_CFG is set.
This solves continuous timeouts on at least the Qualcomm sm6125 SoC:
[drm:dpu_encoder_frame_done_timeout:2091] [dpu error]enc31 frame done timeout
[drm:_dpu_encoder_phys_cmd_handle_ppdone_timeout.isra.0] *ERROR* id:31 pp:0 kickoff timeout 0 cnt 1 koff_cnt 1
[drm:dpu_encoder_phys_cmd_prepare_for_kickoff] *ERROR* failed wait_for_idle: id:31 ret:-110 pp:0
In the same way this pingpong block should also be unbound followed by
an interface flush when the encoder is disabled, according to the
downstream display driver [2].
[1]: https://source.codeaurora.org/quic/la/platform/vendor/opensource/display-drivers/tree/msm/sde/sde_encoder_phys_cmd.c?h=LA.UM.9.16.r1-08500-MANNAR.0#n167
[2]: https://source.codeaurora.org/quic/la/platform/vendor/opensource/display-drivers/tree/msm/sde/sde_encoder.c?h=LA.UM.9.16.r1-08500-MANNAR.0#n2986
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/475874/
Link: https://lore.kernel.org/r/20220223114011.219044-1-marijn.suijten@somainline.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To remove possible confusion between (old) INTF_EDP and newer INTF_DP,
stop using INTF_EDP in DPU's code. Until the 8x74/8x84 SoCs are
supported by DPU driver, there is no point in using INTF_EDP.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/475560/
Link: https://lore.kernel.org/r/20220222062246.242577-5-dmitry.baryshkov@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
DPU driver never supported INTF_EDP, so let's drop the obsolete comment.
If at some point 8x74/8x84's INTF_EDP is ported to DPU driver,
corresponding handling will have to be ported too. Until that time, the
comment serves no purpose.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/475557/
Link: https://lore.kernel.org/r/20220222062246.242577-4-dmitry.baryshkov@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
