- 07 Jul, 2022 11 commits
-
-
Rob Clark authored
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. Signed-off-by:
Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/489337/ Link: https://lore.kernel.org/r/20220613182036.2567963-1-robdclark@gmail.com
-
Rob Clark authored
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). Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/14Signed-off-by:
-
Dmitry Baryshkov authored
Remove unused dp_display_en/disable prototypes. While we are at it, remove extra 'data' argument that is unused. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/490104/ Link: https://lore.kernel.org/r/20220617232434.1139950-3-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
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(). Signed-off-by:
-
Dmitry Baryshkov authored
Refactoring DP code transformed several functions into empty stubs. Remove them. Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
Geert Uytterhoeven authored
With sparse ("make C=2"), lots of error: return expression in void function messages are seen. Fix this by removing the return statements to propagate void return values. Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Patchwork: https://patchwork.freedesktop.org/patch/492529/ Link: https://lore.kernel.org/r/0083bc7e23753c19902580b902582ae499b44dbf.1657113388.git.geert@linux-m68k.orgSigned-off-by:
-
Rob Clark authored
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. Signed-off-by:
-
Rob Clark authored
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. Signed-off-by:
-
Dmitry Baryshkov authored
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:
-
Dmitry Baryshkov authored
MDP5 and DPU drivers have the same piece of code now to initialize IOMMU and GEM address space. Move it to the msm_drv.c Signed-off-by:
-
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:
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:
-
- 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 10 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:
-
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:
-
