- 19 Feb, 2022 4 commits
-
-
Dmitry Baryshkov authored
Merge branches 'msm-next-lumag-core', 'msm-next-lumag-dpu', 'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-hdmi' and 'msm-next-lumag-mdp5' into msm-next-lumag
-
Dmitry Baryshkov authored
It is possible to supply display-connector (bridge) to the DP interface, add support for parsing it too. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220211224006.1797846-4-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Currently DP driver will allocate panel bridge for eDP panels. This supports only the following topology: - eDP encoder ⇒ eDP panel (wrapped using panel-bridge) Simplify this code to just check if there is any next bridge in the chain (be it a panel bridge or regular bridge). Rename panel_bridge field to next_bridge accordingly. This allows one to use e.g. one of the following display topologies: - eDP encoder ⇒ ptn3460 ⇒ fixed LVDS panel - eDP encoder ⇒ ptn3460 ⇒ LVDS connector with EDID lines for panel autodetect - eDP encoder ⇒ ptn3460 ⇒ THC63LVD1024 ⇒ DPI panel. - eDP encoder ⇒ LT8912 ⇒ DSI panel Signed-off-by:
-
Dmitry Baryshkov authored
In commit 8a3b4c17 ("drm/msm/dp: employ bridge mechanism for display enable and disable") the DP driver received a drm_bridge instance, which is always attached to the encoder as a root bridge. However it conflicts with the panel_bridge support for eDP panels. The panel bridge attaches to the encoder before the "dp" bridge (DP driver's drm_bridge instance created in msm_dp_bridge_init()) has a chance to do so. Change panel bridge attachment to come after the "dp" bridge attachment (and to use it as a previous bridge). Fixes: 8a3b4c17 ("drm/msm/dp: employ bridge mechanism for display enable and disable") Cc: Kuogee Hsieh <quic_khsieh@quicinc.com> Signed-off-by:
-
- 18 Feb, 2022 36 commits
-
-
AngeloGioacchino Del Regno authored
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always checking if the relative CTL is started by waiting for an interrupt to fire: it is fine to do that, but then sometimes we call this function while the CTL is up and has never been put down, but that interrupt gets raised only when the CTL gets a state change from 0 to 1 (disabled to enabled), so we're going to wait for something that will never happen on its own. Solving this while avoiding to restart the CTL is actually possible and can be done by just checking if it is already up and running when the wait_for_commit_done function is called: in this case, so, if the CTL was already running, we can say that the commit is done if the command transmission is complete (in other terms, if the interface has been flushed). Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
-
AngeloGioacchino Del Regno authored
Add a function that returns whether the requested CTL is active or not: this will be used in a later commit to fix command mode panel issues. Signed-off-by:
-
Dmitry Baryshkov authored
DPU driver contains code to parse clock items from device tree into special data struct and then enable/disable/set rate for the clocks using that data struct. However the DPU driver itself uses only parsing and enabling/disabling part (the rate setting is used by DP driver). Move this implementation to the DP driver (which actually uses rate setting) and replace hand-coded enable/disable/get loops in the DPU with the respective clk_bulk operations. Put operation is removed completely because, it is handled using devres instead. DP implementation is unchanged for now. Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # RB3 (sdm845) and RB5 (qrb5165) Reviewed-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by:
-
Dmitry Baryshkov authored
All physical encoders used by virtual encoder share the same connector, so pull the connector field from dpu_encoder_phys into dpu_encoder_virt structure. Otherwise code suggests that different phys_encs can have different connectors. Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
-
Dmitry Baryshkov authored
Make dpu_encoder use atomic_mode_set to receive connector and CRTC states as arguments rather than finding connector and CRTC by manually looping through the respective lists. Reviewed-by:
-
Dmitry Baryshkov authored
Both cmd and vid backends provide useless mode_fixup() callback. Drop it. Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
-
Dmitry Baryshkov authored
We do not use MSM bus client, so drop bus_scaling_client field from dpu_encoder_virt. Reviewed-by:
-
Dmitry Baryshkov authored
Stop caching msm_dp instance in dpu_encoder_virt since it's not used now. Fixes: 8a3b4c17 ("drm/msm/dp: employ bridge mechanism for display enable and disable") Reviewed-by:
-
Dmitry Baryshkov authored
The msm_display_info structure is not used by the rest of msm driver, so move it into the dpu1 (dpu_encoder.h to be precise). Reviewed-by:
-
Dmitry Baryshkov authored
DP audio enablement code which is comparing intf_type, DRM_MODE_ENCODER_TMDS (= 2) with DRM_MODE_CONNECTOR_DisplayPort (= 10). Which would never succeed. Fix it to check for DRM_MODE_ENCODER_TMDS. Fixes: d13e36d7 ("drm/msm/dp: add audio support for Display Port on MSM") Reviewed-by:
-
Dmitry Baryshkov authored
The access macros BLK_foo are not used by the code, drop them. Signed-off-by:
-
Bjorn Andersson authored
dpu_kms_debugfs_init() is invoked for each minor being registered. Most of the files created are unrelated to the minor, so there's no reason to present them per minor. The exception to this is the DisplayPort code, which ends up invoking dp_debug_get() for each minor, each time associate the allocated object with dp->debug. As such dp_debug will create debugfs files in both the PRIMARY and the RENDER minor's debugfs directory, but only the last reference will be remembered. The only use of this reference today is in the cleanup path in dp_display_deinit_sub_modules() and the dp_debug_private object does outlive the debugfs entries in either case, so there doesn't seem to be any adverse effects of this, but per the code the current behavior is unexpected, so change it to only create debugfs files for the PRIMARY minor. Signed-off-by:
-
Rob Clark authored
Add SC8180x to the hardware catalog, for initial support for the platform. Due to limitations in the DP driver only one of the four DP interfaces is left enabled. The SC8180x platform supports the newly added DPU_INTF_WIDEBUS flag and the Windows-on-Snapdragon bootloader leaves the widebus bit set, so this is flagged appropriately to ensure widebus is disabled - for now. Signed-off-by:
Rob Clark <robdclark@chromium.org> [bjorn: Reworked intf and irq definitions] Signed-off-by:
-
Bjorn Andersson authored
SC8180x has the eDP controller wired up to INTF_5, so add the interrupt register block for this interface to the list. Signed-off-by:
-
Dmitry Baryshkov authored
Using IS_ERR_OR_NULL() together with PTR_ERR() is a typical mistake. If the value is NULL, then the function will return 0 instead of a proper return code. Moreover none of dpu_hw_*_init() functions can return NULL. So, replace all dpu_rm_init()'s IS_ERR_OR_NULL() calls with IS_ERR(). Signed-off-by:
-
Dmitry Baryshkov authored
Now as dpu_hw_intf is not hanled by dpu_rm_get_assigned_resources, there is no point in embedding the (empty) struct dpu_hw_blk into dpu_hw_intf (and using typecasts between dpu_hw_blk and dpu_hw_intf). Drop it and use dpu_hw_intf directly. Signed-off-by:
-
Dmitry Baryshkov authored
INTF blocks are not really handled by resource manager, they are assigned at dpu_encoder_setup_display using dpu_encoder_get_intf(). Then this allocation is passed to RM and then returned to then dpu_encoder. So allocate them outside of RM and use them directly. Signed-off-by:
-
Dmitry Baryshkov authored
Add missing calls to dpu_hw_dspp_destroy() to free resources allocated for DSPP hardware blocks. Fixes: e47616df ("drm/msm/dpu: add support for color processing blocks in dpu driver") Signed-off-by:
-
Dmitry Baryshkov authored
No code uses lm_max_width from resource manager, so drop it. Instead of calculating the lm_max_width, code can use max_mixer_width field from the hw catalog. Signed-off-by:
-
Kuogee Hsieh authored
intf_audio_select() callback function use to configure HDMI_DP_CORE_SELECT to decide audio output routes to HDMI or DP interface. HDMI is obsoleted at newer chipset. To keep supporting legacy hdmi application, intf_audio_select call back function have to be populated base on hardware chip capability where legacy chipsets have has_audio_select flag set to true. Changes in V2: -- remove has_audio_select flag -- add BIT(DPU_MDP_AUDIO_SELECT) into dpu_mdp_cfg Signed-off-by:
-
Vinod Koul authored
dpu_core_irq_callback_handler() function comments seem to have become stale and emit a warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:147: warning: Function parameter or member 'dpu_kms' not described in 'dpu_core_irq_callback_handler' drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:147: warning: Excess function parameter 'arg' description in 'dpu_core_irq_callback_handler' Fix by updating the documentation Signed-off-by:
Vinod Koul <vkoul@kernel.org> Reviewed-by:
-
Vinod Koul authored
The multi line comment style is wrongly used as kernel-doc comment. This gives a warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:17: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Update the style to fix this. Signed-off-by:
-
Vinod Koul authored
We get warning: In function ‘dpu_encoder_virt_enable’: drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1145:33: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable] 1145 | struct msm_drm_private *priv; In function ‘dpu_encoder_virt_disable’: drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1182:33: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable] 1182 | struct msm_drm_private *priv; Remove these unused but set variables Signed-off-by:
-
Yang Li authored
Eliminate the follow smatch warning: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:411 _dpu_crtc_blend_setup_mixer() warn: inconsistent indenting Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Reviewed-by:
-
AngeloGioacchino Del Regno authored
Add yaml binding for msm8998 dpu1 support. Signed-off-by:
Jami Kettunen <jami.kettunen@somainline.org> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220113145111.29984-4-jami.kettunen@somainline.orgSigned-off-by:
-
AngeloGioacchino Del Regno authored
Bringup functionality for MSM8998 in the DPU, driver which is mostly the same as SDM845 (just a few variations). Signed-off-by:
-
AngeloGioacchino Del Regno authored
The enum dpu_clk_ctrl_type misses DPU_CLK_CTRL_DMA{2,3} even though this driver does actually handle both, if present: add the two in preparation for adding support for SoCs having them. Signed-off-by: -
Yury Norov authored
smp_request_block() in drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c calls bitmap_weight() to check if any bit of a given bitmap is set. It's better to use bitmap_empty() in that case because bitmap_empty() stops traversing the bitmap as soon as it finds first set bit, while bitmap_weight() counts all bits unconditionally. Signed-off-by:
Yury Norov <yury.norov@gmail.com> Reviewed-by:
-
Daniel Thompson authored
Quoting the header comments, IRQF_ONESHOT is "Used by threaded interrupts which need to keep the irq line disabled until the threaded handler has been run.". When applied to an interrupt that doesn't request a threaded irq then IRQF_ONESHOT has a lesser known (undocumented?) side effect, which it to disable the forced threading of irqs. For "normal" kernels if there is no thread_fn then IRQF_ONESHOT is a nop. In this case disabling forced threading is not appropriate because the driver calls wake_up_all() (via msm_hdmi_i2c_irq) and also directly uses the regular spinlock API for locking (in msm_hdmi_hdcp_irq() ). Neither of these APIs can be called from no-thread interrupt handlers on PREEMPT_RT systems. Fix this by removing IRQF_ONESHOT. Signed-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by:
-
Dmitry Baryshkov authored
The dsi_7nm_phy_enable() disagrees with downstream for glbl_str_swi_cal_sel_ctrl and glbl_hstx_str_ctrl_0 values. Update programmed settings to match downstream driver. To remove the possibility for such errors in future drop less_than_1500_mhz assignment and specify settings explicitly. Fixes: 5ac17838 ("drm/msm/dsi: support CPHY mode for 7nm pll/phy") Signed-off-by:
-
Dmitry Baryshkov authored
The DSI subsystem does not fully fall into the pre-enable/enable system of callbacks, since typically DSI device bridge drivers expect to be able to communicate with DSI devices at the pre-enable() callback. The reason is that for some DSI hosts enabling the video stream would prevent other drivers from sending DSI commands. For example see the panel-bridge driver, which does drm_panel_prepare() from the pre_enable() callback (which would be called before our pre_enable() callback, resulting in panel preparation failures as the link is not yet ready). Therewere several attempts to solve this issue, but currently the best approach is to power up the DSI link from the mode_set() callback, allowing next bridge/panel to use DSI transfers in the pre_enable() time. Follow this approach. Signed-off-by:
-
Daniel Thompson authored
Quoting the header comments, IRQF_ONESHOT is "Used by threaded interrupts which need to keep the irq line disabled until the threaded handler has been run.". When applied to an interrupt that doesn't request a threaded irq then IRQF_ONESHOT has a lesser known (undocumented?) side effect, which it to disable the forced threading of irqs (and for "normal" kernels it is a nop). In this case I can find no evidence that suppressing forced threading is intentional. Had it been intentional then a driver must adopt the raw_spinlock API in order to avoid deadlocks on PREEMPT_RT kernels (and avoid calling any kernel API that uses regular spinlocks). Fix this by removing the spurious additional flag. This change is required for my Snapdragon 7cx Gen2 tablet to boot-to-GUI with PREEMPT_RT enabled. Signed-off-by:
-
Rajeev Nandan authored
The clock and data lanes of the DSI PHY have a calibration circuitry feature. As per the MSM DSI PHY tuning guidelines, the drive strength tuning can be done by adjusting rescode offset for hstop/hsbot, and the drive level tuning can be done by adjusting the LDO output level for the HSTX drive. Signed-off-by:
Rajeev Nandan <quic_rajeevny@quicinc.com> Reviewed-by:
-
Rajeev Nandan authored
Add support for MSM DSI PHY tuning configuration. Current design is to support drive strength and drive level/amplitude tuning for 10nm PHY version, but this can be extended to other PHY versions. Signed-off-by:
-
Rajeev Nandan authored
In most cases, the default values of DSI PHY tuning registers should be sufficient as they are fully optimized. However, in some cases where extreme board parasitics cause the eye shape to degrade, the override bits can be used to improve the signal quality. The general guidelines for DSI PHY tuning include: - High and moderate data rates may benefit from the drive strength and drive level tuning. - Drive strength tuning will affect the output impedance and may be used for matching optimization. - Drive level tuning will affect the output levels without affecting the impedance. The clock and data lanes have a calibration circuitry feature. The drive strength tuning can be done by adjusting rescode offset for hstop/hsbot, and the drive level tuning can be done by adjusting the LDO output level for the HSTX drive. Signed-off-by:
-
Marijn Suijten authored
All DSI PHY/PLL drivers were referencing their VCO parent clock by a global name, most of which don't exist or have been renamed. These clock drivers seem to function fine without that except the 14nm driver for sdm6xx [1]. At the same time all DTs provide a "ref" clock as per the requirements of dsi-phy-common.yaml, but the clock is never used. This patchset puts that clock to use without relying on a global clock name, so that all dependencies are explicitly defined in DT (the firmware) in the end. Note that this patch intentionally breaks older firmware (DT) that relies on the clock to be found globally instead. The only affected platform is msm8974 [2] for whose dsi_phy_28nm a .name="xo" fallback is left in place to accommodate a more graceful transition period. All other platforms had the "ref" clock added to their phy node since its inception, or in a followup patch some time after. These patches wrongly assumed that the "ref" clock was actively used and have hence been listed as "Fixes:" below. Furthermore apq8064 was providing the wrong 19.2MHz cxo instead of 27MHz pxo clock, which has been addressed in [3]. It is expected that both [2] and [3] are applied to the tree well in advance of this patch such that any actual breakage is extremely unlikely, but might still occur if kernel upgrades are performed without the DT to match. After some time the fallback for msm8974 can be removed again as well. [1]: https://lore.kernel.org/linux-arm-msm/386db1a6-a1cd-3c7d-a88e-dc83f8a1be96@somainline.org/ [2]: https://lore.kernel.org/linux-arm-msm/20210830175739.143401-1-marijn.suijten@somainline.org/ [3]: https://lore.kernel.org/linux-arm-msm/20210829203027.276143-2-marijn.suijten@somainline.org/ Fixes: 79e51645 ("arm64: dts: qcom: msm8916: Set 'xo_board' as ref clock of the DSI PHY") Fixes: 6969d1d9 ("ARM: dts: qcom-apq8064: Set 'cxo_board' as ref clock of the DSI PHY") Fixes: 0c0e7270 ("arm64: dts: sdm845: Set 'bi_tcxo' as ref clock of the DSI PHYs") Signed-off-by:
-
