- Jul 11, 2023
-
-
Dmitry Baryshkov authored
The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely. Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Tested-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/545384/ Link: https://lore.kernel.org/r/20230704022136.130522-19-dmitry.baryshkov@linaro.org
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by:
-
Dmitry Baryshkov authored
Shift dpu_ctl_cfg contents to correct the indentation of CTL blocks. This is done in preparation to expanding the rest of hardware block defines, so that all blocks have similar indentation. Reviewed-by:
-
Dmitry Baryshkov authored
Drop useless zero assignments to the dpu_ctl_cfg::features field. Reviewed-by:
-
Dmitry Baryshkov authored
Drop useless zero assignments to the dpu_mdp_cfg::features field. Reviewed-by:
-
Dmitry Baryshkov authored
Use more standard initialisation for .clk_ctrls definitions. Define a single .clk_ctrls field and use array init inside. Reviewed-by:
-
Dmitry Baryshkov authored
Since there is always just a single MDP_TOP instance, drop the enum dpu_mdp and corresponding index value. Reviewed-by:
-
Dmitry Baryshkov authored
There is always a single MDP TOP block. Drop the mdp_count field and stop declaring dpu_mdp_cfg instances as arrays. Tested-by:
-
Dmitry Baryshkov authored
For each LM there is at max 1 peer LM. Thus there is no need to have a mask for the peer LM enumeration. Change that to have an ID of the peer LM. Reviewed-by:
-
Dmitry Baryshkov authored
In several catalog entries we did not use existing MSM_DP_CONTROLLER_n constants. Fill them in. Also use freshly defined MSM_DSI_CONTROLLER_n for DSI interfaces. Reviewed-by:
-
Dmitry Baryshkov authored
Follow the DP example and define MSM_DSI_CONTROLLER_n enumeration. Reviewed-by:
-
Consume the refgen supply on configurations that may use it. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
-
DSI host needs REFGEN to be enabled (if it's present on a given platform). Allow consuming it. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Document the optional displayport controller subnode of the SM8550 MDSS. Acked-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
-
Document the optional displayport controller subnode of the SM8450 MDSS. Acked-by:
-
Document the optional displayport controller subnode of the SM8350 MDSS. Acked-by:
-
Since struct drm_dsc_config is stored at atomic_enable() instead of display setup time during boot up, saving struct drm_dsc_config at struct msm_display_info is not necessary. Lets drop the dsc member from struct msm_display_info. Changes in v4: -- fix "Since" at commit text Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
-
Currently struct drm_dsc_config for DSI is populated at display setup during system boot up. This mechanism works fine with embedded display but not for pluggable displays as the struct drm_dsc_config will become stale once external display is unplugged. In preparation of adding support for DP DSC support move storing of DSI DSC struct to atomic_enable() so that same mechanism will work for both embedded display and pluggable displays. Changes in v4: -- fix checkpatch.pl warning Changes in v5: -- delete dpu_encoder_get_dsc_config() from atomic_mode_set Signed-off-by:
-
- Jul 10, 2023
-
-
Dmitry Baryshkov authored
The array of CRTC in the struct msm_drm_private duplicates a list of CRTCs in the drm_device. Drop it and use the existing list for CRTC enumeration. Signed-off-by:
-
SDM845 was the first SoC to include both PCC v4 and GC v1.8. We don't currently support any other blocks but the common config for these two can be reused for a large amount of SoCs. Rename it to indicate the origin of that combo. Signed-off-by:
-
- Jun 18, 2023
-
-
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125 (trinket) and SM6225 (khaje). Trinket does not support speed binning (only a single SKU exists) and we don't yet support khaje upstream. Hence, add a fuse mapping table for bengal to allow for per-chip frequency limiting. Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375 (blair). This is what seems to be a first occurrence of this happening, but it's easy to overcome by guarding the SoC-specific fuse values with of_machine_is_compatible(). Do just that to enable frequency limiting on these SoCs. Reviewed-by:
-
Before transitioning to using per-SoC and not per-Adreno speedbin fuse values (need another patchset to land elsewhere), a good improvement/stopgap solution is to use adreno_is_aXYZ macros in place of explicit revision matching. Do so to allow differentiating between A619 and A619_holi. Reviewed-by:
-
The GPU can only be one at a time. Turn a series of ifs into if + elseifs to save some CPU cycles. Reviewed-by:
-
Adreno 619 expects some tunables to be set differently. Make up for it. Fixes: b7616b5c ("drm/msm/adreno: Add A619 support") Reviewed-by:
-
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It features no GMU, as it's implemented solely on SoCs with SMD_RPM. What's more interesting is that it does not feature a VDDGX line either, being powered solely by VDDCX and has an unfortunate hardware quirk that makes its reset line broken - after a couple of assert/ deassert cycles, it will hang for good and will not wake up again. This GPU requires mesa changes for proper rendering, and lots of them at that. The command streams are quite far away from any other A6XX GPU and hence it needs special care. This patch was validated both by running an (incomplete) downstream mesa with some hacks (frames rendered correctly, though some instructions made the GPU hangcheck which is expected - garbage in, garbage out) and by replaying RD traces captured with the downstream KGSL driver - no crashes there, ever. Add support for this GPU on the kernel side, which comes down to pretty simply adding A612 HWCG tables, altering a few values and adding a special case for handling the reset line. Reviewed-by:
-
A619_holi is a GMU-less variant of the already-supported A619 GPU. It's present on at least SM4350 (holi) and SM6375 (blair). No mesa changes are required. Add the required kernel-side support for it. Signed-off-by:
-
A610 and A619_holi don't support the feature. Disable it to make the GPU stop crashing after almost each and every submission - the received data on the GPU end was simply incomplete in garbled, resulting in almost nothing being executed properly. Extend the disablement to adreno_has_gmu_wrapper, as none of the GMU wrapper Adrenos that don't support yet seem to feature it. Reviewed-by:
-
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs but don't implement the associated GMUs. This is due to the fact that the GMU directly pokes at RPMh. Sadly, this means we have to take care of enabling & scaling power rails, clocks and bandwidth ourselves. Reuse existing Adreno-common code and modify the deeply-GMU-infused A6XX code to facilitate these GPUs. This involves if-ing out lots of GMU callbacks and introducing a new type of GMU - GMU wrapper (it's the actual name that Qualcomm uses in their downstream kernels). This is essentially a register region which is convenient to model as a device. We'll use it for managing the GDSCs. The register layout matches the actual GMU_CX/GX regions on the "real GMU" devices and lets us reuse quite a bit of gmu_read/write/rmw calls. Signed-off-by:
-
Since the introduction of A6xx support, we've been enabling the CX GMU power counter 0 in a bit of a weird spot. Move it to hw_init so that GMU wrapper GPUs can reuse the same code paths. As a bonus, this order makes it easier to compare mainline and downstream register access traces. Signed-off-by:
-
Rename lower_bit to hbb_lo and explain what it signifies. Add explanations (wherever possible to other tunables). Port setting min_access_length, ubwc_mode and hbb_hi from downstream. Reviewed-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also need REG_A6XX_GBIF_HALT to be set to 0. This is typically done automatically on successful GX collapse, but in case that fails, we should take care of it. Also, add a memory barrier to ensure it's gone through before jumping to further initialization. Reviewed-by:
-
Introduce a6xx_gpu_sw_reset() in preparation for adding GMU wrapper GPUs and reuse it in a6xx_gmu_force_off(). This helper, contrary to the original usage in GMU code paths, adds a readback+delay sequence to ensure that the reset is never deasserted too quickly due to e.g. OoO execution going crazy. Signed-off-by:
-
