- 02 Mar, 2022 1 commit
-
-
Rob Herring authored
The MDSS interrupt provider is a single cell, so specifying interrupt flags on the consumers is incorrect. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220301210513.1855076-1-robh@kernel.orgSigned-off-by:
Rob Clark <robdclark@chromium.org>
-
- 25 Feb, 2022 5 commits
-
-
Akhil P Oommen authored
Expose speedbin through MSM_PARAM_CHIP_ID parameter to help userspace identify the sku. Signed-off-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Link: https://lore.kernel.org/r/20220226005021.v2.4.I86c32730e08cba9e5c83f02ec17885124d45fa56@changeidSigned-off-by:
-
Akhil P Oommen authored
Add support for 7c3 SKU detection using speedbin fuse. Signed-off-by:
-
Akhil P Oommen authored
Use a gpu name which is sprintf'ed from the chipid for 7c3 gpu instead of hardcoding one. This helps to avoid code churn in case of a gpu rename. Signed-off-by:
-
Akhil P Oommen authored
Use generic name for resources like irq and kthread instead of hardware specific name to make it easier to grep. Signed-off-by:
-
Rob Clark authored
Someone on IRC once asked an innocent enough sounding question: Why with xf86-video-modesetting is es2gears limited at 120fps. So I broke out the perfetto tracing mesa MR and took a look. It turns out the problem was drm_atomic_helper_dirtyfb(), which would end up waiting for vblank.. es2gears would rapidly push two frames to Xorg, which would blit them to screen and in idle hook (I assume) call the DIRTYFB ioctl. Which in turn would do an atomic update to flush the dirty rects, which would stall until the next vblank. And then the whole process would repeat. But this is a bit silly, we only need dirtyfb for command mode DSI panels. So track in plane state whether dirtyfb is required, and track in the fb how many attached planes require dirtyfb so that we can skip it when not required. (Note, mdp4 does not actually have cmd mode support.) Signed-off-by:
-
- 23 Feb, 2022 7 commits
-
-
Dmitry Baryshkov authored
-
Dmitry Baryshkov authored
The commit adding msm8998 support didn't added msm8998's DSPP blocks configuration, but did not use them in msm8998_cfg_init(). Wire them up to be used for display post processing. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 94391a14 ("drm/msm/dpu1: Add MSM8998 to hw catalog") Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Cc: Jami Kettunen <jami.kettunen@somainline.org> Signed-off-by:
-
Loic Poulain authored
QCM2290 MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks like DPU display controller, DSI etc. Add YAML schema for DPU device tree bindings Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Reviewed-by:
-
Loic Poulain authored
Add compatibility for QCM2290 display subsystem, including required entries in DPU hw catalog. Signed-off-by:
-
Loic Poulain authored
Add DSI block specific qcm2290 compatible string as valid Qualcomm DSI controller. Signed-off-by:
-
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 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: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 21 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:
-
