- 23 Feb, 2022 2 commits
-
-
Loic Poulain authored
QCM2290 MDSS includes a Qualcomm DSI controller v2.4.1. Since this controller version is not SoC specific, and already assigned to sc7180 for auto configuration, we rely on DSI block specific compatible string "qcom,dsi-ctrl-6g-qcm2290", and use the device's data to point to the right dsi config handler. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/474088/ Link: https://lore.kernel.org/r/1644853060-12222-2-git-send-email-loic.poulain@linaro.orgSigned-off-by:
-
Loic Poulain authored
Config autodetect based on DSI controller version is quite limited since several qcom SoCs can integrate a DSI controller with the same version, but with different config (io_offset, supplies, etc). This change allows to specify dsi config via device data pointer. config autodetect is still used in case data pointer is NULL. Signed-off-by:
-
- 20 Feb, 2022 2 commits
-
-
Rob Clark authored
Other processes don't need to know about faults that they are isolated from by virtue of address space isolation. They are only interested in whether some of their state might have been corrupted. But to be safe, also track unattributed faults. This case should really never happen unless there is a kernel bug (and that would never happen, right?) v2: Instead of adding a new param, just change the behavior of the existing param to match what userspace actually wants [anholt] Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5934Signed-off-by:Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20220201161618.778455-3-robdclark@gmail.comReviewed-by:
Emma Anholt <emma@anholt.net> Signed-off-by:
-
Rob Clark authored
Prep work for next patch. Signed-off-by:
-
- 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:
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 32 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:
-
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:
-
