- 30 Nov, 2021 7 commits
-
-
Bjorn Andersson authored
Since '8ede2ecc ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets")' the hpd_high member of struct dp_usbpd has been write-only. Let's clean up the code a little bit by removing the writes as well. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20211106172246.2597431-1-bjorn.andersson@linaro.orgSigned-off-by:
Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Signed-off-by:
-
Rob Clark authored
If you don't realize is_a650_family() also encompasses a660 family, you'd think that the debug buffer is double allocated. Add a comment to make this more clear. Signed-off-by:
-
Rob Clark authored
It appears to be a GMU fw build option whether it does anything with debug and log buffers, but if they are all zeros it won't add anything to the devcore size. Signed-off-by:
-
Rob Clark authored
This also includes a history of start index of the last 8 messages on each queue, since parsing backwards to decode recently sent HFI messages is hard(ish). Signed-off-by:
-
Rob Clark authored
Turn it into a thing we can use to snapshot other GMU buffers. Signed-off-by:
-
Rob Clark authored
We don't expect either of these conditions to ever be true, so let's get shouty if they are. Signed-off-by:
-
- 28 Nov, 2021 29 commits
-
-
Akhil P Oommen authored
Capture gmu log in coredump to enhance debugging. Signed-off-by:
Akhil P Oommen <akhilpo@codeaurora.org> Signed-off-by:
-
Rob Clark authored
Re-work the boost and idle clamping to use PM QoS requests instead, so they get aggreggated with other requests (such as cooling device). This does have the minor side-effect that devfreq sysfs min_freq/ max_freq files now reflect the boost and idle clamping, as they show (despite what they are documented to show) the aggregated min/max freq. Fixing that in devfreq does not look straightforward after considering that OPPs can be dynamically added/removed. However writes to the sysfs files still behave as expected. v2: Use 64b math to avoid potential 32b overflow Signed-off-by:
-
Akhil P Oommen authored
Currently, we boost gpu freq after 25ms of inactivity. This regresses some of the 30 fps usecases where the workload on gpu (at 33ms internval) is very small which it can finish at the lowest OPP before the deadline. Lets increase this inactivity threshold to 50ms (same as the current devfreq interval) to fix this. Signed-off-by:
-
Rob Clark authored
This was the one GPU related kernel buffer which was not given a debug name. Let's fix that. Signed-off-by:
-
Rob Clark authored
Add a debugfs interface to ignore hw error irqs, in order to force fallback to sw hangcheck mechanism. Because the hw error detection is pretty good on newer gens, we need this for igt tests to test the sw hang detection. Signed-off-by:
-
Rob Clark authored
Add some helpers for fence comparision, which handle rollover properly, and stop open coding fence seqno comparisions. Signed-off-by:
-
Rob Clark authored
The remaining struct_mutex usage is just to serialize various gpu related things (submit/retire/recover/fault/etc), so replace struct_mutex with gpu->lock. Signed-off-by:
-
Rob Clark authored
cur_ctx_seqno already does the same thing, but handles the edge cases where a refcnt'd context can live after lastclose. So let's not have two ways to do the same thing. Signed-off-by:
-
Rob Clark authored
The struct_mutex locking is a remnant from the days before per-obj locks, and no longer needed. Signed-off-by:
-
Dmitry Baryshkov authored
The "vdd" regulator was used by the mdp5 driver only on downstream kernels, where the GDSC is represented as a regulator. On all current kernels the MDSS_GDSC is implemented as the power domain, removing the need for this regulator. Remove it from the mdp5 driver. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
-
Sankeerth Billakanti authored
The eDP sink on sc7280 supports ASSR and dp driver will enable ASSR in the source hardware. The driver needs to enable the ASSR field in the DPCD configuration register to avoid screen corruption. This change will enable ASSR if supported in the sink device. Signed-off-by:
Sankeerth Billakanti <quic_sbillaka@quicinc.com> Reviewed-by:
-
Sankeerth Billakanti authored
The sc7280 eDP sink that supports downspread will fail link training if source does not enable SSC / downspread. This change will set the downspread bit in the DP sink if supported and indicate SSC support to the DP PHY driver. Signed-off-by:
-
Sankeerth Billakanti authored
Add a macro to check for the max_downspread capability in drm_dp_helper. Signed-off-by:
-
Sankeerth Billakanti authored
The eDP controller on SC7280 is similar to the eDP/DP controllers supported by the current driver implementation. SC7280 supports one EDP and one DP controller which can operate concurrently. This change adds the support for eDP and DP controller on sc7280. Signed-off-by:
-
Sankeerth Billakanti authored
The Qualcomm SC7280 platform supports one eDP controller and a DP controller. This change will add the compatible string for both eDP and DP to msm dp-controller binding. Signed-off-by:
-
Dmitry Baryshkov authored
There is no reason to set clock parents manually, use device tree to assign DSI/display clock parents to DSI PHY clocks. Dropping this manual setup allows us to drop repeating code and to move registration of hw clock providers to generic place. Signed-off-by:
Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20211006204828.1218225-2-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Move DPHY/CPHY setting from msm_dsi_host_set_src_pll() to new function msm_dsi_host_set_phy_mode(). Signed-off-by:
-
Dmitry Baryshkov authored
eDP driver is being removed, so drop bindings description. Signed-off-by:
-
Dmitry Baryshkov authored
MSM DRM driver has support for eDP block present on MSM 8x74/8x84 SoC families. However since addition back in 2015 this driver received only generic fixes. No actual devices with these SoCs supported upstream (or by the community) seem to support eDP panels. Judging from downstream kernels the eDP was present only on MSM8974 LIQUID or on APQ8084 CDP. Remove this driver. Signed-off-by:
-
Dmitry Baryshkov authored
Prepare for removing old eDP support present in 8x74/8x84 SoC families. No devices present in mainline support eDP ports. Signed-off-by:
-
Dmitry Baryshkov authored
Do not cache hw_pipe's sblk in dpu_plane. Use pdpu->pipe_hw->cap->sblk directly. Signed-off-by:
-
Dmitry Baryshkov authored
Do not cache hw_pipe's features in dpu_plane. Use pdpu->pipe_hw->cap->features directly. Signed-off-by:
-
Dmitry Baryshkov authored
Remove struct dpu_hw_pipe_cdp_cfg instance from dpu_plane, it is an interim configuration structure. Allocate it on stack instead. Signed-off-by:
-
Dmitry Baryshkov authored
Simplify code surrounding CSC table setup by removing struct dpu_csc_cfg pointer from dpu_plane and getting it directly at the CSC setup time. Signed-off-by:
-
Dmitry Baryshkov authored
struct dpu_hw_pipe_cfg represents an interim state during atomic update/color fill, so move it out of struct dpu_plane. Signed-off-by:
-
Dmitry Baryshkov authored
The stage_cfg is not used outside of _dpu_crtc_blend_setup(), so remove the temporary config from global struct. Signed-off-by:
-
Dmitry Baryshkov authored
Use plane->name instead of artificial pipe_name. Signed-off-by:
-
Dmitry Baryshkov authored
The pipe_qos_cfg is used only in _dpu_plane_set_qos_ctrl(), so remove it from the dpu_plane struct and allocate it on stack when necessary. Signed-off-by:
-
Dmitry Baryshkov authored
LUT levels are setup outside of setup_qos_ctrl, so remove them from the struct dpu_hw_pipe_qos_cfg. Signed-off-by:
-
- 26 Nov, 2021 1 commit
-
-
Arnd Bergmann authored
When CONFIG_COMMON_CLOCK is disabled, the 8996 specific phy code is left out, which results in a link failure: ld: drivers/gpu/drm/msm/hdmi/hdmi_phy.o:(.rodata+0x3f0): undefined reference to `msm_hdmi_phy_8996_cfg' This was only exposed after it became possible to build test the driver without the clock interfaces. Make COMMON_CLK a hard dependency for compile testing, and simplify it a little based on that. Fixes: b3ed524f ("drm/msm: allow compile_test on !ARM") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
- 22 Nov, 2021 3 commits
-
-
Rob Clark authored
In particular, we need to ensure all the necessary blocks are switched to 64b mode (a5xx+) otherwise the high bits of the address of the BO to snapshot state into will be ignored, resulting in: *** gpu fault: ttbr0=0000000000000000 iova=0000000000012000 dir=READ type=TRANSLATION source=CP (0,0,0,0) platform 506a000.gmu: [drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set BOOT_SLUMBER: 0x0 Fixes: 4f776f45 ("drm/msm/gpu: Convert the GPU show function to use the GPU state") Signed-off-by:
-
Douglas Anderson authored
If you happened to try to access `/dev/drm_dp_aux` devices provided by the MSM DP AUX driver too early at bootup you could go boom. Let's avoid that by only allowing AUX transfers when the controller is powered up. Specifically the crash that was seen (on Chrome OS 5.4 tree with relevant backports): Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 0 PID: 3131 Comm: fwupd Not tainted 5.4.144-16620-g28af11b73efb #1 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Call trace: dump_backtrace+0x0/0x14c show_stack+0x20/0x2c dump_stack+0xac/0x124 panic+0x150/0x390 nmi_panic+0x80/0x94 arm64_serror_panic+0x78/0x84 do_serror+0x0/0x118 do_serror+0xa4/0x118 el1_error+0xbc/0x160 dp_catalog_aux_write_data+0x1c/0x3c dp_aux_cmd_fifo_tx+0xf0/0x1b0 dp_aux_transfer+0x1b0/0x2bc drm_dp_dpcd_access+0x8c/0x11c drm_dp_dpcd_read+0x64/0x10c auxdev_read_iter+0xd4/0x1c4 I did a little bit of tracing and found that: * We register the AUX device very early at bootup. * Power isn't actually turned on for my system until hpd_event_thread() -> dp_display_host_init() -> dp_power_init() * You can see that dp_power_init() calls dp_aux_init() which is where we start allowing AUX channel requests to go through. In general this patch is a bit of a bandaid but at least it gets us out of the current state where userspace acting at the wrong time can fully crash the system. * I think the more proper fix (which requires quite a bit more changes) is to power stuff on while an AUX transfer is happening. This is like the solution we did for ti-sn65dsi86. This might be required for us to move to populating the panel via the DP-AUX bus. * Another fix considered was to dynamically register / unregister. I tried that at <https://crrev.com/c/3169431/3> but it got ugly. Currently there's a bug where the pm_runtime() state isn't tracked properly and that causes us to just keep registering more and more. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
-
Philip Chen authored
If "data_lanes" property of the dsi output endpoint is missing in the DT, num_data_lanes would be 0 by default, which could cause dsi_host_attach() to fail if dsi->lanes is set to a non-zero value by the bridge driver. According to the binding document of msm dsi controller, the input/output endpoint of the controller is expected to have 4 lanes. So let's set num_data_lanes to 4 by default. Signed-off-by:
Philip Chen <philipchen@chromium.org> Reviewed-by:
-
