- 06 Apr, 2023 26 commits
-
-
Thomas Zimmermann authored
Move code from ad-hoc fbdev callbacks into DRM client functions and remove the old callbacks. The functions instruct the client to poll for changed output or restore the display. The DRM core calls both, the old callbacks and the new client helpers, from the same places. The new functions perform the same operation as before, so there's no change in functionality. Replace all code that initializes or releases fbdev emulation throughout the driver. Instead initialize the fbdev client by a single call to msm_fbdev_setup() after msm has registered its DRM device. As in most drivers, msm's fbdev emulation now acts like a regular DRM client. The fbdev client setup consists of the initial preparation and the hot-plugging of the display. The latter creates the fbdev device and sets up the fbdev framebuffer. The setup performs display hot-plugging once. If no display can be detected, DRM probe helpers re-run the detection on each hotplug event. A call to drm_dev_unregister() releases the client automatically. No further action is required within msm. If the fbdev framebuffer has been fully set up, struct fb_ops.fb_destroy implements the release. For partially initialized emulation, the fbdev client reverts the initial setup. v2: * handle fbdev module parameter correctly (kernel test robot) Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # RB5 Patchwork: https://patchwork.freedesktop.org/patch/530560/ Link: https://lore.kernel.org/r/20230403124538.8497-9-tzimmermann@suse.deSigned-off-by:
-
Thomas Zimmermann authored
Initialize the fbdev client in the fbdev code with empty helper functions. Also clean up the client. The helpers will later implement various functionality of the DRM client. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Define the module's parameter 'fbdev' in fbdev code. No other code uses it. No functional changes, but simplifies the later conversion to struct drm_client. Signed-off-by:
-
Thomas Zimmermann authored
The DRM device stores a pointer to the fbdev helper. Remove struct msm_drm_private.fbdev, which contains the same value. No functional changes. v2: * test for fb_helper->fb in debugfs code Signed-off-by:
-
Thomas Zimmermann authored
Remove struct msm_fbdev, which is an empty wrapper around struct drm_fb_helper. Use the latter directly. No functional changes. v2: * kfree fbdev helper instance on init errors (Dmitri) Signed-off-by:
-
Thomas Zimmermann authored
Fbdev's struct fb_helper stores a pointer to the framebuffer. Remove struct msm_fbdev.fb, which contains thre same value. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Move aperture management out of the fbdev code. It is unrelated and needs to run even if fbdev support has been disabled. Call the helper at the top of msm_drm_init() to take over hardware from other drivers. v2: * bind all subdevices before acquiring device (Dmitri) Signed-off-by:
-
Thomas Zimmermann authored
Include <linux/io.h> to get the declaration of devm_ioremap() on sparc64. No functional changes. Signed-off-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202303301856.zSmpwZjj-lkp@intel.com/Reviewed-by:
-
Rob Clark authored
If userspace asked for a timeout greater than zero, but less than a jiffy, they clearly weren't planning on spinning. So it is better to round up to one. This fixes an issue with supertuxkart that was (for some reason) spinning on a gl sync with 1ms timeout. CPU time for a demo lap drops from: 15.83user 20.98system 0:47.46elapsed 77%CPU drops to: 8.84user 2.30system 0:46.67elapsed 23%CPU Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
-
Danylo Piliaiev authored
Clashes with C++ `or` keyword Signed-off-by:
Danylo Piliaiev <dpiliaiev@igalia.com> Signed-off-by:
-
Neil Armstrong authored
The DSI compatible changed between patchset revisions, but that wasn't reflected in the bindings. Fix it. Fixes: 0eda3c6c ("dt-bindings: display/msm: add support for the display on SM8450") Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/528589/ Link: https://lore.kernel.org/r/20230323-topic-sm8450-upstream-dt-bindings-fixes-v2-1-0ca1bea1a843@linaro.orgSigned-off-by:
-
Maíra Canal authored
As msm_parse_deps() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in msm in order to simply use the DRM function. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Patchwork: https://patchwork.freedesktop.org/patch/524090/ Link: https://lore.kernel.org/r/20230224214133.411966-2-mcanal@igalia.comSigned-off-by:
-
Johan Hovold authored
Move the include of of_address.h to the top of the file where it belongs. Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
-
Johan Hovold authored
Make sure to destroy the workqueue also in case of early errors during bind (e.g. a subcomponent failing to bind). Since commit c3b790ea ("drm: Manage drm_mode_config_init with drmm_") the mode config will be freed when the drm device is released also when using the legacy interface, but add an explicit cleanup for consistency and to facilitate backporting. Fixes: 060530f1 ("drm/msm: use componentised device support") Cc: stable@vger.kernel.org # 3.15 Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Johan Hovold authored
Add the missing sanity check to handle workqueue allocation failures. Fixes: c8afe684 ("drm/msm: basic KMS driver for snapdragon") Cc: stable@vger.kernel.org # 3.12 Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Johan Hovold authored
Make sure to release the VRAM buffer also in a case a subcomponent fails to bind. Fixes: d863f0c7 ("drm/msm: Call msm_init_vram before binding the gpu") Cc: stable@vger.kernel.org # 5.11 Cc: Craig Tatlor <ctatlor97@gmail.com> Signed-off-by:
-
Johan Hovold authored
Make sure to free the DRM device also in case of early errors during bind(). Fixes: 2027e5b3 ("drm/msm: Initialize MDSS irq domain at probe time") Cc: stable@vger.kernel.org # 5.17 Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
Johan Hovold authored
In case of early initialisation errors and on platforms that do not use the DPU controller, the deinitilisation code can be called with the kms pointer set to NULL. Fixes: f026e431 ("drm/msm: Convert to Linux IRQ interfaces") Cc: stable@vger.kernel.org # 5.14 Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Johan Hovold authored
In case of early initialisation errors and on platforms that do not use the DPU controller, the deinitilisation code can be called with the kms pointer set to NULL. Fixes: 98659487 ("drm/msm: add support to take dpu snapshot") Cc: stable@vger.kernel.org # 5.14 Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
-
Johan Hovold authored
This reverts commit 86365003. A recent commit tried to address a drm device leak in the early msm_drm_uninit() error paths but ended up making things worse. Specifically, it moved the drm device reference put in msm_drm_uninit() to msm_drm_init() which means that the drm would now be leaked on normal unbind. For reasons that were never spelled out, it also added kms NULL pointer checks to a couple of helper functions that had nothing to do with the paths modified by the patch. Instead of trying to salvage this incrementally, let's revert the bad commit so that clean and backportable fixes can be added in its place. Fixes: 86365003 ("drm/msm: Fix failure paths in msm_drm_init()") Cc: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by:
-
Johan Hovold authored
This reverts commit 643b7d08. A recent patch that tried to fix up the msm_drm_init() paths with respect to the workqueue but only ended up making things worse: First, the newly added calls to msm_drm_uninit() on early errors would trigger NULL-pointer dereferences, for example, as the kms pointer would not have been initialised. (Note that these paths were also modified by a second broken error handling patch which in effect cancelled out this part when merged.) Second, the newly added allocation sanity check would still leak the previously allocated drm device. Instead of trying to salvage what was badly broken (and clearly not tested), let's revert the bad commit so that clean and backportable fixes can be added in its place. Fixes: 643b7d08 ("drm/msm: Add missing check and destroy for alloc_ordered_workqueue") Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by:
-
Dmitry Baryshkov authored
Add the platform data for sdm845 platform. Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
-
Dmitry Baryshkov authored
Add platform data for sc8180xp based on sdmshrike-sde.dtsi. Reviewed-by:
-
Dmitry Baryshkov authored
To simplify adding new platforms and to make settings more obvious, rewrite the UBWC setup to use the data structure to pass platform config rather than just calling the functions direcly. Signed-off-by:
-
Neil Armstrong authored
Document the MDSS hardware found on the Qualcomm SM8550 platform. Reviewed-by:
-
Jessica Zhang authored
Add a NULL check before calling prepare_commit() in msm_atomic_commit_tail() Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/523604/ Link: https://lore.kernel.org/r/20230221184256.1436-3-quic_jesszhan@quicinc.comSigned-off-by:
-
- 03 Apr, 2023 2 commits
-
-
Konrad Dybcio authored
The adreno_load_gpu() path is guarded by an error check on adreno_load_fw(). This function is responsible for loading Qualcomm-only-signed binaries (e.g. SQE and GMU FW for A6XX), but it does not take the vendor-signed ZAP blob into account. By embedding the SQE (and GMU, if necessary) firmware into the initrd/kernel, we can trigger and unfortunate path that would not bail out early and proceed with gpu->hw_init(). That will fail, as the ZAP loader path will not find the firmware and return back to adreno_load_gpu(). This error path involves pm_runtime_put_sync() which then calls idle() instead of suspend(). This is suboptimal, as it means that we're not going through the clean shutdown sequence. With at least A619_holi, this makes the GPU not wake up until it goes through at least one more start-fail-stop cycle. The pm_runtime_put_sync that appears in the error path actually does not guarantee that because of the earlier enabling of runtime autosuspend. Fix that by using pm_runtime_put_sync_suspend to force a clean shutdown. Test cases: 1. All firmware baked into kernel 2. error loading ZAP fw in initrd -> load from rootfs at DE start Both succeed on A619_holi (SM6375) and A630 (SDM845). Fixes: 0d997f95 ("drm/msm/adreno: fix runtime PM imbalance at gpu load") Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
-
Konrad Dybcio authored
Recently I contributed the switch to OPP API for all Adreno generations. I did however also skip over the fact that GPUs with a GMU don't specify a core clock of any kind in the GPU node. While that didn't break anything, it did introduce unwanted spam in the dmesg: adreno 5000000.gpu: error -ENOENT: _opp_set_clknames: Couldn't find clock with name: core_clk Guard the entire logic so that it's not used with GMU-equipped GPUs. Fixes: 9f251f93 ("drm/msm/adreno: Use OPP for every GPU generation") Signed-off-by:
-
- 31 Mar, 2023 2 commits
-
-
Konrad Dybcio authored
Add support for matching QFPROM fuse values to get the correct speed bin on A650 (SM8250) GPUs. Reviewed-by:
-
Konrad Dybcio authored
Add support for matching QFPROM fuse values to get the correct speed bin on A640 (SM8150) GPUs. Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by:
-
- 30 Mar, 2023 1 commit
-
-
Dmitry Baryshkov authored
Use adreno_fault_handler() to implement a5xx_fault_handler(). This enables devcoredump support on a5xx platforms, allowing one to capture the crashed GPU state at the time of context fault. Signed-off-by:
-
- 28 Mar, 2023 9 commits
-
-
Dmitry Baryshkov authored
Split the a6xx_fault_handler() into the generic adreno_fault_handler() and platform-specific parts. The adreno_fault_handler() can further be used by a5xx and hopefully by a4xx (at some point). Signed-off-by:
-
Dmitry Baryshkov authored
The commit e25e92e0 ("drm/msm: devcoredump iommu fault support") enabled SMMU stalling to collect GPU state, but only for a6xx. It tied enabling the stall with tha per-instance pagetables creation. Since that commit SoCs with a5xx also gained support for adreno-smmu-priv. Move stalling into generic code and add corresponding resume_translation calls. Signed-off-by:
-
Rob Clark authored
Drop our custom thing and switch to drm_crtc_next_vblank_start() for calculating the time of the start of the next vblank period. Signed-off-by:
-
Rob Clark authored
Add a way for various userspace waits to signal urgency. Signed-off-by:
-
Rob Clark authored
Track the nearest deadline on a fence timeline and set a timer to expire shortly before to trigger boost if the fence has not yet been signaled. v2: rebase Signed-off-by:
-
Rob Clark authored
This series adds a deadline hint to fences, so realtime deadlines such as vblank can be communicated to the fence signaller for power/ frequency management decisions. This is partially inspired by a trick i915 does, but implemented via dma-fence for a couple of reasons: 1) To continue to be able to use the atomic helpers 2) To support cases where display and gpu are different drivers See https://patchwork.freedesktop.org/series/93035/ This does not yet add any UAPI, although this will be needed in a number of cases: 1) Workloads "ping-ponging" between CPU and GPU, where we don't want the GPU freq governor to interpret time stalled waiting for GPU as "idle" time 2) Cases where the compositor is waiting for fences to be signaled before issuing the atomic ioctl, for example to maintain 60fps cursor updates even when the GPU is not able to maintain that framerate. Signed-off-by:
-
Rob Clark authored
For an atomic commit updating a single CRTC (ie. a pageflip) calculate the next vblank time, and inform the fence(s) of that deadline. v2: Comment typo fix (danvet) v3: If there are multiple CRTCs, consider the time of the soonest vblank Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rob Clark authored
Will be used in the next commit to set a deadline on fences that an atomic update is waiting on. v2: Calculate time at *start* of vblank period, not end v3: Fix kbuild complaints Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com>
-
Rob Clark authored
As the finished fence is the one that is exposed to userspace, and therefore the one that other operations, like atomic update, would block on, we need to propagate the deadline from from the finished fence to the actual hw fence. v2: Split into drm_sched_fence_set_parent() (ckoenig) v3: Ensure a thread calling drm_sched_fence_set_deadline_finished() sees fence->parent set before drm_sched_fence_set_parent() does this test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT). Signed-off-by:Luben Tuikov <luben.tuikov@amd.com>
-
