- 28 Mar, 2023 8 commits
-
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/525816/ Link: https://lore.kernel.org/r/20230308155322.344664-13-robdclark@gmail.com
-
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 <robdclark@chromium.org>
-
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: Rob Clark <robdclark@chromium.org> Reviewed-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: Rob Clark <robdclark@chromium.org> Reviewed-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: Rob Clark <robdclark@chromium.org> Acked-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: Rob Clark <robdclark@chromium.org> Acked-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: Rob Clark <robdclark@chromium.org> Reviewed-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: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com>
-
- 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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527854/ Link: https://lore.kernel.org/r/20230320144356.803762-15-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527852/ Link: https://lore.kernel.org/r/20230320144356.803762-14-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527849/ Link: https://lore.kernel.org/r/20230320144356.803762-13-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527847/ Link: https://lore.kernel.org/r/20230320144356.803762-12-robdclark@gmail.com
-
Rob Clark authored
Needed to idr_preload() which returns with preemption disabled. Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527846/ Link: https://lore.kernel.org/r/20230320144356.803762-11-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527845/ Link: https://lore.kernel.org/r/20230320144356.803762-10-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527843/ Link: https://lore.kernel.org/r/20230320144356.803762-9-robdclark@gmail.com
-
Rob Clark authored
Just code-motion. Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527841/ Link: https://lore.kernel.org/r/20230320144356.803762-8-robdclark@gmail.com
-
Rob Clark authored
Export the locked version or lru's move_tail(). Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527835/ Link: https://lore.kernel.org/r/20230320144356.803762-7-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527837/ Link: https://lore.kernel.org/r/20230320144356.803762-6-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527839/ Link: https://lore.kernel.org/r/20230320144356.803762-5-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527833/ Link: https://lore.kernel.org/r/20230320144356.803762-4-robdclark@gmail.com
-
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527830/ Link: https://lore.kernel.org/r/20230320144356.803762-3-robdclark@gmail.com
-
Rob Clark authored
Avoid allocating memory in job_run() by pre-allocating the hw_fence. Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527832/ Link: https://lore.kernel.org/r/20230320144356.803762-2-robdclark@gmail.com
-
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 <robdclark@chromium.org>
-
Rob Clark authored
Propagate the deadline to all the fences in the array. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com>
-
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: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-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: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527926/ Link: https://lore.kernel.org/r/20230320185416.938842-2-robdclark@gmail.com
-
- 20 Mar, 2023 14 commits
-
-
Rob Clark authored
The next generated header update will drop the _LO/_HI suffix, now that the userspace tooling properly understands 64b vs 32b regs (and the _LO/ _HI workarounds are getting cleaned up). So convert to using the 64b reg helpers in prep. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/527923/ Link: https://lore.kernel.org/r/20230320185416.938842-1-robdclark@gmail.com
-
Adam Skladowski authored
Downstream driver appears to not support preemption on A510 target, trying to use one make device slow and fill log with rings related errors. Set num_rings to 1 to disable preemption. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: e20c9284 ("drm/msm/adreno: Add support for Adreno 510 GPU") Signed-off-by: Adam Skladowski <a39.skl@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/526898/ Link: https://lore.kernel.org/r/20230314221757.13096-1-a39.skl@gmail.comSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Abhinav Kumar authored
Update the URI for MSM DRM bugs for users to be able to file bugs at a centralized location. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Acked-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/525026/ Link: https://lore.kernel.org/r/1677972416-7353-1-git-send-email-quic_abhinavk@quicinc.comSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Johan Hovold authored
Clean up the component ops initialisers which were indented one level too far. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/524973/ Link: https://lore.kernel.org/r/20230303164807.13124-5-johan+linaro@kernel.orgSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Johan Hovold authored
The runtime PM status can only be updated while runtime PM is disabled. Drop the bogus pm_runtime_set_active() call that was made after enabling runtime PM and which (incidentally but correctly) left the runtime PM status set to 'suspended'. Fixes: 2c087a33 ("drm/msm/adreno: Load the firmware before bringing up the hardware") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/524972/ Link: https://lore.kernel.org/r/20230303164807.13124-4-johan+linaro@kernel.orgSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Johan Hovold authored
A recent commit moved enabling of runtime PM to GPU load time (first open()) but failed to update the error paths so that runtime PM is disabled if initialisation of the GPU fails. This would trigger a warning about the unbalanced disable count on the next open() attempt. Note that pm_runtime_put_noidle() is sufficient to balance the usage count when pm_runtime_put_sync() fails (and is chosen over pm_runtime_resume_and_get() for consistency reasons). Fixes: 4b18299b ("drm/msm/adreno: Defer enabling runpm until hw_init()") Cc: stable@vger.kernel.org # 6.0 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/524971/ Link: https://lore.kernel.org/r/20230303164807.13124-3-johan+linaro@kernel.orgSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
Add the dev_pm_opp_of_find_icc_paths() call to let the OPP framework handle bus voting as part of power level setting. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/523787/ Link: https://lore.kernel.org/r/20230223-topic-opp-v3-7-5f22163cd1df@linaro.orgSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
Add support for gpu_busy on a4xx, which is required for devfreq support. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/523791/ Link: https://lore.kernel.org/r/20230223-topic-opp-v3-6-5f22163cd1df@linaro.orgSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
Add support for gpu_busy on a3xx, which is required for devfreq support. Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> #ifc6410 Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/523789/ Link: https://lore.kernel.org/r/20230223-topic-opp-v3-5-5f22163cd1df@linaro.orgSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
Some older GPUs (namely a2xx with no opp tables at all and a320 with downstream-remnants gpu pwrlevels) used not to have OPP tables. They both however had just one frequency defined, making it extremely easy to construct such an OPP table from within the driver if need be. Do so and switch all clk_set_rate calls on core_clk to their OPP counterparts. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/523784/ Link: https://lore.kernel.org/r/20230223-topic-opp-v3-3-5f22163cd1df@linaro.orgSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Akhil P Oommen authored
As per the recommended recovery sequence of adreno gpu, cx gdsc should collapse at hardware before it is turned back ON. This helps to clear out the stale states in hardware before it is reinitialized. Use the genpd notifier along with the newly introduced dev_pm_genpd_synced_poweroff() api to ensure that cx gdsc has collapsed before we turn it back ON. Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/516472/ Link: https://lore.kernel.org/r/20230102161757.v5.5.I9e10545c6a448d5eb1b734839b871d1b3146dac3@changeidSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Akhil P Oommen authored
Remove the unused 'reset' interface which was supposed to help to ensure that cx gdsc has collapsed during gpu recovery. This is was not enabled so far due to missing gpucc driver support. Similar functionality using genpd framework will be implemented in the upcoming patch. This effectively reverts commit 1f6cca40 ("drm/msm/a6xx: Ensure CX collapse during gpu recovery"). Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Patchwork: https://patchwork.freedesktop.org/patch/516470/ Link: https://lore.kernel.org/r/20230102161757.v5.4.I96e0bf9eaf96dd866111c1eec8a4c9b70fd7cbcb@changeidSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Akhil P Oommen authored
When a device has multiple power domains, dev->power_domain is left empty during probe. That didn't cause any issue so far because we are freeloading on smmu driver's vote on cx gdsc. Instead of that, create a device_link between cx genpd device and gmu device to keep a vote from gpu driver. Before this patch: localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary gx_gdsc on 0 /devices/genpd:1:3d6a000.gmu active 0 cx_gdsc on 0 /devices/platform/soc@0/3da0000.iommu active 0 After this patch: localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary gx_gdsc on 0 /devices/genpd:1:3d6a000.gmu active 0 cx_gdsc on 0 /devices/platform/soc@0/3da0000.iommu active 0 /devices/genpd:0:3d6a000.gmu active 0 Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/516468/ Link: https://lore.kernel.org/r/20230102161757.v5.3.I7f545d8494dcdbe6e96a15fbe8aaf5bb0c003d50@changeidSigned-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Merge drm-next into msm-next to pick up external clk and PM dependencies for improved a6xx GPU reset sequence. Signed-off-by: Rob Clark <robdclark@chromium.org>
-