- 20 Jun, 2019 13 commits
-
-
Sean Paul authored
It's a bit dangerous to store the flags in msm_dsi since there's no way to tell when they're populated. Fortunately the only place that uses them is the same place that fills them. So just use a local variable and delete the struct member. Reviewed-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190617201301.133275-5-sean@poorly.run
-
Sean Paul authored
We use the flags in more places than just get_panel, so split them out into a separate function. Reviewed-by:
-
Sean Paul authored
add_display_components() calls of_platform_populate, and we depopluate on pdev remove, but not when probe fails. So if we get a probe deferral in one of the components, we won't depopulate the platform. This causes the core to keep references to devices which should be destroyed, which causes issues when those same devices try to re-initialize on the next probe attempt. I think this is the reason we had issues with the gmu's device-managed resources on deferral (worked around in commit 94e3a17f33a5). Reviewed-by:
-
Sean Paul authored
While I'm in here, cut this out, pdev can't be NULL Reviewed-by:
-
Sean Paul authored
The 10nm pll driver didn't have any failure-path cleanup in register, and the destroy function didn't unregister any of the hardware. This patch adds both. The reason things haven't been blowing up horribly is that msm_drv has a reference count issue that keeps devices alive, so the destroy function was never called. That will be fixed in a follow-up patch. Reviewed-by:
-
Sean Paul authored
We have if (!phy->pll) checks scattered through the driver and if phy->pll is an error pointer, those checks will pass and bad things will happen :( Reviewed-by:
-
Sean Paul authored
Fix the error paths in _dpu_kms_mmu_init() to properly clean up the iommu domain and not call _dpu_kms_mmu_destroy() when things are only partially setup. Reviewed-by:
-
Sean Paul authored
Now that mode_fixup has been removed, we can just rely on the call from drm_helper_probe_single_connector_modes(), Reviewed-by:
-
Georgi Djakov authored
The interconnect API provides an interface for consumer drivers to express their bandwidth needs in the SoC. This data is aggregated and the on-chip interconnect hardware is configured to the most appropriate power/performance profile. Use the API to configure the interconnects and request bandwidth between DDR and the display hardware (MDP port(s) and rotator downscaler). v2: update the path names to be consistent with dpu, handle the NULL path case, updated commit msg from Georgi. v3: split out icc setup into it's own function, and rework logic slightly so no interconnect paths is not fatal. Signed-off-by:Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
-
Abhinav Kumar authored
dpu_mdss_destroy() can get called not just from msm_drm_uninit() but also from msm_drm_bind() in case of any failures. dpu_mdss_destroy() removes the icc voting by calling icc_put. This could accidentally remove the voting done by pm_runtime_enable. To make the voting balanced add a minimum vote in dpu_mdss_init() to avoid any unclocked access. This change depends on the following patch which introduces interconnect binding to MDSS driver: https://patchwork.codeaurora.org/patch/708155/Signed-off-by:
Abhinav Kumar <abhinavk@codeaurora.org> Reviewed-by:
Sean Paul <sean@poorly.run> Signed-off-by:
-
Jayant Shekhar authored
Add interconnect properties such as interconnect provider specifier , the edge source and destination ports which are required by the interconnect API to configure interconnect path for MDSS. Changes in v2: - None Changes in v3: - Remove common property definitions (Rob Herring) Changes in v4: - Use port macros and change port string names (Georgi Djakov) Changes in v5-v7: - None Signed-off-by:
Sravanthi Kollukuduru <skolluku@codeaurora.org> Signed-off-by:
Jayant Shekhar <jshekhar@codeaurora.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jayant Shekhar authored
The interconnect framework is designed to provide a standard kernel interface to control the settings of the interconnects on a SoC. The interconnect API uses a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. MDSS is one of the interconnect consumers which uses the interconnect APIs to get the path between endpoints and set its bandwidth requirement for the given interconnected path. Changes in v2: - Remove error log and unnecessary check (Jordan Crouse) Changes in v3: - Code clean involving variable name change, removal of extra paranthesis and variables (Matthias Kaehlcke) Changes in v4: - Add comments, spacings, tabs, proper port name and icc macro (Georgi Djakov) Changes in v5: - Commit text and parenthesis alignment (Georgi Djakov) Changes in v6: - Change to new icc_set API's (Doug Anderson) Changes in v7: - Fixed a typo Changes in v8: - Handle the of_icc_get() returning NULL case. In practice icc_set_bw() will gracefully handle the case of a NULL path, but it's probably best for clarity to keep num_paths=0 in this case. Signed-off-by:
-
Jayant Shekhar authored
Since the upstream interconnect bus framework has landed upstream, the existing references of custom bus scaling needs to be cleaned up. Changes in v2: - Fixed build error due to partial clean up Changes in v3: - Condense multiple lines into a single line (Sean Paul) Changes in v4-v7: - None Signed-off-by:
-
- 19 Jun, 2019 1 commit
-
-
Nathan Chancellor authored
Clang warns: drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) { ^ ~ drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses after the '!' to evaluate the bitwise operator first if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) { ^ ( ) drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses around left hand side expression to silence this warning if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) { ^ ( ) 1 warning generated. Add parentheses around the bitwise AND so it is evaluated first then negated. Fixes: 3dbbf8f0 ("drm/msm/dsi: Add old timings quirk for 10nm phy") Link: https://github.com/ClangBuiltLinux/linux/issues/547Reported-by:kbuild test robot <lkp@intel.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
- 18 Jun, 2019 23 commits
-
-
Jeffrey Hugo authored
The A540 is a derivative of the A530, and is found in the MSM8998 SoC. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
-
Brian Masney authored
put_iova() would attempt to dereference a NULL pointer via the address space pointer when no IOMMU is present. Correct this by adding the appropriate check. Signed-off-by:
Brian Masney <masneyb@onstation.org> Signed-off-by:
-
Abhinav Kumar authored
When panel probe happens after DSI probe, the DSI probe is deferred as per current design. In the probe defer path dsi device is destroyed. This NULL dsi device could be deferenced by the panel probe in the mipi_dsi_attach path. Check for NULL dsi device before accessing it. Changes in v2: - Add more comments on how this NULL pointer situation will be hit Reported-by:
Jeffrey Hugo <jhugo@codeaurora.org> Tested-by:
-
Jordan Crouse authored
Before loading the zap shader we should ensure that the reserved memory region is big enough to hold the loaded file. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
-
Jeffrey Hugo authored
The DSI controller on the MSM8998 SoC is a 6G v2.0.0 controller which is very similar to the v2.0.1 of SDM845. Signed-off-by:
-
Jeffrey Hugo authored
The v3.0.0 10nm phy has two different implementations between MSM8998 and SDM845, which require different timings calculations. Unfortunately, the hardware designers did not choose to revise the version to account for this delta so implement a quirk instead. Signed-off-by:
-
Jeffrey Hugo authored
The MSM8998 dsi phy is 10nm v3.0.0 like SDM845, however there appear to be minor differences such as the address space location. Signed-off-by:
-
Jeffrey Hugo authored
The DSI phy on MSM8998 is a 10nm design like SDM845, however it has some slightly different quirks which need to be handled by drivers. Provide a separate compatible to assist in handling the specifics. Signed-off-by:
-
Jeffrey Hugo authored
If mdp5_cfg_init fails because of an unknown major version, a null pointer dereference occurs. This is because the caller of init expects error pointers, but init returns NULL on error. Fix this by returning the expected values on error. Fixes: 2e362e17 (drm/msm/mdp5: introduce mdp5_cfg module) Signed-off-by:
-
Jordan Crouse authored
The GPU specific pm_suspend code assumes that the hardware is active when the function is called, which it usually is when called as part of pm_runtime. But during unbind, the pm_suspend functions are called blindly resulting in a bit of a when the hardware wasn't already active (or booted, in the case of the GMU). Instead of calling the pm_suspend function directly, use pm_runtime_force_suspend() which should check the correct state of runtime and call the functions on our behalf or skip them if they are not needed. Signed-off-by:
-
Jordan Crouse authored
In the failure path for dpu_kms_init() it is possible to get to the MMU destroy function with uninitialized MMU structs. Check for NULL and skip if needed. Signed-off-by:
Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by:
-
Jordan Crouse authored
If enabling clocks fails in msm_dss_enable_clk() the code to unwind the settings starts at 'i' which is the clock that just failed. While this isn't harmful it does result in a number of warnings from the clock subsystem while trying to unpreare/disable the very clock that had just failed to prepare/enable. Skip the current failed clock during the unwind to to avoid the extra log spew. Signed-off-by:
-
Jordan Crouse authored
Pass the index of the MMU domain in struct msm_file_private instead of assuming gpu->id throughout the submit path. This clears the way to change ctx->aspace to a per-instance pagetable. Signed-off-by:
-
Jordan Crouse authored
When we move to 64 bit addressing for a5xx and a6xx targets we will start seeing pagefaults at larger addresses so format them appropriately in the log message for easier debugging. Signed-off-by:
-
Jordan Crouse authored
A5XX and newer GPUs can be run in either 32 or 64 bit mode. The GPU registers and the microcode use 64 bit virtual addressing in either case but the upper 32 bits are ignored if the GPU is in 32 bit mode. There is no performance disadvantage to remaining in 64 bit mode even if we are only generating 32 bit addresses so switch over now to prepare for using addresses above 4G on targets that support them. Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [small fixup for unused variable warning] Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jeykumar Sankaran <jsanka@codeaurora.org> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Abhinav Kumar <abhinavk@codeaurora.org> Cc: Bruce Wang <bzwang@chromium.org> Cc: Sravanthi Kollukuduru <skolluku@codeaurora.org> Cc: Fritz Koenig <frkoenig@google.com> Cc: Chandan Uddaraju <chandanu@codeaurora.org> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Mamta Shukla <mamtashukla555@gmail.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Signed-off-by:
-
Nathan Huckleberry authored
Clang produces the following warning drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:477:32: warning: unused variable 'dpu_format_map_tile' [-Wunused-const-variable] static const struct dpu_format dpu_format_map_tile[] = { ^ drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:602:32: warning: unused variable 'dpu_format_map_p010' [-Wunused-const-variable] static const struct dpu_format dpu_format_map_p010[] = { ^ drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:610:32: warning: unused variable 'dpu_format_map_p010_ubwc' [-Wunused-const-variable] static const struct dpu_format dpu_format_map_p010_ubwc[] = { ^ drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:619:32: warning: unused variable 'dpu_format_map_tp10_ubwc' [-Wunused-const-variable] static const struct dpu_format dpu_format_map_tp10_ubwc[] = { ^ Removing the unimplemented modifiers that cause the warning. Cc: clang-built-linux@googlegroups.com Link: https://github.com/ClangBuiltLinux/linux/issues/528Signed-off-by:Nathan Huckleberry <nhuck@google.com> Signed-off-by:
-
Nicholas Mc Guire authored
wait_for_completion_timeout() returns 0 on timeout and aleast 1 otherwise so checking for < makes no sense here. Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Reviewed-by:
-
Sean Paul authored
This comment doesn't make any sense, remove it. Suggested-by:
-
Sean Paul authored
Fold it into dpu_debugfs_init. Cc: Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Sean Paul authored
Instead of reaching into dev->primary for debugfs_root, use the minor passed into debugfs_init. This avoids creating the debug directory under /sys/kernel/debug/ and instead creates the directory under the correct node in /sys/kernel/debug/dri/<node>/ Reported-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
- 24 May, 2019 3 commits
-
-
Sean Paul authored
This rename makes it more clear that everything initialized in the _init function must be cleaned up in a6xx_gmu_remove. This will hopefully dissuade people from using device managed resources (for reasons laid out in the previous patch). Changes in v2: - None Cc: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by:
-
Sean Paul authored
of_find_device_by_node() grabs a dev reference, so make sure we clear it on error and remove. Changes in v2: - Added to the set (Jordan) Cc: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by:
-
Sean Paul authored
The gmu driver is initialized and cleaned up with calls from the gpu driver. As such, the platform device stays valid after a6xx_gmu_remove is called and the device managed resources are not freed. In the case of gpu probe failures or unbind, these resources will remain managed. If the gpu bind is run again (eg: if there's a probe defer somewhere in msm), these resources will be initialized again for the same device, creating multiple references. In the case of irqs, this causes failures since the irqs are not shared (nor should they be). This patch removes all devm_* calls and manually cleans things up in gmu_remove. Changes in v2: - Add iounmap and free_irq to gmu_probe error paths Cc: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by:
-
