Kuogee Hsieh [Thu, 11 Aug 2022 22:57:50 +0000 (15:57 -0700)]
drm/msm/dp: delete DP_RECOVERED_CLOCK_OUT_EN to fix tps4
Data Symbols scrambled is required for tps4 at link training 2.
Therefore SCRAMBLING_DISABLE bit should not be set for tps4 to
work.
RECOVERED_CLOCK_OUT_EN is for enable simple EYE test for jitter
measurement with minimal equipment for embedded applications purpose
and is not required to be set during normal operation. Current
implementation always have RECOVERED_CLOCK_OUT_EN bit set which
cause SCRAMBLING_DISABLE bit wrongly set at tps4 which prevent
tps4 from working.
This patch delete setting RECOVERED_CLOCK_OUT_EN to fix
SCRAMBLING_DISABLE be wrongly set at tps4.
Changes in v2:
-- fix Fixes tag
Changes in v3:
-- revise commit text
Changes in v4:
-- fix commit text newline
Changes in v5:
-- fix commit text line over 75 chars
drm/msm/dp: make eDP panel as the first connected connector
Some userspace presumes that the first connected connector is the main
display, where it's supposed to display e.g. the login screen. For
laptops, this should be the main panel.
This patch call drm_helper_move_panel_connectors_to_head() after
drm_bridge_connector_init() to make sure eDP stay at head of
connected connector list. This fixes unexpected corruption happen
at eDP panel if eDP is not placed at head of connected connector
list.
Changes in v2:
-- move drm_helper_move_panel_connectors_to_head() to
dpu_kms_drm_obj_init()
Changes in v4:
-- move drm_helper_move_panel_connectors_to_head() to msm_drm_init()
Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Fixes: ef7837ff091c ("drm/msm/dp: Add DP controllers for sc7280")
Patchwork: https://patchwork.freedesktop.org/patch/492581/ Link: https://lore.kernel.org/r/1657135928-31195-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Rob Clark [Thu, 7 Jul 2022 21:20:00 +0000 (14:20 -0700)]
drm/msm/dpu: Fix for non-visible planes
Fixes `kms_cursor_crc --run-subtest cursor-offscreen`.. when the cursor
moves offscreen the plane becomes non-visible, so we need to skip over
it in crtc atomic test and mixer setup.
Fixes: d59be579fa93 ("drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/492701/ Link: https://lore.kernel.org/r/20220707162040.1594855-1-robdclark@gmail.com
Rob Clark [Sat, 25 Jun 2022 22:54:36 +0000 (15:54 -0700)]
drm/msm: Switch to pfn mappings
I'm not entirely sure why we were using VM_MIXEDMAP. These are never
CoW mappings. Let's switch to be more consistent with what other
drivers and the GEM shmem helpers do.
Rob Clark [Mon, 13 Jun 2022 18:20:30 +0000 (11:20 -0700)]
drm/msm/adreno: Defer enabling runpm until hw_init()
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.
Rob Clark [Mon, 13 Jun 2022 20:50:32 +0000 (13:50 -0700)]
drm/msm/gem: Drop obj lock in msm_gem_free_object()
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).
Dmitry Baryshkov [Fri, 17 Jun 2022 23:24:33 +0000 (02:24 +0300)]
drm/msm/dp: rename second dp_display_enable()'s argument
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().
Rob Clark [Wed, 29 Jun 2022 21:19:16 +0000 (14:19 -0700)]
drm/msm/gpu: Add GEM debug label to devcore
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.
Rob Clark [Wed, 29 Jun 2022 21:19:15 +0000 (14:19 -0700)]
drm/msm/gpu: Capture all BO addr+size in devcore
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.
Dmitry Baryshkov [Thu, 16 Jun 2022 08:11:06 +0000 (11:11 +0300)]
drm/msm: switch msm_kms_init_aspace() to use device_iommu_mapped()
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: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489703/ Link: https://lore.kernel.org/r/20220616081106.350262-6-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
Dmitry Baryshkov [Thu, 16 Jun 2022 08:11:04 +0000 (11:11 +0300)]
drm/msm: Stop using iommu_present()
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: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/489699/ Link: https://lore.kernel.org/r/20220616081106.350262-4-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
Dmitry Baryshkov [Thu, 16 Jun 2022 08:11:03 +0000 (11:11 +0300)]
drm/msm/mdp5: move iommu_domain_alloc() call close to its usage
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: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489695/ Link: https://lore.kernel.org/r/20220616081106.350262-3-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
Dmitry Baryshkov [Thu, 16 Jun 2022 08:11:02 +0000 (11:11 +0300)]
drm/msm/dpu: check both DPU and MDSS devices for the IOMMU
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: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489696/ Link: https://lore.kernel.org/r/20220616081106.350262-2-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Wed, 15 Jun 2022 16:35:28 +0000 (09:35 -0700)]
drm/msm: Fix %d vs %u
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.
drm/msm/dpu: move struct dpu_hw_blk definition to dpu_hw_utils.h
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.
drm/msm/dpu: merge base_off with blk_off in struct dpu_hw_blk_reg_map
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.
Rob Clark [Sun, 29 May 2022 18:04:23 +0000 (11:04 -0700)]
drm/msm/adreno: Allow larger address space size
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)
Konrad Dybcio [Sat, 28 May 2022 16:03:51 +0000 (18:03 +0200)]
drm/msm/adreno: Fix up formatting
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.
Konrad Dybcio [Sat, 28 May 2022 16:03:50 +0000 (18:03 +0200)]
drm/msm/a6xx: Add speedbin support for A619 GPU
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.
Douglas Anderson [Fri, 10 Jun 2022 19:47:31 +0000 (12:47 -0700)]
drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy
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: eadf79286a4b ("drm/msm: Check for powered down HW in the devfreq callbacks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/489124/ Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
Merge branches 'msm-next-lumag-core', 'msm-next-lumag-dpu', 'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-hdmi', 'msm-next-lumag-mdp5' and 'msm-next-lumag-mdp4' into msm-next-lumag
Changes in this merge:
Core:
- client utilization via fdinfo support
- fix fence rollover issue
DPU:
- constification of HW catalog
- support for using encoder as CRC source
- WB support on sc7180
- WB resolution fixes
- enable DSPP support for sc7280
DP:
- dropped custom bulk clock implementation
- made dp_bridge_mode_valid() return MODE_CLOCK_HIGH where applicable
- fix link retraining on resolution change
MDP5:
- MSM8953 perf data
HDMI:
- YAML'ification of schema
- dropped obsolete GPIO support
- misc cleanups
Wan Jiabing [Tue, 26 Apr 2022 13:21:26 +0000 (21:21 +0800)]
drm/msm: Use div64_ul instead of do_div
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.
Rob Clark [Thu, 9 Jun 2022 17:42:12 +0000 (10:42 -0700)]
drm/msm: Expose client engine utilization via fdinfo
Similar to AMD commit 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.
drm/msm/mdp4: get rid of struct mdp4_platform_config
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.
drm/msm/mdp4: move iommu_domain_alloc() call close to its usage
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.
Dmitry Baryshkov [Thu, 16 Jun 2022 08:50:57 +0000 (11:50 +0300)]
drm/msm/hdmi: support attaching the "next" bridge
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.
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.
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.
drm/msm/hdmi: enable core-vcc/core-vdda-supply for 8996 platform
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: 0afbe59edd3f ("drm/msm/hdmi: Add basic HDMI support for msm8996") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/488857/ Link: https://lore.kernel.org/r/20220609122350.3157529-8-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
The HDMI driver has code to configure extra GPIOs, which predates
pinctrl support. Nowadays all platforms should use pinctrl instead.
Neither of upstreamed Qualcomm platforms uses these properties, so it's
safe to drop them.
dt-bindings: display/msm: hdmi: mark hdmi-mux-supply as deprecated
hdmi-mux-supply is not used by the SoC's HDMI block, it is thought to
power up the external logic. Thus it should not be a part of HDMI
bindings, but it should be declared at some other device in the DT (like
HDMI mux, bridge, etc). Mark it as deprecated.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/488870/ Link: https://lore.kernel.org/r/20220609122350.3157529-4-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
dt-bindings: display/msm: hdmi: split and convert to yaml
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- dropped qcom,tx-ddc-* from example, they were not documented
- make phy-names deprecated, drop it from the examples
PHY:
- moved into phy/ directory
- split into QMP and non-QMP PHY schemas
Co-developed-by: David Heidelberg <david@ixit.cz> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/488850/ Link: https://lore.kernel.org/r/20220609122350.3157529-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Dmitry Baryshkov [Mon, 27 Jun 2022 16:54:13 +0000 (19:54 +0300)]
drm/msm/dp: use ARRAY_SIZE for calculating num_descs
If for some reason the msm_dp_config::descs array starts from non-zero
index or contains the hole, setting the msm_dp_config::num_descs might
be not that obvious and error-prone. Use ARRAY_SIZE to set this field
rather than encoding the value manually.
Vladimir Lypak [Fri, 10 Jun 2022 22:02:57 +0000 (00:02 +0200)]
drm/msm/dsi: Use single function for reset
There is currently two function for performing reset: dsi_sw_reset and
dsi_sw_reset_restore. Only difference between those is that latter one
assumes that DSI controller is enabled. In contrary former one assumes
that controller is disabled and executed during power-on. However this
assumtion is not true mobile devices which have boot splash set up by
boot-loader.
This patch removes dsi_sw_reset_restore and makes dsi_sw_reset disable
DSI controller during reset sequence if it's enabled.
Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489152/ Link: https://lore.kernel.org/r/20220610220259.220622-1-luca@z3ntu.xyz
[DB: fixed the typo in the commit message] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Conversion to use bulk regulator API omitted filling the pwr_regs with
proper regulator IDs. This was left unnoticed, since none of my testing
platforms has used the pwr_regs. Fix this by propagating regulator ids
properly.
Dmitry Baryshkov [Wed, 15 Jun 2022 11:59:20 +0000 (14:59 +0300)]
drm/msm/dp: make dp_bridge_mode_valid() more precise
Make dp_connector_mode_valid() return precise MODE_CLOCK_HIGH rather
than generic MODE_BAD in case the mode clock is higher than
DP_MAX_PIXEL_CLK_KHZ (675 MHz).
Douglas Anderson [Mon, 25 Apr 2022 21:06:42 +0000 (14:06 -0700)]
dt-bindings: msm/dp: List supplies in the bindings
We're supposed to list the supplies in the dt bindings but there are
none in the DP controller bindings. Looking at the Linux driver and
existing device trees, we can see that two supplies are expected:
- vdda-0p9-supply
- vdda-1p2-supply
Let's list them both in the bindings. Note that the datasheet for
sc7280 doesn't describe these supplies very verbosely. For the 0p9
supply, for instance, it says "Power for eDP 0.9 V circuits". This
this is obvious from the property name, we don't bother cluttering the
bindings with a description.
Jessica Zhang [Wed, 22 Jun 2022 17:18:35 +0000 (10:18 -0700)]
drm/msm/dpu: Add interface support for CRC debugfs
Add support for writing CRC values for the interface block to
the debugfs by calling the necessary MISR setup/collect methods.
Changes since V1:
- Set values_cnt to only include phys with backing hw_intf
- Loop over all drm_encs connected to crtc
Changes since V2:
- Remove vblank.h inclusion
- Change `pos + i` to `pos + entries`
- Initialize values_cnt to 0 for encoder
- Change DPU_CRTC_CRC_SOURCE_INTF to DPU_CRTC_CRC_SOURCE_ENCODER (and
"intf" to "enc")
- Change dpu_encoder_get_num_phys to dpu_encoder_get_num_hw_intfs
- Add checks for setup_misr and collect_misr in
dpu_encoder_get_num_hw_intfs
Changes since V3:
- Remove extra whitespace
- Change "enc" to "encoder"
- Move crcs array to dpu_crtc_get_encoder_crc
- Rename dpu_encoder_get_num_hw_intfs to dpu_encoder_get_crc_values_cnt
Dmitry Baryshkov [Thu, 17 Feb 2022 05:55:27 +0000 (08:55 +0300)]
drm/msm/dp: set stream_pixel rate directly
The only clock for which we set the rate is the "stream_pixel". Rather
than storing the rate and then setting it by looping over all the
clocks, set the clock rate directly.
"ctrl_link" is the clock from DP_CTRL_PM module. The result of setting
the rate for it would be a call to dev_pm_opp_set_rate(). Instead of
saving the rate inside struct dss_module_power, call the
devm_pm_opp_set_rate() directly.
Jessica Zhang [Wed, 22 Jun 2022 17:18:32 +0000 (10:18 -0700)]
drm/msm/dpu: Move LM CRC code into separate method
Move layer mixer-specific section of dpu_crtc_get_crc() into a separate
helper method. This way, we can make it easier to get CRCs from other HW
blocks by adding other get_crc helper methods.
Changes since V1:
- Move common bitmasks to dpu_hw_util.h
- Move common CRC methods to dpu_hw_util.c
- Update copyrights
- Change crcs array to a dynamically allocated array and added it as a
member of crtc_state
Changes since V2:
- Put changes for hw_util into a separate commit
- Revert crcs array to a static array
- Add else case for set_crc_source to return EINVAL if no valid source
is selected
- Add DPU_CRTC_MAX_CRC_ENTRIES macro
Changes since V3:
- Move crcs array into dpu_crtc_get_lm_crc
- Remove comment about crcs array in dpu_crtc_state struct
- Revert `lm` rename
- Remove DPU_CRTC_MAX_CRC_ENTRIES macro
- Return EINVAL in dpu_crtc_get_crc if no valid CRC source is set
After the commit c46f0d69039c ("drm/msm: remove unused hotplug and edid
macros from msm_drv.h") the msm_display_caps enum contains two bits
describing whether the encoder should work in video or command mode.
Drop the enum and replace capabilities field in struct msm_display_info
with boolean is_cmd_mode field.
drm/msm/dpu: remove hwversion field from data structures
The driver should not depend on hw revision for detecting features.
Instead it should use features from the hw catalog. Drop the hwversion
field from struct dpu_mdss_cfg and struct dpu_hw_blk_reg_map.
drm/msm/dpu: use feature bit for LM combined alpha check
Rather than checking hwversion, follow the usual patter and add special
bit to the lm->features to check whether the LM has combined or separate
alpha registers. While we are at it, rename
dpu_hw_lm_setup_blend_config_sdm845() to
dpu_hw_lm_setup_blend_config_combined_alpha().
Kuogee Hsieh [Wed, 22 Jun 2022 19:55:31 +0000 (12:55 -0700)]
drm/msm/dp: reset drm_dev to NULL at dp_display_unbind()
During msm initialize phase, dp_display_unbind() will be called to undo
initializations had been done by dp_display_bind() previously if there is
error happen at msm_drm_bind. Under this kind of circumstance, drm_device
may not be populated completed which causes system crash at drm_dev_dbg().
This patch reset drm_dev to NULL so that following drm_dev_dbg() will not
refer to any internal fields of drm_device to prevent system from crashing.
Below are panic stack trace,
Stephen Boyd [Wed, 22 Jun 2022 02:38:55 +0000 (19:38 -0700)]
drm/msm/dpu: Increment vsync_cnt before waking up userspace
The 'vsync_cnt' is used to count the number of frames for a crtc.
Unfortunately, we increment the count after waking up userspace via
dpu_crtc_vblank_callback() calling drm_crtc_handle_vblank().
drm_crtc_handle_vblank() wakes up userspace processes that have called
drm_wait_vblank_ioctl(), and if that ioctl is expecting the count to
increase it won't.
Increment the count before calling into the drm APIs so that we don't
have to worry about ordering the increment with anything else in drm.
This fixes a software video decode test that fails to see frame counts
increase on Trogdor boards.
Kuogee Hsieh [Thu, 16 Jun 2022 20:26:40 +0000 (13:26 -0700)]
drm/msm/dp: force link training for display resolution change
Display resolution change is implemented through drm modeset. Older
modeset (resolution) has to be disabled first before newer modeset
(resolution) can be enabled. Display disable will turn off both
pixel clock and main link clock so that main link have to be
re-trained during display enable to have new video stream flow
again. At current implementation, display enable function manually
kicks up irq_hpd_handle which will read panel link status and start
link training if link status is not in sync state.
However, there is rare case that a particular panel links status keep
staying in sync for some period of time after main link had been shut
down previously at display disabled. In this case, main link retraining
will not be executed by irq_hdp_handle(). Hence video stream of newer
display resolution will fail to be transmitted to panel due to main
link is not in sync between host and panel.
This patch will bypass irq_hpd_handle() in favor of directly call
dp_ctrl_on_stream() to always perform link training in regardless of
main link status. So that no unexpected exception resolution change
failure cases will happen. Also this implementation are more efficient
than manual kicking off irq_hpd_handle function.
Changes in v2:
-- set force_link_train flag on DP only (is_edp == false)
Changes in v3:
-- revise commit text
-- add Fixes tag
Changes in v4:
-- revise commit text
Changes in v5:
-- fix spelling at commit text
Changes in v6:
-- split dp_ctrl_on_stream() for phy test case
-- revise commit text for modeset
Changes in v7:
-- drop 0 assignment at local variable (ret = 0)
Changes in v8:
-- add patch to remove pixel_rate from dp_ctrl
Changes in v9:
-- forward declare dp_ctrl_on_stream_phy_test_report()
Fixes: 62671d2ef24b ("drm/msm/dp: fixes wrong connection state caused by failure of link train") Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489895/ Link: https://lore.kernel.org/r/1655411200-7255-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Rob Clark <robdclark@chromium.org>
Abhinav Kumar [Thu, 16 Jun 2022 19:26:46 +0000 (12:26 -0700)]
drm/msm/dpu: limit wb modes based on max_mixer_width
As explained in [1], using max_linewidth to limit the modes
does not seem to remove 4K modes on chipsets such as
sm8250 where the max_linewidth actually supports 4k.
This would have been alright if dual SSPP support was
present but otherwise fails the per SSPP bandwidth check.
The ideal way to implement this would be to filter out
the modes which will exceed the bandwidth check by computing
it.
But this would be an exhaustive solution till we have
dual SSPP support.
Let's instead use max_mixer_width to limit the modes.
max_mixer_width still remains 2560 on sm8250 so even if
the max_linewidth is 4096, the only way 4k modes could have
been supported is to have source split enabled on the SSPP.
Since source split support is not enabled yet in DPU driver,
enforce max_mixer_width as the upper limit on the modes.
Kuogee Hsieh [Mon, 6 Jun 2022 17:55:39 +0000 (10:55 -0700)]
drm/msm/dp: check core_initialized before disable interrupts at dp_display_unbind()
During msm initialize phase, dp_display_unbind() will be called to undo
initializations had been done by dp_display_bind() previously if there is
error happen at msm_drm_bind. In this case, core_initialized flag had to
be check to make sure clocks is on before update DP controller register
to disable HPD interrupts. Otherwise system will crash due to below NOC
fatal error.
changes in v2:
-- drop the first patch (drm/msm: enable msm irq after all initializations are done successfully at msm_drm_init()) since the problem had been fixed by other patch
Fixes: 570d3e5d28db ("drm/msm/dp: stop event kernel thread when DP unbind") Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/488387/ Link: https://lore.kernel.org/r/1654538139-7450-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Rob Clark <robdclark@chromium.org>
Miaoqian Lin [Tue, 7 Jun 2022 11:08:38 +0000 (15:08 +0400)]
drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf
of_graph_get_remote_node() returns remote device node pointer with
refcount incremented, we should use of_node_put() on it
when not need anymore.
Add missing of_node_put() to avoid refcount leak.
Fixes: 86418f90a4c1 ("drm: convert drivers to use of_graph_get_remote_node") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/488473/ Link: https://lore.kernel.org/r/20220607110841.53889-1-linmq006@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Sat, 18 Jun 2022 16:11:19 +0000 (09:11 -0700)]
drm/msm: Don't overwrite hw fence in hw_init
Prior to the last commit, this could result in setting the GPU
written fence value back to an older value, if we had missed
updating completed_fence prior to suspend. This was mostly
harmless as the GPU would eventually overwrite it again with
the correct value. But we should just not do this. Instead
just leave a sanity check that the fence looks plausible (in
case the GPU scribbled on memory).
Rob Clark [Sat, 18 Jun 2022 16:11:18 +0000 (09:11 -0700)]
drm/msm: Drop update_fences()
I noticed while looking at some traces, that we could miss calls to
msm_update_fence(), as the irq could have raced with retire_submits()
which could have already popped the last submit on a ring out of the
queue of in-flight submits. But walking the list of submits in the
irq handler isn't really needed, as dma_fence_is_signaled() will dtrt.
So lets just drop it entirely.
v2: use spin_lock_irqsave/restore as we are no longer protected by the
spin_lock_irqsave/restore() in update_fences()
Rob Clark [Fri, 10 Jun 2022 17:20:55 +0000 (10:20 -0700)]
drm/msm/gem: Drop early returns in close/purge vma
Keep the warn, but drop the early return. If we do manage to hit this
sort of issue, skipping the cleanup just makes things worse (dangling
drm_mm_nodes when the msm_gem_vma is freed, etc). Whereas the worst
that happens if we tear down a mapping the GPU is accessing is that we
get GPU iova faults, but otherwise the world keeps spinning.
Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Steev Klimaszewski <steev@kali.org> Reported-by: Steev Klimaszewski <steev@kali.org>
Patchwork: https://patchwork.freedesktop.org/patch/489115/ Link: https://lore.kernel.org/r/20220610172055.2337977-1-robdclark@gmail.com
Rob Clark [Fri, 27 May 2022 17:23:40 +0000 (10:23 -0700)]
drm/msm/gem: Separate object and vma unpin
Previously the BO_PINNED state in the submit was tracking two related
but different things: (1) that the buffer object was pinned, and (2)
that the vma (mapping within a set of pagetables) was pinned. But with
fenced vma unpin (needed so that userspace couldn't race with retire
path for releasing a vma) these two were decoupled. The fact that the
BO_PINNED flag was already cleared meant that we leaked the bo pin count
which should have been dropped when the submit was retired.
So split this state into BO_OBJ_PINNED and BO_VMA_PINNED, so they can be
dropped independently.
projects / thirdparty / linux.git / log
