- 07 Jul, 2022 1 commit
-
-
Dmitry Baryshkov authored
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:
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.orgSigned-off-by:
Rob Clark <robdclark@chromium.org>
-
- 06 Jul, 2022 13 commits
-
-
Dmitry Baryshkov authored
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:
-
Dmitry Baryshkov authored
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:
-
Rob Clark authored
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. Signed-off-by:
-
Dmitry Baryshkov authored
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. Signed-off-by:
-
Dmitry Baryshkov authored
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. Signed-off-by:
-
Dmitry Baryshkov authored
We (nearly) do not use the length field from struct dpu_hw_blk_reg_map, so we can drop it safely. Signed-off-by:
-
Dmitry Baryshkov authored
Drop the unused field xin_id. Signed-off-by:
-
Rob Clark authored
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) Signed-off-by:Chia-I Wu <olvaffe@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/487601/ Link: https://lore.kernel.org/r/20220529180428.2577832-1-robdclark@gmail.com
-
Konrad Dybcio authored
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. Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/487592/ Link: https://lore.kernel.org/r/20220528160353.157870-4-konrad.dybcio@somainline.orgSigned-off-by:
-
Konrad Dybcio authored
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. Signed-off-by:
-
Konrad Dybcio authored
Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350), 480 (SM4350) and 750G (SM7225). Signed-off-by:
-
Konrad Dybcio authored
This BUG_ON will never be reached, and there is a comment 20 above explaining why. Signed-off-by:
-
Douglas Anderson authored
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: eadf7928 ("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@changeidSigned-off-by:
-
- 05 Jul, 2022 6 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', '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 Signed-off-by: -
Rob Clark authored
And while we are at it, let's start the fence counter close to the rollover point so that if issues slip in, they are more obvious. Signed-off-by:
-
Wan Jiabing authored
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. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Patchwork: https://patchwork.freedesktop.org/patch/483499/ Link: https://lore.kernel.org/r/20220426132126.686447-1-wanjiabing@vivo.comSigned-off-by:
-
Rob Clark authored
Similar to AMD commit 87444254 ("drm/amdgpu: Add show_fdinfo() interface"), using the infrastructure added in previous patches, we add basic client info and GPU engine utilisation for msm. Example output: # cat /proc/`pgrep glmark2`/fdinfo/6 pos: 0 flags: 02400002 mnt_id: 21 ino: 162 drm-driver: msm drm-client-id: 7 drm-engine-gpu: 1734371319 ns drm-cycles-gpu: 1153645024 drm-maxfreq-gpu: 800000000 Hz See also: https://patchwork.freedesktop.org/patch/468505/ v2: Add dev-maxfreq-$engine and update drm-usage-stats.rst v3: spelling and compiler warning Signed-off-by:
-
Rob Clark authored
The DEFINE_DRM_GEM_FOPS() helper is a bit limiting if a driver wants to provide additional file ops, like show_fdinfo(). v2: Split out DRM_GEM_FOPS instead of making DEFINE_DRM_GEM_FOPS varardic v3: nits Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de> Patchwork: https://patchwork.freedesktop.org/patch/488904/ Link: https://lore.kernel.org/r/20220609174213.2265938-1-robdclark@gmail.comSigned-off-by:
-
Rob Clark authored
Misc small cleanup I noticed. Not called from another object file since commit 3c9edd9c ("drm/msm: Introduce GEM object funcs") Signed-off-by:
-
- 04 Jul, 2022 20 commits
-
-
Kalyan Thota authored
Add destination side post processing hw block support in sc7280. This hwblock enablement is necessary to support color features like CT Matix (Ex: Night Light feature) Signed-off-by:
Kalyan Thota <quic_kalyant@quicinc.com> Reviewed-by:
-
Vladimir Lypak authored
Add the perf data for the mdp found in msm8953. Signed-off-by:
Vladimir Lypak <vladimir.lypak@gmail.com> Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Reviewed-by:
-
Dmitry Baryshkov authored
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. Signed-off-by:
-
Dmitry Baryshkov authored
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. Signed-off-by:
-
Dmitry Baryshkov authored
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. Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/489709/ Link: https://lore.kernel.org/r/20220616085057.432353-1-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Drop empty callbacks msm_hdmi_bridge_enable() and msm_hdmi_bridge_disable(). Signed-off-by:
-
Dmitry Baryshkov authored
Declare that 8x60 HDMI PHY uses the core-vdda regulator and slave_iface clock (this is the same config as is used by the 8960). Reviewed-by:
-
Dmitry Baryshkov authored
MSM8660 requires the same set of clocks and regulators as MSM8960. Reuse MSM8960's config for the MSM8660 (8x60). Reviewed-by:
-
Dmitry Baryshkov authored
Since there is no more difference between the HDMI platform data between MSM8974/APQ8084/MSM8994/MSM8996, merge these configs into a single entry. Reviewed-by:
-
Dmitry Baryshkov authored
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. Reviewed-by:
-
Dmitry Baryshkov authored
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. Reviewed-by:
-
Dmitry Baryshkov authored
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: 0afbe59e ("drm/msm/hdmi: Add basic HDMI support for msm8996") Signed-off-by:
-
Dmitry Baryshkov authored
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. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Dmitry Baryshkov authored
With the last (and only) in-kernel user of hdmi-mux regulator, drop it from the HDMI driver. Reviewed-by:
-
Dmitry Baryshkov authored
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:
-
Dmitry Baryshkov authored
Mark obsolete GPIO properties as deprecated. They are not used by existing device trees. While we are at it, also drop them from the schema example. Reviewed-by:
-
Dmitry Baryshkov authored
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:
-
Dmitry Baryshkov authored
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. Reported-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Signed-off-by:
-
Vladimir Lypak authored
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:
-
Dmitry Baryshkov authored
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. Fixes: 31b3b1f5 ("drm/msm/hdmi: use bulk regulator API") Signed-off-by:
-
