- 06 Apr, 2023 5 commits
-
-
Colin Ian King authored
There is a spelling mistake in a drm_dbg_dp message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/526658/ Link: https://lore.kernel.org/r/20230314082050.26331-1-colin.i.king@gmail.comSigned-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Neil Armstrong authored
The SM8450 & SM350 shares the same DT TX IP version, use the SM8350 compatible as fallback for SM8450. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/527564/ Link: https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v6-1-d78313cbc41d@linaro.orgSigned-off-by:
-
Douglas Anderson authored
If our interrupt handler gets called and we don't really handle the interrupt then we should return IRQ_NONE. The current interrupt handler didn't do this, so let's fix it. NOTE: for some of the cases it's clear that we should return IRQ_NONE and some cases it's clear that we should return IRQ_HANDLED. However, there are a few that fall somewhere in between. Specifically, the documentation for when to return IRQ_NONE vs. IRQ_HANDLED is probably best spelled out in the commit message of commit d9e4ad5b ("Document that IRQ_NONE should be returned when IRQ not actually handled"). That commit makes it clear that we should return IRQ_HANDLED if we've done something to make the interrupt stop happening. The case where it's unclear is, for instance, in dp_aux_isr() after we've read the interrupt using dp_catalog_aux_get_irq() and confirmed that "isr" is non-zero. The function dp_catalog_aux_get_irq() not only reads the interrupts but it also "ack"s all the interrupts that are returned. For an "unknown" interrupt this has a very good chance of actually stopping the interrupt from happening. That would mean we've identified that it's our device and done something to stop them from happening and should return IRQ_HANDLED. Specifically, it should be noted that most interrupts that need "ack"ing are ones that are one-time events and doing an "ack" is enough to clear them. However, since these interrupts are unknown then, by definition, it's unknown if "ack"ing them is truly enough to clear them. It's possible that we also need to remove the original source of the interrupt. In this case, IRQ_NONE would be a better choice. Given that returning an occasional IRQ_NONE isn't the absolute end of the world, however, let's choose that course of action. The IRQ framework will forgive a few IRQ_NONE returns now and again (and it won't even log them, which is why we have to log them ourselves). This means that if we _do_ end hitting an interrupt where "ack"ing isn't enough the kernel will eventually detect the problem and shut our device down. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Tested-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
-
Douglas Anderson authored
The DP AUX interrupt handling was a bit of a mess. * There were two functions (one for "native" transfers and one for "i2c" transfers) that were quite similar. It was hard to say how many of the differences between the two functions were on purpose and how many of them were just an accident of how they were coded. * Each function sometimes used "else if" to test for error bits and sometimes didn't and again it was hard to say if this was on purpose or just an accident. * The two functions wouldn't notice whether "unknown" bits were set. For instance, there seems to be a bit "DP_INTR_PLL_UNLOCKED" and if it was set there would be no indication. * The two functions wouldn't notice if more than one error was set. Let's fix this by being more consistent / explicit about what we're doing. By design this could cause different handling for AUX transfers, though I'm not actually aware of any bug fixed as a result of this patch (this patch was created because we simply noticed how odd the old code was by code inspection). Specific notes here: 1. In the old native transfer case if we got "done + wrong address" we'd ignore the "wrong address" (because of the "else if"). Now we won't. 2. In the old native transfer case if we got "done + timeout" we'd ignore the "timeout" (because of the "else if"). Now we won't. 3. In the old native transfer case we'd see "nack_defer" and translate it to the error number for "nack". This differed from the i2c transfer case where "nack_defer" was given the error number for "nack_defer". This 100% can't matter because the only user of this error number treats "nack defer" the same as "nack", so it's clear that the difference between the "native" and "i2c" was pointless here. 4. In the old i2c transfer case if we got "done" plus any error besides "nack" or "defer" then we'd ignore the error. Now we don't. 5. If there is more than one error signaled by the hardware it's possible that we'll report a different one than we used to. I don't know if this matters. If someone is aware of a case this matters we should document it and change the code to make it explicit. 6. One quirk we keep (I don't know if this is important) is that in the i2c transfer case if we see "done + defer" we report that as a "nack". That seemed too intentional in the old code to just drop. After this change we will add extra logging, including: * A warning if we see more than one error bit set. * A warning if we see an unexpected interrupt. * A warning if we get an AUX transfer interrupt when shouldn't. It actually turns out that as a result of this change then at boot we sometimes see an error: [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy That means that, during init, we are seeing DP_INTR_PLL_UNLOCKED. For now I'm going to say that leaving this error reported in the logs is OK-ish and hopefully it will encourage someone to track down what's going on at init time. One last note here is that this change renames one of the interrupt bits. The bit named "i2c done" clearly was used for native transfers being done too, so I renamed it to indicate this. Signed-off-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:
Johan Hovold <johan+linaro@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/530001/ Link: https://lore.kernel.org/r/20230330231517.2747024-1-konrad.dybcio@linaro.orgSigned-off-by:
Rob Clark <robdclark@chromium.org>
-
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 12 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>
-
Rob Clark authored
We had all of the internal driver APIs, but not the all important userspace uABI, in the dma-buf doc. Fix that. And re-arrange the comments slightly as otherwise the comments for the ioctl nr defines would not show up. v2: Fix docs build warning coming from newly including the uabi header in the docs build Signed-off-by:Pekka Paalanen <pekka.paalanen@collabora.com>
-
Rob Clark authored
Add a way to set a deadline on remaining resv fences according to the requested usage. Signed-off-by:
Christian König <christian.koenig@amd.com>
-
Rob Clark authored
Propagate the deadline to all the fences in the chain. v2: Use dma_fence_chain_contained [Tvrtko] Signed-off-by:
-
- 25 Mar, 2023 17 commits
-
-
Rob Clark authored
Move the one-time RPMh setup to a6xx_gmu_init(). To get rid of the hack for one-time init vs start, add in an extra a6xx_rpmh_stop() at the end of the init sequence. Signed-off-by:
-
Rob Clark authored
These allocations are only done the first (successful) time through hw_init() so they won't actually happen in the job_run() path. But lockdep doesn't know this. So dis-entangle them from the hw_init() path. Signed-off-by:
-
Rob Clark authored
It is already a no-op, since we've already loaded the fw from adreno_load_gpu(), so drop the redundant call. Signed-off-by:
-
Rob Clark authored
Avoid allocation under idr_lock, to prevent deadlock against the job_free() path (which runs on same thread as job_run(), which makes it also part of the fence-signaling path. Signed-off-by:
-
Rob Clark authored
Needed to idr_preload() which returns with preemption disabled. Signed-off-by:
-
Rob Clark authored
Now that everything that controls which LRU an obj lives in *except* the backing pages is protected by the LRU lock, add a special path to unpin in the job_run() path, where we are assured that we already have backing pages and will not be racing against eviction (because the GEM object's dma_resv contains the fence that will be signaled when the submit/job completes). Signed-off-by:
-
Rob Clark authored
Since the LRU lock is already acquired when moving an obj between LRUs, we can use it to protect pin_count and madv, without any significant change in locking (ie. it just expands the scope of the lock by a hand- ful of instructions). This prepares the way to decrement the pin_count in the job_run() path without needing to hold the obj lock, to avoid a potential deadlock (or rather stall) caused by the fence-signaling path (job_run()) blocking on shrinker/reclaim. (Only a stall because the wait for fence signaling wait_for_idle() is not infinite.) Signed-off-by:
-
Rob Clark authored
Just code-motion. Signed-off-by:
-
Rob Clark authored
Export the locked version or lru's move_tail(). Signed-off-by:
-
Rob Clark authored
vmap'ing is just pinning in disguise. So treat it as such and simplify the LRU tracking. Signed-off-by:
-
Rob Clark authored
We need to use the inuse count to track that a BO is pinned until we have the hw_fence. But we want to remove the obj lock from the job_run() path as this could deadlock against reclaim/shrinker (because it is blocking the hw_fence from eventually being signaled). So split that tracking out into a per-vma lock with narrower scope. Signed-off-by:
-
Rob Clark authored
Stop open coding VMA construction, which will be needed in the next commit. And since the VMA already has a ptr to the adress space, stop passing that around everywhere. (Also, an aspace always has an mmu so we can drop a couple pointless NULL checks.) Signed-off-by:
-
Rob Clark authored
The flags are only accessed (1) when submit is constructed, before enqueuing to gpu sched (ie. when still visible to only the task calling the submit ioctl), (2) here, where we own a reference to the submit and are serialized on the gpu sched thread, and (3) after the submit is retired and last reference is dropped, which is serialized on the submit's reference count. Hence locking is unneeded here. Signed-off-by:
-
Rob Clark authored
Avoid allocating memory in job_run() by pre-allocating the hw_fence. Signed-off-by:
-
Arnd Bergmann authored
Selecting CONFIG_PM_GENERIC_DOMAINS causes a build failure when CONFIG_PM is not enabled: WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS Depends on [n]: PM [=n] Selected by [m]: - DRM_MSM [=m] && HAS_IOMEM [=y] && DRM [=m] && (ARCH_QCOM [=y] || SOC_IMX5 || COMPILE_TEST [=y]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] && (QCOM_OCMEM [=y] || QCOM_OCMEM [=y]=n) && (QCOM_LLCC [=n] || QCOM_LLCC [=n]=n) && (QCOM_COMMAND_DB [=y] || QCOM_COMMAND_DB [=y]=n) && DEVFREQ_GOV_SIMPLE_ONDEMAND [=y] drivers/base/power/domain.c:654:13: error: use of undeclared identifier 'pm_wq' queue_work(pm_wq, &genpd->power_off_work); ^ drivers/base/power/domain.c:853:26: error: no member named 'ignore_children' in 'struct dev_pm_info' if (!dev || dev->power.ignore_children) ~~~~~~~~~~ ^ Fixes: c11fa120 ("drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/528597/ Link: https://lore.kernel.org/r/20230324095502.3289094-1-arnd@kernel.orgSigned-off-by:
-
Rob Clark authored
Propagate the deadline to all the fences in the array. Signed-off-by:
-
Rob Clark authored
Add a way to hint to the fence signaler of an upcoming deadline, such as vblank, which the fence waiter would prefer not to miss. This is to aid the fence signaler in making power management decisions, like boosting frequency as the deadline approaches and awareness of missing deadlines so that can be factored in to the frequency scaling. v2: Drop dma_fence::deadline and related logic to filter duplicate deadlines, to avoid increasing dma_fence size. The fence-context implementation will need similar logic to track deadlines of all the fences on the same timeline. [ckoenig] v3: Clarify locking wrt. set_deadline callback v4: Clarify in docs comment that this is a hint v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v6: More docs v7: Fix typo, clarify past deadlines Signed-off-by:Bagas Sanjaya <bagasdotme@gmail.com>
-
- 21 Mar, 2023 1 commit
-
-
Rob Clark authored
It's been a bit overdue. Regen headers to pull in a2xx perfcntr updates, etc. Signed-off-by:
-
