summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/msm
AgeCommit message (Collapse)AuthorFilesLines
2021-11-30drm/msm/gpu: Snapshot GMU debug bufferRob Clark1-0/+12
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 <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211124214151.1427022-10-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-30drm/msm/gpu: Also snapshot GMU HFI bufferRob Clark3-1/+68
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 <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211124214151.1427022-9-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-30drm/msm/gpu: Make a6xx_get_gmu_log() more genericRob Clark1-19/+15
Turn it into a thing we can use to snapshot other GMU buffers. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211124214151.1427022-8-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-30drm/msm/gpu: Add some WARN_ON()sRob Clark1-0/+3
We don't expect either of these conditions to ever be true, so let's get shouty if they are. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211124214151.1427022-6-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/a6xx: Capture gmu log in devcoredumpAkhil P Oommen3-1/+44
Capture gmu log in coredump to enhance debugging. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211124214151.1427022-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/gpu: Respect PM QoS constraintsRob Clark2-51/+71
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: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211120200103.1051459-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm: Increase gpu boost intervalAkhil P Oommen1-1/+1
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: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20211118154903.1.I2ed37cd8ad45a5a94d9de53330f973a62bd1fb29@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/adreno: Name the shadow bufferRob Clark2-0/+4
This was the one GPU related kernel buffer which was not given a debug name. Let's fix that. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211115191514.310472-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm: Add debugfs to disable hw err handlingRob Clark4-0/+22
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 <robdclark@chromium.org> Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20211109181117.591148-6-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm: Handle fence rolloverRob Clark4-5/+17
Add some helpers for fence comparision, which handle rollover properly, and stop open coding fence seqno comparisions. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20211109181117.591148-5-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm: Remove struct_mutex usageRob Clark8-34/+49
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 <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211109181117.591148-4-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm: Drop priv->lastctxRob Clark10-35/+22
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 <robdclark@chromium.org> Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20211109181117.591148-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm: Remove unnecessary struct_mutexRob Clark2-34/+16
The struct_mutex locking is a remnant from the days before per-obj locks, and no longer needed. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211109181117.591148-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/mdp5: drop vdd regulatorDmitry Baryshkov1-22/+2
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: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211104003428.2205497-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dp: Enable ASSR for supported DP sinksSankeerth Billakanti1-2/+9
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: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1635839325-401-6-git-send-email-quic_sbillaka@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dp: Enable downspread for supported DP sinksSankeerth Billakanti1-1/+11
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 <quic_sbillaka@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1635839325-401-5-git-send-email-quic_sbillaka@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dp: Add DP controllers for sc7280Sankeerth Billakanti2-2/+11
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 <quic_sbillaka@quicinc.com> changes in v3: - Split into patches according to function (Dmitry Baryshkov) - Use DP_CONTROLLER_1 for eDP controller intf (Dmitry Baryshkov) - Use DP_CONTROLLER_0 for sc7280-dp (Dmitry Baryshkov) - Add macro in drm_helper.h for checking ssc capability (Stephen Boyd) - Use existing macro to check assr capability (Stephen Boyd) - Add comment for HPD_INIT_SETUP delay (Stephen Boyd) changes in v2: - Don't initialize variables to 0 (Stephen Boyd) - Use const for read-only dpcd (Stephen Boyd) - Remove zero pixel clock check (Stephen Boyd) - Sort compatible strings alphabetically (Stephen Boyd) - Use pwm_bl.c for backlight instead of gpio (Stephen Boyd) - Change return type for functions returning always 0 (Matthias Kaehlcke) Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1635839325-401-3-git-send-email-quic_sbillaka@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dsi: stop setting clock parents manuallyDmitry Baryshkov4-73/+2
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: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20211006204828.1218225-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dsi: untangle cphy setting from the src pll settingDmitry Baryshkov3-2/+13
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 <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20211006204828.1218225-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/edp: drop old eDP supportDmitry Baryshkov11-2662/+0
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 <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211001165011.441945-3-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> [rob: Rebased on "drm: msm: fix building without CONFIG_COMMON_CLK"] Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/mdp5: drop eDP supportDmitry Baryshkov1-16/+1
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 <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211001165011.441945-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: don't cache pipe->cap->sblk in dpu_planeDmitry Baryshkov1-17/+8
Do not cache hw_pipe's sblk in dpu_plane. Use pdpu->pipe_hw->cap->sblk directly. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-11-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: don't cache pipe->cap->features in dpu_planeDmitry Baryshkov1-7/+5
Do not cache hw_pipe's features in dpu_plane. Use pdpu->pipe_hw->cap->features directly. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-10-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: remove dpu_hw_pipe_cdp_cfg from dpu_planeDmitry Baryshkov2-9/+7
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 <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-9-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: drop dpu_csc_cfg from dpu_planeDmitry Baryshkov5-50/+54
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 <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-8-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: move dpu_hw_pipe_cfg out of struct dpu_planeDmitry Baryshkov1-47/+57
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 <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-6-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: remove stage_cfg from struct dpu_crtcDmitry Baryshkov2-7/+6
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 <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-5-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: drop pipe_name from struct dpu_planeDmitry Baryshkov1-6/+2
Use plane->name instead of artificial pipe_name. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-4-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: remove pipe_qos_cfg from struct dpu_planeDmitry Baryshkov1-14/+16
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 <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-3-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm/dpu: move LUT levels out of QOS configDmitry Baryshkov3-28/+20
LUT levels are setup outside of setup_qos_ctrl, so remove them from the struct dpu_hw_pipe_qos_cfg. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210930140002.308628-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-26drm: msm: fix building without CONFIG_COMMON_CLKArnd Bergmann2-4/+4
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: b3ed524f84f5 ("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: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211013144308.2248978-1-arnd@kernel.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-22drm/msm: Do hw_init() before capturing GPU stateRob Clark1-0/+1
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: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state") Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211108180122.487859-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-22drm/msm/dp: Avoid unpowered AUX xfers that caused crashesDouglas Anderson1-0/+17
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: Abhinav Kumar <quic_abhinavk@quicinc.com> Link: https://lore.kernel.org/r/20211109100403.1.I4e23470d681f7efe37e2e7f1a6466e15e9bb1d72@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-22drm/msm/dsi: set default num_data_lanesPhilip Chen1-0/+2
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20211030100812.1.I6cd9af36b723fed277d34539d3b2ba4ca233ad2d@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm/gpu: Fix check for devices without devfreqRob Clark1-3/+3
Looks like 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq") was badly rebased on top of efb8a170a367 ("drm/msm: Fix devfreq NULL pointer dereference on a3xx") and ended up with the NULL check in the wrong place. Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq") Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211120200103.1051459-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm/gpu: Fix idle_work timeRob Clark1-1/+1
This was supposed to be a relative timer, not absolute. Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20211120200103.1051459-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm/a6xx: Fix uinitialized use of gpu_scidAkhil P Oommen1-9/+9
Avoid a possible uninitialized use of gpu_scid variable to fix the below smatch warning: drivers/gpu/drm/msm/adreno/a6xx_gpu.c:1480 a6xx_llc_activate() error: uninitialized symbol 'gpu_scid'. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20211118154903.3.Ie4ac321feb10168af569d9c2b4cf6828bed8122c@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm: Fix null ptr access msm_ioctl_gem_submit()Akhil P Oommen1-0/+1
Fix the below null pointer dereference in msm_ioctl_gem_submit(): 26545.260705: Call trace: 26545.263223: kref_put+0x1c/0x60 26545.266452: msm_ioctl_gem_submit+0x254/0x744 26545.270937: drm_ioctl_kernel+0xa8/0x124 26545.274976: drm_ioctl+0x21c/0x33c 26545.278478: drm_compat_ioctl+0xdc/0xf0 26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100 26545.287169: el0_svc_common+0xf8/0x250 26545.291025: do_el0_svc_compat+0x28/0x54 26545.295066: el0_svc_compat+0x10/0x1c 26545.298838: el0_sync_compat_handler+0xa8/0xcc 26545.303403: el0_sync_compat+0x188/0x1c0 26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008) 26545.318799: Kernel panic - not syncing: Oops: Fatal exception Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20211118154903.2.I3ae019673a0cc45d83a193a7858748dd03dbb820@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm: Demote debug messageRob Clark1-1/+1
Mesa attempts to allocate a cached-coherent buffer in order to determine if cached-coherent is supported. Resulting in seeing this error message once per process with newer mesa. But no reason for this to be more than a debug msg. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211111230214.765476-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm: Make a6xx_gpu_set_freq() staticRob Clark1-1/+1
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211111230151.765228-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm: Restore error return on invalid fenceRob Clark3-0/+10
When converting to use an idr to map userspace fence seqno values back to a dma_fence, we lost the error return when userspace passes seqno that is larger than the last submitted fence. Restore this check. Reported-by: Akhil P Oommen <akhilpo@codeaurora.org> Fixes: a61acbbe9cf8 ("drm/msm: Track "seqno" fences by idr") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20211111192457.747899-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm: Fix wait_fence submitqueue leakRob Clark1-20/+29
We weren't dropping the submitqueue reference in all paths. In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths. Fixes: a61acbbe9cf8 ("drm/msm: Track "seqno" fences by idr") Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211111192457.747899-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm: Fix mmap to include VM_IO and VM_DONTDUMPDouglas Anderson1-2/+1
In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object function") we switched to a new/cleaner method of doing things. That's good, but we missed a little bit. Before that commit, we used to _first_ run through the drm_gem_mmap_obj() case where `obj->funcs->mmap()` was NULL. That meant that we ran: vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); ...and _then_ we modified those mappings with our own. Now that `obj->funcs->mmap()` is no longer NULL we don't run the default code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP was important because we're now getting crashes on Chromebooks that use ARC++ while logging out. Specifically a crash that looks like this (this is on a 5.10 kernel w/ relevant backports but also seen on a 5.15 kernel): Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000 [ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003, pud=00000001002b3003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP [...] CPU: 7 PID: 15734 Comm: crash_dump64 Tainted: G W 5.10.67 #1 [...] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT) pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) pc : __arch_copy_to_user+0xc0/0x30c lr : copyout+0xac/0x14c [...] Call trace: __arch_copy_to_user+0xc0/0x30c copy_page_to_iter+0x1a0/0x294 process_vm_rw_core+0x240/0x408 process_vm_rw+0x110/0x16c __arm64_sys_process_vm_readv+0x30/0x3c el0_svc_common+0xf8/0x250 do_el0_svc+0x30/0x80 el0_svc+0x10/0x1c el0_sync_handler+0x78/0x108 el0_sync+0x184/0x1c0 Code: f8408423 f80008c3 910020c6 36100082 (b8404423) Let's add the two flags back in. While we're at it, the fact that we aren't running the default means that we _don't_ need to clear out VM_PFNMAP, so remove that and save an instruction. NOTE: it was confirmed that VM_IO was the important flag to fix the problem I was seeing, but adding back VM_DONTDUMP seems like a sane thing to do so I'm doing that too. Fixes: 510410bfc034 ("drm/msm: Implement mmap as GEM object function") Reported-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20211110113334.1.I1687e716adb2df746da58b508db3f25423c40b27@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm/devfreq: Fix OPP refcnt leakRob Clark1-0/+5
Reported-by: Douglas Anderson <dianders@chromium.org> Fixes: 9bc95570175a ("drm/msm: Devfreq tuning") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-By: Steev Klimaszewski <steev@kali.org> Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20211105202021.181092-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-21drm/msm/a6xx: Allocate enough space for GMU registersDouglas Anderson1-2/+2
In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for A650") we changed a6xx_get_gmu_registers() to read 3 sets of registers. Unfortunately, we didn't change the memory allocation for the array. That leads to a KASAN warning (this was on the chromeos-5.4 kernel, which has the problematic commit backported to it): BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430 Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209 CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22 Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT) Call trace: dump_backtrace+0x0/0x248 show_stack+0x20/0x2c dump_stack+0x128/0x1ec print_address_description+0x88/0x4a0 __kasan_report+0xfc/0x120 kasan_report+0x10/0x18 __asan_report_store8_noabort+0x1c/0x24 _a6xx_get_gmu_registers+0x144/0x430 a6xx_gpu_state_get+0x330/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 Allocated by task 209: __kasan_kmalloc+0xfc/0x1c4 kasan_kmalloc+0xc/0x14 kmem_cache_alloc_trace+0x1f0/0x2a0 a6xx_gpu_state_get+0x164/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 Fixes: 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for A650") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20211103153049.1.Idfa574ccb529d17b69db3a1852e49b580132035c@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-18Merge drm/drm-next into drm-misc-nextThomas Zimmermann69-1267/+1479
Backmerging from drm/drm-next for v5.16-rc1. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2021-11-11drm/msm: use the new dma_resv_describeChristian König1-19/+1
Instead of hand rolling pretty much the same code. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211103081231.18578-3-christian.koenig@amd.com
2021-10-28Merge tag 'drm-msm-next-2021-10-26' of ↵Dave Airlie60-1157/+1213
https://gitlab.freedesktop.org/drm/msm into drm-next * eDP support in DP sub-driver (for newer SoCs with native eDP output) * dpu irq handling cleanup * CRC support for making igt happy * Support for NO_CONNECTOR bridges * dsi: 14nm phy support for msm8953 * mdp5: support for msm8x53, sdm450, sdm632 * various smaller fixes and cleanups Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsH9EwcpqGNNRJeL99NvFFjHX3SUg+nTYu0dHG5U9+QuA@mail.gmail.com
2021-10-28BackMerge tag 'v5.15-rc7' into drm-nextDave Airlie21-114/+270
The msm next tree is based on rc3, so let's just backmerge rc7 before pulling it in. Signed-off-by: Dave Airlie <airlied@redhat.com>
2021-10-27drm/msm/dsi: Adjust probe orderRob Clark5-38/+42
Switch to the documented order dsi-host vs bridge probe. Tested-by: Amit Pundir <amit.pundir@linaro.org> Tested-by: Caleb Connolly <caleb.connolly@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-22-maxime@cerno.tech
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 13:21:32 +0300