summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
AgeCommit message (Collapse)Author
2025-01-03drm/msm: adreno: add plumbing to generate bandwidth vote table for GMUNeil Armstrong
The Adreno GPU Management Unit (GMU) can also scale DDR Bandwidth along the Frequency and Power Domain level, but by default we leave the OPP core scale the interconnect ddr path. While scaling via the interconnect path was sufficient, newer GPUs like the A750 requires specific vote paremeters and bandwidth to achieve full functionality. In order to calculate vote values used by the GPU Management Unit (GMU), we need to parse all the possible OPP Bandwidths and create a vote value to be sent to the appropriate Bus Control Modules (BCMs) declared in the GPU info struct. This vote value is called IB, while on the other side the GMU also takes another vote called AB which is a 16bit quantized value of the floor bandwidth against the maximum supported bandwidth. The AB vote will be calculated later when setting the frequency. The vote array will then be used to dynamically generate the GMU bw_table sent during the GMU power-up. Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/629395/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-03drm/msm/a6xx: Use posamble to reset counters on preemptionAntonino Maniscalco
Use the postamble to reset perf counters when switching between rings, except when sysprof is enabled, analogously to how they are reset between submissions when switching pagetables. Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Tested-by: Rob Clark <robdclark@gmail.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8450-HDK Signed-off-by: Antonino Maniscalco <antomani103@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/618024/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-03drm/msm/a6xx: Implement preemption for a7xx targetsAntonino Maniscalco
This patch implements preemption feature for A6xx targets, this allows the GPU to switch to a higher priority ringbuffer if one is ready. A6XX hardware as such supports multiple levels of preemption granularities, ranging from coarse grained(ringbuffer level) to a more fine grained such as draw-call level or a bin boundary level preemption. This patch enables the basic preemption level, with more fine grained preemption support to follow. Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Tested-by: Rob Clark <robdclark@gmail.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8450-HDK Signed-off-by: Sharat Masetty <smasetty@codeaurora.org> Signed-off-by: Antonino Maniscalco <antomani103@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/618021/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-03drm/msm/a6xx: Add a pwrup_list field to a6xx_infoAntonino Maniscalco
Add a field to contain the pwup_reglist needed for preemption. Signed-off-by: Antonino Maniscalco <antomani103@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/618018/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a6xx: Store correct gmu_cgc_mode in struct a6xx_infoKonrad Dybcio
Store the correct values that we happen to have for some A7xx SKUs in the GPU info struct and fill out the missing information for A6xx GPUs based on downstream kernel information. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/611094/ [add missing entry to a615 catalog to resolve conflict] Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-09-01drm/msm/a6xx: Store primFifoThreshold in struct a6xx_infoKonrad Dybcio
The if-else monster is so unmaintainable that one case is repeated twice. Get rid of it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/611092/ [add missing entry to a615 catalog to resolve conflict] Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-06-29drm/msm/adreno: Add support for X185 GPUAkhil P Oommen
Add support in drm/msm driver for the Adreno X185 gpu found in Snapdragon X1 Elite chipset. Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/601399/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-06-20drm/msm/adreno: Move CP_PROTECT settings to hw catalogRob Clark
Move the CP_PROTECT settings into the hw catalog. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/599731/
2024-06-20drm/msm/adreno: Move hwcg table into a6xx specific infoRob Clark
Introduce a6xx_info where we can stash gen specific stuff without polluting the toplevel adreno_info struct. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/599728/
2024-04-22drm/msm: Drop msm_read/writelKonrad Dybcio
Totally useless. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Patchwork: https://patchwork.freedesktop.org/patch/588804/ Link: https://lore.kernel.org/r/20240410-topic-msm_rw-v1-1-e1fede9ffaba@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-08-17drm/msm/a6xx: Move LLC accessors to the common headerKonrad Dybcio
Move these wrappers in preparation for use in a6xx_gmu.c Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # sm8450 Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/551824/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-08-07drm/msm/a6xx: Fix misleading commentRob Clark
The range is actually len+1. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/545099/
2023-06-18drm/msm/a6xx: Introduce GMU wrapper supportKonrad Dybcio
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs but don't implement the associated GMUs. This is due to the fact that the GMU directly pokes at RPMh. Sadly, this means we have to take care of enabling & scaling power rails, clocks and bandwidth ourselves. Reuse existing Adreno-common code and modify the deeply-GMU-infused A6XX code to facilitate these GPUs. This involves if-ing out lots of GMU callbacks and introducing a new type of GMU - GMU wrapper (it's the actual name that Qualcomm uses in their downstream kernels). This is essentially a register region which is convenient to model as a device. We'll use it for managing the GDSCs. The register layout matches the actual GMU_CX/GX regions on the "real GMU" devices and lets us reuse quite a bit of gmu_read/write/rmw calls. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/542766/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-06-18drm/msm/a6xx: Add a helper for software-resetting the GPUKonrad Dybcio
Introduce a6xx_gpu_sw_reset() in preparation for adding GMU wrapper GPUs and reuse it in a6xx_gmu_force_off(). This helper, contrary to the original usage in GMU code paths, adds a readback+delay sequence to ensure that the reset is never deasserted too quickly due to e.g. OoO execution going crazy. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/542758/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-06-18drm/msm/a6xx: Move a6xx_bus_clear_pending_transactions to a6xx_gpuKonrad Dybcio
This function is responsible for telling the GPU to halt transactions on all of its relevant buses, drain them and leave them in a predictable state, so that the GPU can be e.g. reset cleanly. Move the function to a6xx_gpu.c, remove the static keyword and add a prototype in a6xx_gpu.h to accomodate for the move. Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/542762/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-01-05drm/msm/a6xx: Avoid gx gbit halt during rpm suspendAkhil P Oommen
As per the downstream driver, gx gbif halt is required only during recovery sequence. So lets avoid it during regular rpm suspend. Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/515279/ Link: https://lore.kernel.org/r/20221216223253.1.Ice9c47bfeb1fddb8dc377a3491a043a3ee7fca7d@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-07-06drm/msm: Avoid unclocked GMU register access in 6xx gpu_busyDouglas Anderson
From testing on sc7180-trogdor devices, reading the GMU registers needs the GMU clocks to be enabled. Those clocks get turned on in a6xx_gmu_resume(). Confusingly enough, that function is called as a result of the runtime_pm of the GPU "struct device", not the GMU "struct device". Unfortunately the current a6xx_gpu_busy() grabs a reference to the GMU's "struct device". The fact that we were grabbing the wrong reference was easily seen to cause crashes that happen if we change the GPU's pm_runtime usage to not use autosuspend. It's also believed to cause some long tail GPU crashes even with autosuspend. We could look at changing it so that we do pm_runtime_get_if_in_use() on the GPU's "struct device", but then we run into a different problem. pm_runtime_get_if_in_use() will return 0 for the GPU's "struct device" the whole time when we're in the "autosuspend delay". That is, when we drop the last reference to the GPU but we're waiting a period before actually suspending then we'll think the GPU is off. One reason that's bad is that if the GPU didn't actually turn off then the cycle counter doesn't lose state and that throws off all of our calculations. Let's change the code to keep track of the suspend state of devfreq. msm_devfreq_suspend() is always called before we actually suspend the GPU and msm_devfreq_resume() after we resume it. This means we can use the suspended state to know if we're powered or not. NOTE: one might wonder when exactly our status function is called when devfreq is supposed to be disabled. The stack crawl I captured was: msm_devfreq_get_dev_status devfreq_simple_ondemand_func devfreq_update_target qos_notifier_call qos_max_notifier_call blocking_notifier_call_chain pm_qos_update_target freq_qos_apply apply_constraint __dev_pm_qos_update_request dev_pm_qos_update_request msm_devfreq_idle_work Fixes: eadf79286a4b ("drm/msm: Check for powered down HW in the devfreq callbacks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/489124/ Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-11-28drm/msm: Drop priv->lastctxRob Clark
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-10-01drm/msm/a6xx: Track current ctx by seqnoRob Clark
In theory a context can be destroyed and a new one allocated at the same address, making the pointer comparision to detect when we don't need to update the current pagetables invalid. Instead assign a sequence number to each context on creation, and use this for the check. Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables") Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-06-23drm/msm: Convert to use resource-managed OPP APIYangtao Li
Use resource-managed OPP API to simplify code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210314163408.22292-12-digetx@gmail.com Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-06-08drm/msm/a6xx: update/fix CP_PROTECT initializationJonathan Marek
Update CP_PROTECT register programming based on downstream. A6XX_PROTECT_RW is renamed to A6XX_PROTECT_NORDWR to make things aligned and also be more clear about what it does. Note that this required switching to use the CP_ALWAYS_ON_COUNTER as the GMU counter is not accessible from the cmdstream. Which also means using the CPU counter for the msm_gpu_submit_flush() tracepoint (as catapult depends on being able to compare this to the start/end values captured in cmdstream). This may need to be revisited when IFPC is enabled. Also, compared to downstream, this opens up CP_PERFCTR_CP_SEL as the userspace performance tooling (fdperf and pps-producer) expect to be able to configure the CP counters. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20210513171431.18632-5-jonathan@marek.ca [switch to CP_ALWAYS_ON_COUNTER, open up CP_PERFCNTR_CP_SEL, and spiff up commit msg] Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-31drm/msm: Add speed-bin support to a618 gpuAkhil P Oommen
Some GPUs support different max frequencies depending on the platform. To identify the correct variant, we should check the gpu speedbin fuse value. Add support for this speedbin detection to a6xx family along with the required fuse details for a618 gpu. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-11-29drm/msm/a6xx: Add support for using system cache on MMU500 based targetsJordan Crouse
GPU targets with an MMU-500 attached have a slightly different process for enabling system cache. Use the compatible string on the IOMMU phandle to see if an MMU-500 is attached and modify the programming sequence accordingly. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-11-29drm/msm/a6xx: Add support for using system cache(LLC)Sharat Masetty
The last level system cache can be partitioned to 32 different slices of which GPU has two slices preallocated. One slice is used for caching GPU buffers and the other slice is used for caching the GPU SMMU pagetables. This talks to the core system cache driver to acquire the slice handles, configure the SCID's to those slices and activates and deactivates the slices upon GPU power collapse and restore. Some support from the IOMMU driver is also needed to make use of the system cache to set the right TCR attributes. GPU then has the ability to override a few cacheability parameters which it does to override write-allocate to write-no-allocate as the GPU hardware does not benefit much from it. DOMAIN_ATTR_IO_PGTABLE_CFG is another domain level attribute used by the IOMMU driver for pagetable configuration which will be used to set a quirk initially to set the right attributes to cache the hardware pagetables into the system cache. Signed-off-by: Sharat Masetty <smasetty@codeaurora.org> [saiprakash.ranjan: fix to set attr before device attach to iommu and rebase] Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-09-15drm/msm: a6xx: Use WHERE_AM_I for eligible targetsJordan Crouse
Support the WHERE_AM_I opcode for the A618, A630 and A640 GPUs if the microcode supports it. The WHERE_AM_I opcode allows the RPTR shadow to be updated in priviliged memory which protects the shadow from being read or written from user submissions. A650 already supports extended APRIV have built in hardware support for to access privilged memory from the CP and can go back to using the hardware RPTR shadow feature. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-09-12drm/msm/a6xx: Add support for per-instance pagetablesJordan Crouse
Add support for using per-instance pagetables if all the dependencies are available. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org>
2020-07-31drm: msm: a6xx: send opp instead of a frequencySharat Masetty
This patch changes the plumbing to send the devfreq recommended opp rather than the frequency. Also consolidate and rearrange the code in a6xx to set the GPU frequency and the icc vote in preparation for the upcoming changes for GPU->DDR scaling votes. Signed-off-by: Sharat Masetty <smasetty@codeaurora.org> Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02drm: msm: a6xx: Add support for A618Sharat Masetty
This patch adds support for enabling Graphics Bus Interface(GBIF) used in multiple A6xx series chipets. Also makes changes to the PDC/RSC sequencing specifically required for A618. This is needed for proper interfacing with RPMH. Signed-off-by: Sharat Masetty <smasetty@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-05-24drm/msm/a6xx: Rename a6xx_gmu_probe to a6xx_gmu_initSean Paul
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: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190523171653.138678-6-sean@poorly.run
2019-04-19drm/msm/a6xx: Make GMU reset usefulJordan Crouse
Now that the GX domain is sorted we can wire up a working GMU reset. IF a GMU hang was detected then try to forcefully shut down the GMU in the power down sequence which should ensure that it can recover normally on the next power up. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2018-12-11drm/msm/a6xx: Add a6xx gpu stateJordan Crouse
Add support for gathering and dumping the a6xx GPU state including registers, GMU registers, indexed registers, shader blocks, context clusters and debugbus. v2: Fix bugs discovered by Sharat Masetty Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-10-04drm/msm/a6xx: Add devfreq support for a6xxSharat Masetty
Implement routines to estimate GPU busy time and fetching the current frequency for the polling interval. This is required by the devfreq framework which recommends a frequency change if needed. The driver code then tries to set this new frequency on the GPU by sending an Out Of Band(OOB) request to the GMU. Signed-off-by: Sharat Masetty <smasetty@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-08-10drm/msm: Add A6XX device supportJordan Crouse
Add support for the A6XX family of Adreno GPUs. The biggest addition is the GMU (Graphics Management Unit) which takes over most of the power management of the GPU itself but in a ironic twist of fate needs a goodly amount of management itself. Add support for the A6XX core code, the GMU and the HFI (hardware firmware interface) queue that the CPU uses to communicate with the GMU. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>