History log of /linux-master/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
Revision Date Author Comments
# d2bcca0c 15-Feb-2024 Neil Armstrong <neil.armstrong@linaro.org>

drm/msm: add support for A750 GPU

Add support for the A750 GPU found on the SM8650 platform

Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU
doesn't have an HWCFG block but a separate register set.

The A750 GPU info are added under the adreno_is_a750() macro and
the ADRENO_7XX_GEN3 family id.

Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/578693/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 54615eda 17-Jan-2024 Rob Clark <robdclark@chromium.org>

drm/msm/adreno: Update generated headers

This updates the GPU headers to latest from mesa, using gen_header.py
(which is used to generate headers at bulid time for mesa), rather than
headergen2 (which doesn't have proper support for A6XX vs A7XX register
variants).

Mostly just uninteresting churn, but there are a couple spots in a7xx
paths which update REG_A6XX_foo to REG_A7XX_foo for registers which are
a7xx specific.

Cc: Connor Abbott <cwabbott0@gmail.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/574880/


# b9986846 13-Oct-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Fix up QMP handling

The commit referenced in the Fixes tag had a couple problems (as
pointed out by Dan):

- qmp_put was never called, resulting in refcnt leaks
- failling to acquire the QMP mailbox on A7xx would not undo the probe
function properly
- the qmp_put call present in the code was unreachable

Fix all of these issues.

Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: 88a0997f2f94 ("drm/msm/a6xx: Send ACD state to QMP at GMU resume")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/562761/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 1f8c29e8 25-Sep-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Add A740 support

A740 builds upon the A730 IP, shuffling some values and registers
around. More differences will appear when things like BCL are
implemented.

adreno_is_a740_family is added in preparation for more A7xx GPUs,
the logic checks will be valid resulting in smaller diffs.

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/559291/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 88a0997f 25-Sep-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Send ACD state to QMP at GMU resume

The QMP mailbox expects to be notified of the ACD (Adaptive Clock
Distribution) state. Get a handle to the mailbox at probe time and
poke it at GMU resume.

Since we don't fully support ACD yet, hardcode the message to "val: 0"
(state = disabled).

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/559287/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# af66706a 25-Sep-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Add skeleton A7xx support

A7xx GPUs are - from kernel's POV anyway - basically another generation
of A6xx. They build upon the A650/A660_family advancements, skipping some
writes (presumably more values are preset correctly on reset), adding
some new ones and changing others.

One notable difference is the introduction of a second shadow, called BV.
To handle this with the current code, allocate it right after the current
RPTR shadow.

BV handling and .submit are mostly based on Jonathan Marek's work.

All A7xx GPUs are assumed to have a GMU.
A702 is not an A7xx-class GPU, it's a weird forked A610.

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/559285/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# f9bff0e3 02-Aug-2023 Matthew Wilcox (Oracle) <willy@infradead.org>

minmax: add in_range() macro

Patch series "New page table range API", v6.

This patchset changes the API used by the MM to set up page table entries.
The four APIs are:

set_ptes(mm, addr, ptep, pte, nr)
update_mmu_cache_range(vma, addr, ptep, nr)
flush_dcache_folio(folio)
flush_icache_pages(vma, page, nr)

flush_dcache_folio() isn't technically new, but no architecture
implemented it, so I've done that for them. The old APIs remain around
but are mostly implemented by calling the new interfaces.

The new APIs are based around setting up N page table entries at once.
The N entries belong to the same PMD, the same folio and the same VMA, so
ptep++ is a legitimate operation, and locking is taken care of for you.
Some architectures can do a better job of it than just a loop, but I have
hesitated to make too deep a change to architectures I don't understand
well.

One thing I have changed in every architecture is that PG_arch_1 is now a
per-folio bit instead of a per-page bit when used for dcache clean/dirty
tracking. This was something that would have to happen eventually, and it
makes sense to do it now rather than iterate over every page involved in a
cache flush and figure out if it needs to happen.

The point of all this is better performance, and Fengwei Yin has measured
improvement on x86. I suspect you'll see improvement on your architecture
too. Try the new will-it-scale test mentioned here:
https://lore.kernel.org/linux-mm/20230206140639.538867-5-fengwei.yin@intel.com/
You'll need to run it on an XFS filesystem and have
CONFIG_TRANSPARENT_HUGEPAGE set.

This patchset is the basis for much of the anonymous large folio work
being done by Ryan, so it's received quite a lot of testing over the last
few months.


This patch (of 38):

Determine if a value lies within a range more efficiently (subtraction +
comparison vs two comparisons and an AND). It also has useful (under some
circumstances) behaviour if the range exceeds the maximum value of the
type. Convert all the conflicting definitions of in_range() within the
kernel; some can use the generic definition while others need their own
definition.

Link: https://lkml.kernel.org/r/20230802151406.3735276-1-willy@infradead.org
Link: https://lkml.kernel.org/r/20230802151406.3735276-2-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>


# 3136a0f8 03-Aug-2023 Rob Clark <robdclark@chromium.org>

drm/msm/a6xx: Fix GMU lockdep splat

For normal GPU devfreq, we need to acquire the GMU lock while already
holding devfreq locks. But in the teardown path, we were calling
dev_pm_domain_detach() while already holding the GMU lock, resulting in
this lockdep splat:

======================================================
WARNING: possible circular locking dependency detected
6.4.3-debug+ #3 Not tainted
------------------------------------------------------
ring0/391 is trying to acquire lock:
ffffff80a025c078 (&devfreq->lock){+.+.}-{3:3}, at: qos_notifier_call+0x30/0x74

but task is already holding lock:
ffffff809b8c1ce8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0x78

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #4 (&(c->notifiers)->rwsem){++++}-{3:3}:
down_write+0x58/0x74
__blocking_notifier_chain_register+0x64/0x84
blocking_notifier_chain_register+0x1c/0x28
freq_qos_add_notifier+0x5c/0x7c
dev_pm_qos_add_notifier+0xd4/0xf0
devfreq_add_device+0x42c/0x560
devm_devfreq_add_device+0x6c/0xb8
msm_devfreq_init+0xa8/0x16c [msm]
msm_gpu_init+0x368/0x54c [msm]
adreno_gpu_init+0x248/0x2b0 [msm]
a6xx_gpu_init+0x2d0/0x384 [msm]
adreno_bind+0x264/0x2bc [msm]
component_bind_all+0x124/0x1f4
msm_drm_bind+0x2d0/0x5f4 [msm]
try_to_bring_up_aggregate_device+0x88/0x1a4
__component_add+0xd4/0x128
component_add+0x1c/0x28
dp_display_probe+0x37c/0x3c0 [msm]
platform_probe+0x70/0xc0
really_probe+0x148/0x280
__driver_probe_device+0xfc/0x114
driver_probe_device+0x44/0x100
__device_attach_driver+0x64/0xdc
bus_for_each_drv+0xb0/0xd8
__device_attach+0xe4/0x140
device_initial_probe+0x1c/0x28
bus_probe_device+0x44/0xb0
deferred_probe_work_func+0xb0/0xc8
process_one_work+0x288/0x3d8
worker_thread+0x1f0/0x260
kthread+0xf0/0x100
ret_from_fork+0x10/0x20

-> #3 (dev_pm_qos_mtx){+.+.}-{3:3}:
__mutex_lock+0xc8/0x388
mutex_lock_nested+0x2c/0x38
dev_pm_qos_remove_notifier+0x3c/0xc8
genpd_remove_device+0x40/0x11c
genpd_dev_pm_detach+0x88/0x130
dev_pm_domain_detach+0x2c/0x3c
a6xx_gmu_remove+0x44/0xdc [msm]
a6xx_destroy+0x7c/0xa4 [msm]
adreno_unbind+0x50/0x64 [msm]
component_unbind+0x44/0x64
component_unbind_all+0xb4/0xbc
msm_drm_uninit.isra.0+0x124/0x17c [msm]
msm_drm_bind+0x340/0x5f4 [msm]
try_to_bring_up_aggregate_device+0x88/0x1a4
__component_add+0xd4/0x128
component_add+0x1c/0x28
dp_display_probe+0x37c/0x3c0 [msm]
platform_probe+0x70/0xc0
really_probe+0x148/0x280
__driver_probe_device+0xfc/0x114
driver_probe_device+0x44/0x100
__device_attach_driver+0x64/0xdc
bus_for_each_drv+0xb0/0xd8
__device_attach+0xe4/0x140
device_initial_probe+0x1c/0x28
bus_probe_device+0x44/0xb0
deferred_probe_work_func+0xb0/0xc8
process_one_work+0x288/0x3d8
worker_thread+0x1f0/0x260
kthread+0xf0/0x100
ret_from_fork+0x10/0x20

-> #2 (&a6xx_gpu->gmu.lock){+.+.}-{3:3}:
__mutex_lock+0xc8/0x388
mutex_lock_nested+0x2c/0x38
a6xx_gpu_set_freq+0x38/0x64 [msm]
msm_devfreq_target+0x170/0x18c [msm]
devfreq_set_target+0x90/0x1e4
devfreq_update_target+0xb4/0xf0
update_devfreq+0x1c/0x28
devfreq_monitor+0x3c/0x10c
process_one_work+0x288/0x3d8
worker_thread+0x1f0/0x260
kthread+0xf0/0x100
ret_from_fork+0x10/0x20

-> #1 (&df->lock){+.+.}-{3:3}:
__mutex_lock+0xc8/0x388
mutex_lock_nested+0x2c/0x38
msm_devfreq_get_dev_status+0x4c/0x104 [msm]
devfreq_simple_ondemand_func+0x5c/0x128
devfreq_update_target+0x68/0xf0
update_devfreq+0x1c/0x28
devfreq_monitor+0x3c/0x10c
process_one_work+0x288/0x3d8
worker_thread+0x1f0/0x260
kthread+0xf0/0x100
ret_from_fork+0x10/0x20

-> #0 (&devfreq->lock){+.+.}-{3:3}:
__lock_acquire+0xdf8/0x109c
lock_acquire+0x234/0x284
__mutex_lock+0xc8/0x388
mutex_lock_nested+0x2c/0x38
qos_notifier_call+0x30/0x74
qos_min_notifier_call+0x1c/0x28
notifier_call_chain+0xf4/0x114
blocking_notifier_call_chain+0x4c/0x78
pm_qos_update_target+0x184/0x190
freq_qos_apply+0x4c/0x64
apply_constraint+0xf8/0xfc
__dev_pm_qos_update_request+0x138/0x164
dev_pm_qos_update_request+0x44/0x68
msm_devfreq_boost+0x40/0x70 [msm]
msm_devfreq_active+0xc0/0xf0 [msm]
msm_gpu_submit+0xc8/0x12c [msm]
msm_job_run+0x88/0x128 [msm]
drm_sched_main+0x240/0x324 [gpu_sched]
kthread+0xf0/0x100
ret_from_fork+0x10/0x20

other info that might help us debug this:
Chain exists of:
&devfreq->lock --> dev_pm_qos_mtx --> &(c->notifiers)->rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(&(c->notifiers)->rwsem);
lock(dev_pm_qos_mtx);
lock(&(c->notifiers)->rwsem);
lock(&devfreq->lock);

*** DEADLOCK ***
4 locks held by ring0/391:
#0: ffffff809c811170 (&gpu->lock){+.+.}-{3:3}, at: msm_job_run+0x7c/0x128 [msm]
#1: ffffff809c811208 (&gpu->active_lock){+.+.}-{3:3}, at: msm_gpu_submit+0xa8/0x12c [msm]
#2: ffffffecbbb46600 (dev_pm_qos_mtx){+.+.}-{3:3}, at: dev_pm_qos_update_request+0x38/0x68
#3: ffffff809b8c1ce8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0x78

stack backtrace:
CPU: 6 PID: 391 Comm: ring0 Not tainted 6.4.3debug+ #3
Hardware name: Google Villager (rev1+) with LTE (DT)
Call trace:
dump_backtrace+0xb4/0xf0
show_stack+0x20/0x30
dump_stack_lvl+0x60/0x84
dump_stack+0x18/0x24
print_circular_bug+0x1cc/0x234
check_noncircular+0x78/0xac
__lock_acquire+0xdf8/0x109c
lock_acquire+0x234/0x284
__mutex_lock+0xc8/0x388
mutex_lock_nested+0x2c/0x38
qos_notifier_call+0x30/0x74
qos_min_notifier_call+0x1c/0x28
notifier_call_chain+0xf4/0x114
blocking_notifier_call_chain+0x4c/0x78
pm_qos_update_target+0x184/0x190
freq_qos_apply+0x4c/0x64
apply_constraint+0xf8/0xfc
__dev_pm_qos_update_request+0x138/0x164
dev_pm_qos_update_request+0x44/0x68
msm_devfreq_boost+0x40/0x70 [msm]
msm_devfreq_active+0xc0/0xf0 [msm]
msm_gpu_submit+0xc8/0x12c [msm]
msm_job_run+0x88/0x128 [msm]
drm_sched_main+0x240/0x324 [gpu_sched]
kthread+0xf0/0x100
ret_from_fork+0x10/0x20

Fix this by only synchronizing access to gmu->initialized.

Fixes: 4cd15a3e8b36 ("drm/msm/a6xx: Make GPU destroy a bit safer")
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/551171/


# 1bfa7951 20-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Fix up GMU region reservations

Change the order of region allocations to make the addresses match
downstream. This shouldn't matter very much, but helps eliminate one
more difference when comparing register accesses.

Also, make the log region 16K long. That's what it is, unconditionally
on A6xx and A7xx.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/543338/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 6ab410e0 20-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Improve GMU force shutdown sequence

The GMU force shutdown sequence involves some additional register cleanup
which was not implemented previously. Do so.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/543340/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 5e46ad83d 20-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Ensure clean GMU state in a6xx_gmu_fw_start

While it's not very well understood, there is some sort of a fault
handler implemented in the GMU firmware which triggers when a certain
bit is set, resulting in the M3 core not booting up the way we expect
it to.

Write a magic value to a magic register to hopefully prevent that
from happening.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/543335/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 90b593ce 27-Jul-2023 Rob Clark <robdclark@chromium.org>

drm/msm/adreno: Switch to chip-id for identifying GPU

Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
This means that we need to explicitly list different patch revisions in
the device table.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549782/


# 75a5227c 27-Jul-2023 Rob Clark <robdclark@chromium.org>

drm/msm/adreno: Bring the a630 family together

All of these are derivatives of a630.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/549770/


# 722d4f06 14-Jul-2023 Rob Herring <robh@kernel.org>

drm: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Acked-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714174545.4056287-1-robh@kernel.org


# 5a903a44 15-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Introduce GMU wrapper support

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>


# 30f55f3f 15-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Move CX GMU power counter enablement to hw_init

Since the introduction of A6xx support, we've been enabling the CX GMU
power counter 0 in a bit of a weird spot. Move it to hw_init so that
GMU wrapper GPUs can reuse the same code paths. As a bonus, this order
makes it easier to compare mainline and downstream register access traces.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/542765/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 277b9678 15-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Add a helper for software-resetting the GPU

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>


# 6e332c99 15-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Move a6xx_bus_clear_pending_transactions to a6xx_gpu

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>


# ce8f1381 15-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Move force keepalive vote removal to a6xx_gmu_force_off()

As pointed out by Akhil during the review process of GMU wrapper
introduction [1], it makes sense to move this write into the function
that's responsible for forcibly shutting the GMU off.

It is also very convenient to move this to GMU-specific code, so that
it does not have to be guarded by an if-condition to avoid calling it
on GMU wrapper targets.

Move the write to the aforementioned a6xx_gmu_force_off() to achieve
that. No effective functional change.

[1] https://lore.kernel.org/linux-arm-msm/20230501194022.GA18382@akhilpo-linux.qualcomm.com/

Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/542752/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# bd31afe0 15-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

drm/msm/a6xx: Remove static keyword from sptprac en/disable functions

These two will be reused by at least A619_holi in the non-gmu
paths. Turn them non-static them to make it possible.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/542751/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 12abd735 10-Apr-2023 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

drm/msm/a6xx: initialize GMU mutex earlier

Move GMU mutex initialization earlier to make sure that it is always
initialized. a6xx_destroy can be called from ther failure path before
GMU initialization.

This fixes the following backtrace:

------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 0 PID: 58 at kernel/locking/mutex.c:582 __mutex_lock+0x1ec/0x3d0
Modules linked in:
CPU: 0 PID: 58 Comm: kworker/u16:1 Not tainted 6.3.0-rc5-00155-g187c06436519 #565
Hardware name: Qualcomm Technologies, Inc. SM8350 HDK (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __mutex_lock+0x1ec/0x3d0
lr : __mutex_lock+0x1ec/0x3d0
sp : ffff800008993620
x29: ffff800008993620 x28: 0000000000000002 x27: ffff47b253c52800
x26: 0000000001000606 x25: ffff47b240bb2810 x24: fffffffffffffff4
x23: 0000000000000000 x22: ffffc38bba15ac14 x21: 0000000000000002
x20: ffff800008993690 x19: ffff47b2430cc668 x18: fffffffffffe98f0
x17: 6f74616c75676572 x16: 20796d6d75642067 x15: 0000000000000038
x14: 0000000000000000 x13: ffffc38bbba050b8 x12: 0000000000000666
x11: 0000000000000222 x10: ffffc38bbba603e8 x9 : ffffc38bbba050b8
x8 : 00000000ffffefff x7 : ffffc38bbba5d0b8 x6 : 0000000000000222
x5 : 000000000000bff4 x4 : 40000000fffff222 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff47b240cb1880
Call trace:
__mutex_lock+0x1ec/0x3d0
mutex_lock_nested+0x2c/0x38
a6xx_destroy+0xa0/0x138
a6xx_gpu_init+0x41c/0x618
adreno_bind+0x188/0x290
component_bind_all+0x118/0x248
msm_drm_bind+0x1c0/0x670
try_to_bring_up_aggregate_device+0x164/0x1d0
__component_add+0xa8/0x16c
component_add+0x14/0x20
dsi_dev_attach+0x20/0x2c
dsi_host_attach+0x9c/0x144
devm_mipi_dsi_attach+0x34/0xac
lt9611uxc_attach_dsi.isra.0+0x84/0xfc
lt9611uxc_probe+0x5b8/0x67c
i2c_device_probe+0x1ac/0x358
really_probe+0x148/0x2ac
__driver_probe_device+0x78/0xe0
driver_probe_device+0x3c/0x160
__device_attach_driver+0xb8/0x138
bus_for_each_drv+0x84/0xe0
__device_attach+0x9c/0x188
device_initial_probe+0x14/0x20
bus_probe_device+0xac/0xb0
deferred_probe_work_func+0x8c/0xc8
process_one_work+0x2bc/0x594
worker_thread+0x228/0x438
kthread+0x108/0x10c
ret_from_fork+0x10/0x20
irq event stamp: 299345
hardirqs last enabled at (299345): [<ffffc38bb9ba61e4>] put_cpu_partial+0x1c8/0x22c
hardirqs last disabled at (299344): [<ffffc38bb9ba61dc>] put_cpu_partial+0x1c0/0x22c
softirqs last enabled at (296752): [<ffffc38bb9890434>] _stext+0x434/0x4e8
softirqs last disabled at (296741): [<ffffc38bb989669c>] ____do_softirq+0x10/0x1c
---[ end trace 0000000000000000 ]---

Fixes: 4cd15a3e8b36 ("drm/msm/a6xx: Make GPU destroy a bit safer")
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/531540/
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 8559da8f 20-Mar-2023 Rob Clark <robdclark@chromium.org>

drm/msm/a6xx: Move ioremap out of hw_init path

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


# c11fa120 02-Jan-2023 Akhil P Oommen <quic_akhilpo@quicinc.com>

drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse

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@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>


# ead5d3e5 02-Jan-2023 Akhil P Oommen <quic_akhilpo@quicinc.com>

drm/msm/a6xx: Vote for cx gdsc from gpu driver

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@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 4cd15a3e 02-Feb-2023 Douglas Anderson <dianders@chromium.org>

drm/msm/a6xx: Make GPU destroy a bit safer

If, for whatever reason, we're trying process adreno_runtime_resume()
at the same time that a6xx_destroy() is running then things can go
boom. Specifically adreno_runtime_resume() will eventually call
a6xx_pm_resume() and that may try to resume the gmu.

Let's grab the GMU lock as we're destroying the GMU. That will solve
the race because a6xx_pm_resume() grabs the same lock. That makes the
access of `gmu->initialized` in a6xx_gmu_resume() safe.

We'll also return an error code in a6xx_gmu_resume() if we see that
`gmu->initialized` was false. If this happens we'll bail out of the
rest of a6xx_pm_resume(), which is good because the rest of that
function is also not good to do if we're racing with a6xx_destroy().

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/521232/
Link: https://lore.kernel.org/r/20230202104822.1.I0e49003bf4dd1dead9be4a29dbee41f3b1236e48@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>


# f4a75b59 16-Dec-2022 Akhil P Oommen <quic_akhilpo@quicinc.com>

drm/msm/a6xx: Avoid gx gbit halt during rpm suspend

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>


# 3236130b 02-Nov-2022 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

drm/msm: move domain allocation into msm_iommu_new()

After the msm_iommu instance is created, the IOMMU domain is completely
handled inside the msm_iommu code. Move the iommu_domain_alloc() call
into the msm_iommu_new() to simplify callers code.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/509615/
Link: https://lore.kernel.org/r/20221102175449.452283-2-dmitry.baryshkov@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>


# d6463fd4 18-Aug-2022 Akhil P Oommen <quic_akhilpo@quicinc.com>

drm/msm/a6xx: Handle GMU prepare-slumber hfi failure

When prepare-slumber hfi fails, we should follow a6xx_gmu_force_off()
sequence.

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/498401/
Link: https://lore.kernel.org/r/20220819015030.v5.7.I54815c7c36b80d4725cd054e536365250454452f@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 3a9dd708 18-Aug-2022 Akhil P Oommen <quic_akhilpo@quicinc.com>

drm/msm/a6xx: Improve gpu recovery sequence

We can do a few more things to improve our chance at a successful gpu
recovery, especially during a hangcheck timeout:
1. Halt CP and GMU core
2. Do RBBM GBIF HALT sequence
3. Do a soft reset of GPU core

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/498400/
Link: https://lore.kernel.org/r/20220819015030.v5.6.Idf2ba51078e87ae7ceb75cc77a5bd4ff2bd31eab@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>


# d7499634 06-Jul-2022 Geert Uytterhoeven <geert@linux-m68k.org>

drm/msm/adreno: Do not propagate void return values

With sparse ("make C=2"), lots of

error: return expression in void function

messages are seen.

Fix this by removing the return statements to propagate void return
values.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Patchwork: https://patchwork.freedesktop.org/patch/492529/
Link: https://lore.kernel.org/r/0083bc7e23753c19902580b902582ae499b44dbf.1657113388.git.geert@linux-m68k.org
Signed-off-by: Rob Clark <robdclark@chromium.org>


# b7616b5c 28-May-2022 Konrad Dybcio <konrad.dybcio@somainline.org>

drm/msm/adreno: Add A619 support

Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350),
480 (SM4350) and 750G (SM7225).

Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487588/
Link: https://lore.kernel.org/r/20220528160353.157870-2-konrad.dybcio@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 0165e9c1 28-May-2022 Konrad Dybcio <konrad.dybcio@somainline.org>

drm/msm/adreno: Remove dead code

This BUG_ON will never be reached, and there is a comment 20 above
explaining why.

Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487586/
Link: https://lore.kernel.org/r/20220528160353.157870-1-konrad.dybcio@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 6694482a 10-Jun-2022 Douglas Anderson <dianders@chromium.org>

drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy

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>


# 2ee4b5d2 11-Apr-2022 Rob Clark <robdclark@chromium.org>

drm/msm/gem: Drop PAGE_SHIFT for address space mm

Get rid of all the unnecessary conversion between address/size and page
offsets. It just confuses things.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220411215849.297838-6-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>


# a630ac68 24-Nov-2021 Rob Clark <robdclark@chromium.org>

drm/msm/gpu: Name GMU bos

Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20211124214151.1427022-5-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>


# f4f6dfde 24-Nov-2021 Rob Clark <robdclark@chromium.org>

drm/msm/gpu: Add a comment in a6xx_gmu_init()

If you don't realize is_a650_family() also encompasses a660 family,
you'd think that the debug buffer is double allocated. Add a comment
to make this more clear.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20211124214151.1427022-11-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 3d91e50f 04-Oct-2021 Dan Carpenter <dan.carpenter@oracle.com>

drm/msm: Fix potential Oops in a6xx_gmu_rpmh_init()

There are two problems here:
1) The "seqptr" is used uninitalized when we free it at the end.
2) The a6xx_gmu_get_mmio() function returns error pointers. It never
returns true.

Fixes: 64245fc55172 ("drm/msm/a6xx: use AOP-initialized PDC for a650")
Fixes: f8fc924e088e ("drm/msm/a6xx: Fix PDC register overlap")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211004134530.GB11689@kili
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 39b14bb5 05-Nov-2020 Wang Qing <wangqing@vivo.com>

drm: Use IS_ERR() instead of IS_ERR_OR_NULL()

dev_pm_opp_find_freq_exact never return null but ERR_PTR(),so we
should use IS_ERR() to clarify and avoid compilation warnings.

Signed-off-by: Wang Qing <wangqing@vivo.com>
Link: https://lore.kernel.org/r/1604630714-6163-1-git-send-email-wangqing@vivo.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# f6f59072 27-Sep-2021 Rob Clark <robdclark@chromium.org>

drm/msm/a6xx: Serialize GMU communication

I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.

Signed-off-by: Rob Clark <robdclark@chromium.org>


# 083cc3a4 07-Aug-2021 Rob Clark <robdclark@chromium.org>

drm/msm: Add adreno_is_a640_family()

Combine adreno_is_a640() and adreno_is_a680().

Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210807163019.379003-1-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 840d10b6 24-Jul-2021 Bjorn Andersson <bjorn.andersson@linaro.org>

drm: msm: Add 680 gpu to the adreno gpu list

This patch adds a Adreno 680 entry to the gpulist.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210725032002.3961691-1-bjorn.andersson@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 192f4ee3 29-Jul-2021 Akhil P Oommen <akhilpo@codeaurora.org>

drm/msm/a6xx: Add support for Adreno 7c Gen 3 gpu

This patch adds support for the gpu found in the Snapdragon 7c Gen 3
compute platform. This gpu is similar to the exisiting a660 gpu with
minor delta in the programing sequence. As the Adreno GPUs are moving
away from a numeric chipid based naming scheme to a string, it was
decided to use 0x06030500 as the chip id of this gpu to communicate
to the userspace driver.

Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org>
Link: https://lore.kernel.org/r/20210730011945.v4.3.I610377db0934b6b7deda532ec2bf786a02c38c01@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 030af2b0 27-Jul-2021 Rob Clark <robdclark@chromium.org>

drm/msm: drop drm_gem_object_put_locked()

No idea why we were still using this. It certainly hasn't been needed
for some time. So drop the pointless twin codepaths.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20210728010632.2633470-4-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>


# f6d62d09 08-Jun-2021 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: add support for Adreno 660 GPU

Add adreno_is_{a660,a650_family} helpers and convert update existing
adreno_is_a650 usage based on downstream driver's logic (changing into
adreno_is_a650_family or adding adreno_is_a660).

And add the remaining changes required for A660, again based on
the downstream driver: missing GMU allocations, additional register init,
dummy hfi BW table, cp protect list, entry in gpulist table, hwcg table,
updated a6xx_ucode_check_version check.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Link: https://lore.kernel.org/r/20210608172808.11803-6-jonathan@marek.ca
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 58e933e3 08-Jun-2021 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: add GMU_CX_GMU_CX_FALNEXT_INTF write for a650

downstream msm-5.14 kernel added a write to this register, so match that.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Link: https://lore.kernel.org/r/20210608172808.11803-4-jonathan@marek.ca
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 64245fc5 08-Jun-2021 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: use AOP-initialized PDC for a650

SM8250 AOP firmware already sets up PDC registers for us, and it only needs
to be enabled. This path will be used for other newer GPUs.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Link: https://lore.kernel.org/r/20210608172808.11803-3-jonathan@marek.ca
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 11120e93 14-Mar-2021 Yangtao Li <tiny.windzz@gmail.com>

drm/msm: Convert to use resource-managed OPP API

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>


# 2fc8a92e 05-Apr-2021 Akhil P Oommen <akhilpo@codeaurora.org>

drm/msm/a6xx: Fix perfcounter oob timeout

We were not programing the correct bit while clearing the perfcounter oob.
So, clear it correctly using the new 'clear' bit. This fixes the below
error:

[drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set PERFCOUNTER: 0x80000000

Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org>
Link: https://lore.kernel.org/r/1617630433-36506-1-git-send-email-akhilpo@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 65aee407 08-Feb-2021 Jonathan Marek <jonathan@marek.ca>

drm/msm: fix a6xx_gmu_clear_oob

The cleanup patch broke a6xx_gmu_clear_oob, fix it by adding the missing
bitshift operation.

Fixes: 555c50a4a19b ("drm/msm: Clean up GMU OOB set/clear handling")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 555c50a4 28-Jan-2021 Eric Anholt <eric@anholt.net>

drm/msm: Clean up GMU OOB set/clear handling.

Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 7a7cbf2a 28-Jan-2021 Eric Anholt <eric@anholt.net>

drm/msm: Fix race of GPU init vs timestamp power management.

We were using the same force-poweron bit in the two codepaths, so they
could race to have one of them lose GPU power early.

freedreno CI was seeing intermittent errors like:
[drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0
and this issue could have contributed to it.

Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 920b4a67 21-Jan-2021 Viresh Kumar <viresh.kumar@linaro.org>

drm: msm: Migrate to dev_pm_opp_set_opp()

dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
be used instead. Migrate to the new API.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>


# 7e688294 19-Oct-2020 Rob Clark <robdclark@chromium.org>

drm/msm/gpu: Convert retire/recover work to kthread_worker

Signed-off-by: Rob Clark <robdclark@chromium.org>


# 74c0a69c 01-Sep-2020 Rob Clark <robdclark@chromium.org>

drm/msm/gpu: Add GPU freq_change traces

Technically the GMU specific one is a bit redundant, but it was useful
to track down a bug.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>


# df561f66 23-Aug-2020 Gustavo A. R. Silva <gustavoars@kernel.org>

treewide: Use fallthrough pseudo-keyword

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>


# 5e0c22d4 13-Aug-2020 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: fix frequency not always being restored on GMU resume

The patch reorganizing the set_freq function made it so the gmu resume
doesn't always set the frequency, because a6xx_gmu_set_freq() exits early
when the frequency hasn't been changed. Note this always happens when
resuming GMU after recovering from a hang.

Use a simple workaround to prevent this from happening.

Fixes: 1f60d11423db ("drm: msm: a6xx: send opp instead of a frequency")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# f5749d61 19-Aug-2020 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

drm/msm/a6xx: fix gmu start on newer firmware

New Qualcomm firmware has changed a way it reports back the 'started'
event. Support new register values.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 20925fe8 13-Jul-2020 Sharat Masetty <smasetty@codeaurora.org>

drm: msm: a6xx: use dev_pm_opp_set_bw to scale DDR

This patches replaces the previously used static DDR vote and uses
dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
GPU frequency. Also since the icc path voting is handled completely
in the opp driver, remove the icc_path handle and its usage in the
drm driver.

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>


# 57c0bd51 17-Jul-2020 Akhil P Oommen <akhilpo@codeaurora.org>

drm: msm: a6xx: fix gpu failure after system resume

On targets where GMU is available, GMU takes over the ownership of GX GDSC
during its initialization. So, move the refcount-get on GX PD before we
initialize the GMU. This ensures that nobody can collapse the GX GDSC
once GMU owns the GX GDSC. This patch fixes some GMU OOB errors seen
during GPU wake up during a system resume.

Reported-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 1f60d114 13-Jul-2020 Sharat Masetty <smasetty@codeaurora.org>

drm: msm: a6xx: send opp instead of a frequency

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>


# 30480e6e 22-Jun-2020 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm: Fix up the rest of the messed up address sizes

msm_gem_address_space_create() changed to take a start/length instead
of a start/end for the iova space but all of the callers were just
cut and pasted from the old usage. Most of the mistakes have been fixed
up so just catch up the rest.

Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# d9e19d79 22-May-2020 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: skip HFI set freq if GMU is powered down

Also skip the newly added HFI set freq path if the GMU is powered down,
which was missing because of patches crossing paths.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# ccac7ce3 22-May-2020 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm: Refactor address space initialization

Refactor how address space initialization works. Instead of having the
address space function create the MMU object (and thus require separate but
equal functions for gpummu and iommu) use a single function and pass the
MMU struct in. Make the generic code cleaner by using target specific
functions to create the address space so a2xx can do its own thing in its
own space. For all the other targets use a generic helper to initialize
IOMMU but leave the door open for newer targets to use customization
if they need it.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
[squash in rebase fixups]
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 52da6d51 22-May-2020 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm: Attach the IOMMU device during initialization

Everywhere an IOMMU object is created by msm_gpu_create_address_space
the IOMMU device is attached immediately after. Instead of carrying around
the infrastructure to do the attach from the device specific code do it
directly in the msm_iommu_init() function. This gets it out of the way for
more aggressive cleanups that follow.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
[squash in rebase fixups and fix for unused fxn]
Signed-off-by: Rob Clark <robdclark@chromium.org>


# ad4968d5 23-Apr-2020 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: enable GMU log

This is required for a650 to work.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 02ef80c5 23-Apr-2020 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: update pdc/rscc GMU registers for A640/A650

Update the gmu_pdc registers for A640 and A650.

Some of the RSCC registers on A650 are in a separate region.

Note this also changes the address of these registers:

RSCC_TCS1_DRV0_STATUS
RSCC_TCS2_DRV0_STATUS
RSCC_TCS3_DRV0_STATUS

Based on the values in msm-4.14 and msm-4.19 kernels.

v3: replaced adreno_is_a650 around ->rscc with checks for "rscc" resource

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# c6ed04f8 23-Apr-2020 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: A640/A650 GMU firmware path

Newer GPUs have different GMU firmware path.

v3: updated a6xx_gmu_fw_load based on feedback, including gmu_write_bulk,
and removed extra whitespace change

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 8167e6fa 23-Apr-2020 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: HFI v2 for A640 and A650

Add HFI v2 code paths required by Adreno 640 and 650 GPUs.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 29ac8979 23-Apr-2020 Jonathan Marek <jonathan@marek.ca>

drm/msm/a6xx: use msm_gem for GMU memory objects

This gives more fine-grained control over how memory is allocated over the
DMA api. In particular, it allows using an address range or pinning to
a fixed address.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# eadf7928 01-May-2020 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm: Check for powered down HW in the devfreq callbacks

Writing to the devfreq sysfs nodes while the GPU is powered down can
result in a system crash (on a5xx) or a nasty GMU error (on a6xx):

$ /sys/class/devfreq/5000000.gpu# echo 500000000 > min_freq
[ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob]
*ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0

Despite the fact that we carefully try to suspend the devfreq device when
the hardware is powered down there are lots of holes in the governors that
don't check for the suspend state and blindly call into the devfreq
callbacks that end up triggering hardware reads in the GPU driver.

Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq()
callbacks to skip the hardware access if it isn't active.

v3: Only check pm_runtime_get_if_in_use() for == 0 per Eric Anholt
v2: Use pm_runtime_get_if_in_use() per Eric Anholt

Cc: stable@vger.kernel.org
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 09b4138e 03-Dec-2019 Christophe JAILLET <christophe.jaillet@wanadoo.fr>

drm/msm/a6xx: Fix a typo in an error message

'in' is duplicated in the error message. Axe one of them.
While at it, slighly improve indentation.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# a5fb8b91 19-Mar-2020 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/a6xx: Use the DMA API for GMU memory objects

The GMU has very few memory allocations and uses a flat memory space so
there is no good reason to go out of our way to bypass the DMA APIs which
were basically designed for this exact scenario.

v7: Check return value of dma_set_mask_and_coherent
v4: Use dma_alloc_wc()
v3: Set the dma mask correctly and use dma_addr_t for the iova type
v2: Pass force_dma false to of_dma_configure to require that the DMA
region be set up and return error from of_dma_configure to fail probe.

Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 9cc68ee1 05-Feb-2020 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm: Fix a6xx GMU shutdown sequence

Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") missed
updating the VBIF flush in a6xx_gmu_shutdown and instead
inserted the new sequence into a6xx_pm_suspend along with a redundant
GMU idle.

Move a6xx_bus_clear_pending_transactions to a6xx_gmu.c and use it in
the appropriate place in the shutdown routine and remove the redundant
idle call.

v2: Remove newly unused variable that was triggering a warning

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Fixes: e812744c5f95 ("drm: msm: a6xx: Add support for A618")
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# e812744c 03-Dec-2019 Sharat Masetty <smasetty@codeaurora.org>

drm: msm: a6xx: Add support for A618

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>


# bd3fe811 18-Nov-2019 Rob Clark <robdclark@chromium.org>

drm/msm/a6xx: restore previous freq on resume

Previously, if the freq were overriden (ie. via sysfs), it would get
reset to max on resume.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>


# 8e3e791d 25-Jul-2019 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm: Use generic bulk clock function

Remove the homebrewed bulk clock get function and replace it with
devm_clk_bulk_get_all().

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 03b7af1e 07-May-2019 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/adreno: Call pm_runtime_force_suspend() during unbind

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 <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# 981f2aab 23-May-2019 Sean Paul <seanpaul@chromium.org>

drm/msm/a6xx: Rename a6xx_gmu_probe to a6xx_gmu_init

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


# 998efc74 23-May-2019 Sean Paul <seanpaul@chromium.org>

drm/msm/a6xx: Drop the device reference in gmu

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: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190523171653.138678-5-sean@poorly.run


# a62fb211 23-May-2019 Sean Paul <seanpaul@chromium.org>

drm/msm/a6xx: Remove devm calls from gmu driver

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: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190523171653.138678-4-sean@poorly.run


# 5ca4a094 23-May-2019 Sean Paul <seanpaul@chromium.org>

drm/msm/a6xx: Check for ERR or NULL before iounmap

pdcptr and seqptr aren't necessarily valid, check them before trying to
unmap them.

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-3-sean@poorly.run


# cfcb3658 23-May-2019 Sean Paul <seanpaul@chromium.org>

drm/msm/a6xx: Remove duplicate irq disable from remove

a6xx_gmu_stop() already calls this function via shutdown or force_stop,
so it's not necessary to call it twice. Previously this would have
knocked the irq refcount out of sync, but now with the irqs_enabled flag
it's just housekeeping.

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-2-sean@poorly.run


# 606ec90f 23-May-2019 Sean Paul <seanpaul@chromium.org>

drm/msm/a6xx: Avoid freeing gmu resources multiple times

The driver checks for gmu->mmio as a sign that the device has been
initialized, however there are failures in probe below the mmio init.
If one of those is hit, mmio will be non-null but freed.

In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
will in turn call a6xx_gmu_remove which checks gmu->mmio and tries to free
resources for a second time. This causes a great boom.

Fix this by adding an initialized member to gmu which is set on
successful probe and cleared on removal.

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-1-sean@poorly.run


# 2b117451 15-May-2019 Sean Paul <seanpaul@chromium.org>

drm/msm: Upgrade gxpd checks to IS_ERR_OR_NULL

dev_pm_domain_attach_by_name() can return NULL, so we should check for
that case when we're about to dereference gxpd.

Fixes: 9325d4266afd ("drm/msm/gpu: Attach to the GPU GX power domain")
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeauorora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190515170104.155525-1-sean@poorly.run


# 41570b74 04-Feb-2019 Jordan Crouse <jcrouse@codeaurora.org>

msm/drm/a6xx: Turn off the GMU if resume fails

Currently if the GMU resume function fails all we try to do is clear the
BOOT_SLUMBER oob which usually times out and ends up in a cycle of death.
If the resume function fails at any point remove any RPMh votes that might
have been added and try to shut down the GMU hardware cleanly.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# e31fdb74 04-Feb-2019 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/a6xx: Make GMU reset useful

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>


# 9325d426 04-Feb-2019 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/gpu: Attach to the GPU GX power domain

99.999% of the time during normal operation the GMU is responsible
for power and clock control on the GX domain and the CPU remains
blissfully unaware. However, there is one situation where the CPU
needs to get involved:

The power sequencing rules dictate that the GX needs to be turned
off before the CX so that the CX can be turned on before the GX
during power up. During normal operation when the CPU is taking
down the CX domain a stop command is sent to the GMU which turns
off the GX domain and then the CPU handles the CX domain.

But if the GMU happened to be unresponsive while the GX domain was
left then the CPU will need to step in and turn off the GX domain
before resetting the CX and rebooting the GMU. This unfortunately
means that the CPU needs to be marginally aware of the GX domain
even though it is expected to usually keep its hands off.

To support this we create a semi-disabled GX power domain that
does nothing to the hardware on power up but tries to shut it
down normally on power down. In this method the reference counting
is correct and we can step in with the pm_runtime_put() at the right
time during the failure path.

This patch sets up the connection to the GX power domain and does
the magic to "enable" and disable it at the right points.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# b94a6e37 04-Feb-2019 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/a6xx: Remove unwanted regulator code

The GMU code currently has some misguided code to try to work around
a hardware quirk that requires the power domains on the GPU be
collapsed in a certain order. Upcoming patches will do this the
right way so get rid of the unused and unwanted regulator
code.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# e1505f62 16-Jan-2019 Douglas Anderson <dianders@chromium.org>

drm/msm: Cleanup A6XX opp-level reading

The patch ("OPP: Add support for parsing the 'opp-level' property")
adds an API enabling a cleaner way to read the opp-level. Let's use
the new API.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>


# fcf9d0b7 12-Feb-2019 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/a6xx: Add support for an interconnect path

Try to get the interconnect path for the GPU and vote for the maximum
bandwidth to support all frequencies. This is needed for performance.
Later we will want to scale the bandwidth based on the frequency to
also optimize for power but that will require some device tree
infrastructure that does not yet exist.

v6: use icc_set_bw() instead of icc_set()
v5: Remove hardcoded interconnect name and just use the default
v4: Don't use a port string at all to skip the need for names in the DT
v3: Use macros and change port string per Georgi Djakov

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# ac11c637 16-Jan-2019 Douglas Anderson <dianders@chromium.org>

drm/msm: Fix A6XX support for opp-level

The bindings for Qualcomm opp levels changed after being Acked but
before landing. Thus the code in the GPU driver that was relying on
the old bindings is now broken.

Let's change the code to match the new bindings by adjusting the old
string 'qcom,level' to the new string 'opp-level'. See the patch
("dt-bindings: opp: Introduce opp-level bindings").

NOTE: we will do additional cleanup to totally remove the string from
the code and use the new dev_pm_opp_get_level() but we'll do it in a
future patch. This will facilitate getting the important code fix in
sooner without having to deal with cross-maintainer dependencies.

This patch needs to land before the patch ("arm64: dts: sdm845: Add
gpu and gmu device nodes") since if a tree contains the device tree
patch but not this one you'll get a crash at bootup.

Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# a3c5e2cd 16-Jan-2019 Douglas Anderson <dianders@chromium.org>

drm/msm: Fix A6XX support for opp-level

The bindings for Qualcomm opp levels changed after being Acked but
before landing. Thus the code in the GPU driver that was relying on
the old bindings is now broken.

Let's change the code to match the new bindings by adjusting the old
string 'qcom,level' to the new string 'opp-level'. See the patch
("dt-bindings: opp: Introduce opp-level bindings").

NOTE: we will do additional cleanup to totally remove the string from
the code and use the new dev_pm_opp_get_level() but we'll do it in a
future patch. This will facilitate getting the important code fix in
sooner without having to deal with cross-maintainer dependencies.

This patch needs to land before the patch ("arm64: dts: sdm845: Add
gpu and gmu device nodes") since if a tree contains the device tree
patch but not this one you'll get a crash at bootup.

Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# 1707add8 02-Nov-2018 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/a6xx: Add a6xx gpu state

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>


# 56869210 02-Nov-2018 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/gpu: Add per-submission statistics

Add infrastructure to track statistics for GPU submissions
by sampling certain perfcounters before and after a submission.

To store the statistics, the per-ring memptrs region is
expanded to include room for up to 64 entries - this should
cover a reasonable amount of inflight submissions without
worrying about losing data. The target specific code inserts
PM4 commands to sample the counters before and after
submission and store them in the data region. The CPU can
access the data after the submission retires to make sense
of the statistics and communicate them to the user.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# 6a41da17 20-Oct-2018 Mamta Shukla <mamtashukla555@gmail.com>

drm: msm: Use DRM_DEV_* instead of dev_*

Use DRM_DEV_INFO/ERROR/WARN instead of dev_info/err/debug to generate
drm-formatted specific log messages so that it will be easy to
differentiate in case of multiple instances of driver.

Signed-off-by: Mamta Shukla <mamtashukla555@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# b601f731 29-Nov-2018 Stephen Boyd <swboyd@chromium.org>

drm: msm: Check cmd_db_read_aux_data() for failure

We need to check the call to cmd_db_read_aux_data() for the error case,
so that we don't continue and use potentially uninitialized values for
'pri_count' and 'sec_count'. Otherwise, we get the following compiler
warnings:

drivers/gpu/drm/msm/adreno/a6xx_gmu.c: In function 'a6xx_gmu_rpmh_arc_votes_init.isra.12':
drivers/gpu/drm/msm/adreno/a6xx_gmu.c:943:12: warning: 'pri_count' is used uninitialized in this function [-Wuninitialized]
pri_count >>= 1;
^~~
drivers/gpu/drm/msm/adreno/a6xx_gmu.c:948:12: warning: 'sec_count' may be used uninitialized in this function
[-Wmaybe-uninitialized]
sec_count >>= 1;
^~~

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Evan Green <evgreen@chromium.org>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>
Fixes: ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Andy Gross <andy.gross@linaro.org>


# ed3cafa7 26-Sep-2018 Stephen Boyd <swboyd@chromium.org>

soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()

Let's change the function signature to return the pointer to memory or
an error pointer on failure, and take an argument that lets us return
the size of the aux data read. This way we can remove the
cmd_db_read_aux_data_len() API entirely and also get rid of the memcpy
operation from cmd_db to the caller. Updating the only user of this code
shows that making this change allows us to remove a function and put the
lookup where the user is.

Cc: Mahesh Sivasubramanian <msivasub@codeaurora.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Evan Green <evgreen@chromium.org>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>


# a2c3c0a5 04-Oct-2018 Sharat Masetty <smasetty@codeaurora.org>

drm/msm/a6xx: Add devfreq support for a6xx

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>


# df0dff13 20-Sep-2018 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/a6xx: Poll for HFI responses

The only HFI communication with the GMU on sdm845 happens
during initialization and all commands are synchronous. A fancy
interrupt tasklet and associated infrastructure is entirely
not eeded and puts us at the mercy of the scheduler.

Instead poll for the message signal and handle the response
immediately and go on our way.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# 32aa27e1 14-Sep-2018 Jordan Crouse <jcrouse@codeaurora.org>

msm/gpu/a6xx: Force of_dma_configure to setup DMA for GMU

The point of the 'force_dma' parameter for of_dma_configure
is to force the device to be set up even if DMA capability is
not described by the firmware which is exactly the use case
we have for GMU - we need SMMU to get set up but we have no
other dma capabilities since memory is managed by the GPU
driver. Currently we pass false so of_dma_configure() fails
and subsequently GMU and GPU probe does as well.

Fixes: 4b565ca5a2c ("drm/msm: Add A6XX device support")
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Tested-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# f8fc924e 08-Aug-2018 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm/a6xx: Fix PDC register overlap

The current design greedily takes a big chunk of the PDC
register space instead of just the GPU specific sections
which conflicts with other drivers and generally makes
a mess of things.

Furthermore we only need to map the GPU PDC sections
just once during init so map the memory inside the function
that uses it and adjust the pointers and register offsets
accordingly.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# 9fb4bfd0 27-Sep-2018 Sharat Masetty <smasetty@codeaurora.org>

drm/msm/a6xx: Send the right perf index value to GMU

The index of the perf table was being set in the wrong bit position
in the register. With this fix, the GPU clock can be seen running at
desired frequency.

Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# 546907de 08-Aug-2018 Colin Ian King <colin.king@canonical.com>

drm/msm: a6xx: fix spelling mistake: "initalization" -> "initialization"

Trivial fix to spelling mistake in dev_err message and comment

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>


# 4b565ca5 06-Aug-2018 Jordan Crouse <jcrouse@codeaurora.org>

drm/msm: Add A6XX device support

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>