Technically it worked as it was before, only because it was using the
_safe version of the iterator.  But it is sloppy practice to leave
dangling pointers.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/507017/
Link: https://lore.kernel.org/r/20221013225520.371226-4-robdclark@gmail.com

Some buffers are unused on certain sub-generations of a6xx.  So just
skip them.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/507013/
Link: https://lore.kernel.org/r/20221013225520.371226-3-robdclark@gmail.com

adreno_show_object() is a trap!  It will re-allocate the pointer it is
passed on first call, when the data is ascii85 encoded, using kvmalloc/
kvfree().  Which means the data *passed* to it must be kvmalloc'd, ie.
we cannot use the state_kcalloc() helper.

This partially reverts commit ec8f1813 ("drm/msm/a6xx: Replace
kcalloc() with kvzalloc()"), but adds the missing kvfree() to fix the
memory leak that was present previously.  And adds a warning comment.

Fixes: ec8f1813 ("drm/msm/a6xx: Replace kcalloc() with kvzalloc()")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/20Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/507014/
Link: https://lore.kernel.org/r/20221013225520.371226-2-robdclark@gmail.com

In adreno_unbind, we should clean up gpu device's drvdata to avoid
accessing a stale pointer during system suspend. Also, check for NULL
ptr in both system suspend/resume callbacks.
Signed-off-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/505075/
Link: https://lore.kernel.org/r/20220928124830.2.I5ee0ac073ccdeb81961e5ec0cce5f741a7207a71@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

In order to reduce chance of allocation failure while capturing a6xx
gpu state, use kvzalloc() instead of kcalloc() in state_kcalloc().

Indirectly, this patch helps to fix leaking memory allocated for
gmu_debug object.

Fixes: b859f9b0 (drm/msm/gpu: Snapshot GMU debug buffer)
Signed-off-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/505074/
Link: https://lore.kernel.org/r/20220928124830.1.I8ea24a8d586b4978823b848adde000f92f74d5c2@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

When prepare-slumber hfi fails, we should follow a6xx_gmu_force_off()
sequence.
Signed-off-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/498401/
Link: https://lore.kernel.org/r/20220819015030.v5.7.I54815c7c36b80d4725cd054e536365250454452f@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

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: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/498400/
Link: https://lore.kernel.org/r/20220819015030.v5.6.Idf2ba51078e87ae7ceb75cc77a5bd4ff2bd31eab@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

Because there could be transient votes from other drivers/tz/hyp which
may keep the cx gdsc enabled, we should poll until cx gdsc collapses.
We can use the reset framework to poll for cx gdsc collapse from gpucc
clk driver.

This feature requires support from the platform's gpucc driver.
Signed-off-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Patchwork: https://patchwork.freedesktop.org/patch/498397/
Link: https://lore.kernel.org/r/20220819015030.v5.5.I176567525af2b9439a7e485d0ca130528666a55c@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

There are some hardware logic under CX domain. For a successful
recovery, we should ensure cx headswitch collapses to ensure all the
stale states are cleard out. This is especially true to for a6xx family
where we can GMU co-processor.

Currently, cx doesn't collapse due to a devlink between gpu and its
smmu. So the *struct gpu device* needs to be runtime suspended to ensure
that the iommu driver removes its vote on cx gdsc.
Signed-off-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/498398/
Link: https://lore.kernel.org/r/20220819015030.v5.4.I4ac27a0b34ea796ce0f938bb509e257516bc6f57@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

Replace some open coding to improve readability.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/499272/
Link: https://lore.kernel.org/r/20220821155441.1092134-1-robdclark@gmail.com

To avoid preventing the display from coming up before the rootfs is
mounted, without resorting to packing fw in the initrd, the GPU has
this limbo state where the device is probed, but we aren't ready to
start sending commands to it.  This is particularly problematic for
a6xx, since the GMU (which requires fw to be loaded) is the one that
is controlling the power/clk/icc votes.

So defer enabling runpm until we are ready to call gpu->hw_init(),
as that is a point where we know we have all the needed fw and are
ready to start sending commands to the coproc's.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489337/
Link: https://lore.kernel.org/r/20220613182036.2567963-1-robdclark@gmail.com

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: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Patchwork: https://patchwork.freedesktop.org/patch/492529/
Link: https://lore.kernel.org/r/0083bc7e23753c19902580b902582ae499b44dbf.1657113388.git.geert@linux-m68k.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

When trying to understand an iova fault devcore, once you figure out
which buffer we accessed beyond the end of, it is useful to see the
buffer's debug label.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/491910/
Link: https://lore.kernel.org/r/20220629211919.563585-3-robdclark@gmail.com

In debugging fence rollover, I noticed that GPU state capture and
devcore dumps were showing me negative fence numbers.  Let's fix that
and some related signed vs unsigned confusion.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489621/
Link: https://lore.kernel.org/r/20220615163532.3013035-1-robdclark@gmail.com

The restriction to 4G was strictly to work around 64b math bug in some
versions of SQE firmware.  This appears to be fixed in a650+ SQE fw, so
allow a larger address space size on these devices.

Also, add a modparam override for debugging and igt.

v2: Send the right version of the patch (ie. the one that actually
    compiles)
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/487601/
Link: https://lore.kernel.org/r/20220529180428.2577832-1-robdclark@gmail.com

Leading spaces are not something checkpatch likes, and it says so when
they are present. Use tabs consistently to indent function body and
unwrap a 83-char-long line, as 100 is cool nowadays.
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487592/
Link: https://lore.kernel.org/r/20220528160353.157870-4-konrad.dybcio@somainline.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

There are various SKUs of A619, ranging from 565 MHz to 850 MHz, depending
on the bin. Add support for distinguishing them, so that proper frequency
ranges can be applied, depending on the HW.
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487590/
Link: https://lore.kernel.org/r/20220528160353.157870-3-konrad.dybcio@somainline.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350),
480 (SM4350) and 750G (SM7225).
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: NAkhil 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.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

This BUG_ON will never be reached, and there is a comment 20 above
explaining why.
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: NAkhil 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.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

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: eadf7928 ("drm/msm: Check for powered down HW in the devfreq callbacks")
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/489124/
Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeidSigned-off-by: NRob Clark <robdclark@chromium.org>

Prior to the last commit, this could result in setting the GPU
written fence value back to an older value, if we had missed
updating completed_fence prior to suspend.  This was mostly
harmless as the GPU would eventually overwrite it again with
the correct value.  But we should just not do this.  Instead
just leave a sanity check that the fence looks plausible (in
case the GPU scribbled on memory).
Reported-by: NSteev Klimaszewski <steev@kali.org>
Fixes: 95d1deb0 ("drm/msm/gem: Add fenced vma unpin")
Signed-off-by: NRob Clark <robdclark@chromium.org>
Tested-by: NSteev Klimaszewski <steev@kali.org>
Patchwork: https://patchwork.freedesktop.org/patch/490138/
Link: https://lore.kernel.org/r/20220618161120.3451993-2-robdclark@gmail.com

Following commit 17e822f7 ("drm/msm: fix unbalanced
pm_runtime_enable in adreno_gpu_{init, cleanup}"), any call to
adreno_unbind() will disable runtime PM twice, as indicated by the call
trees below:

  adreno_unbind()
   -> pm_runtime_force_suspend()
   -> pm_runtime_disable()

  adreno_unbind()
   -> gpu->funcs->destroy() [= aNxx_destroy()]
   -> adreno_gpu_cleanup()
   -> pm_runtime_disable()

Note that pm_runtime_force_suspend() is called right before
gpu->funcs->destroy() and both functions are called unconditionally.

With recent addition of the eDP AUX bus code, this problem manifests
itself when the eDP panel cannot be found yet and probing is deferred.
On the first probe attempt, we disable runtime PM twice as described
above. This then causes any later probe attempt to fail with

  [drm:adreno_load_gpu [msm]] *ERROR* Couldn't power up the GPU: -13

preventing the driver from loading.

As there seem to be scenarios where the aNxx_destroy() functions are not
called from adreno_unbind(), simply removing pm_runtime_disable() from
inside adreno_unbind() does not seem to be the proper fix. This is what
commit 17e822f7 ("drm/msm: fix unbalanced pm_runtime_enable in
adreno_gpu_{init, cleanup}") intended to fix. Therefore, instead check
whether runtime PM is still enabled, and only disable it in that case.

Fixes: 17e822f7 ("drm/msm: fix unbalanced pm_runtime_enable in adreno_gpu_{init, cleanup}")
Signed-off-by: NMaximilian Luz <luzmaximilian@gmail.com>
Tested-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Link: https://lore.kernel.org/r/20220606211305.189585-1-luzmaximilian@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.

a6xx_gmu_init() passes the node to of_find_device_by_node()
and of_dma_configure(), of_find_device_by_node() will takes its
reference, of_dma_configure() doesn't need the node after usage.

Add missing of_node_put() to avoid refcount leak.

Fixes: 4b565ca5 ("drm/msm: Add A6XX device support")
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Link: https://lore.kernel.org/r/20220512121955.56937-1-linmq006@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

Check if 'aspace' is set before using it as it will stay null without
IOMMU, such as on msm8974.

Fixes: bc211258 ("drm/msm/gpu: Track global faults per address-space")
Signed-off-by: NLuca Weiss <luca@z3ntu.xyz>
Link: https://lore.kernel.org/r/20220421203455.313523-1-luca@z3ntu.xyzSigned-off-by: NRob Clark <robdclark@chromium.org>

Move tracking and busy time calculation to msm_devfreq_get_dev_status.
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Cc: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220416003314.59211-2-olvaffe@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

The motivation at this point is mainly native userspace mesa driver in a
VM guest.  The one remaining synchronous "hotpath" is buffer allocation,
because guest needs to wait to know the bo's iova before it can start
emitting cmdstream/state that references the new bo.  By allocating the
iova in the guest userspace, we no longer need to wait for a response
from the host, but can just rely on the allocation request being
processed before the cmdstream submission.  Allocation failures (OoM,
etc) would just be treated as context-lost (ie. GL_GUILTY_CONTEXT_RESET)
or subsequent allocations (or readpix, etc) can raise GL_OUT_OF_MEMORY.

v2: Fix inuse check
v3: Change mismatched iova case to -EBUSY
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NDmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/r/20220411215849.297838-11-robdclark@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

Get rid of all the unnecessary conversion between address/size and page
offsets.  It just confuses things.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220411215849.297838-6-robdclark@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

The ring seqno counter duplicates the fence-context last_fence counter.
They end up getting incremented in lock-step, on the same scheduler
thread, but the split just makes things less obvious.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220411215849.297838-3-robdclark@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

In the cause of using the GPU via virtgpu, the host side process is
really a sort of proxy, and not terribly interesting from the PoV of
crash/fault logging.  Add a way to override these per process so that
we can see the guest process's name.

v2: Handle kmalloc failure, add comment to explain kstrdup returns
    NULL if passed NULL [Dan Carpenter]
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220317165144.222101-4-robdclark@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

The 64b value field is already suffient to hold a pointer instead of
immediate, but we also need a length field.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220317165144.222101-2-robdclark@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

When building with CONFIG_PM=y and CONFIG_PM_SLEEP=n (such as ARCH=riscv
allmodconfig), the following warnings/errors occur:

  drivers/gpu/drm/msm/adreno/adreno_device.c:679:12: error: 'adreno_system_resume' defined but not used [-Werror=unused-function]
    679 | static int adreno_system_resume(struct device *dev)
        |            ^~~~~~~~~~~~~~~~~~~~
  drivers/gpu/drm/msm/adreno/adreno_device.c:655:12: error: 'adreno_system_suspend' defined but not used [-Werror=unused-function]
    655 | static int adreno_system_suspend(struct device *dev)
        |            ^~~~~~~~~~~~~~~~~~~~~
  cc1: all warnings being treated as errors

These functions are only used in SET_SYSTEM_SLEEP_PM_OPS(), which
evaluates to empty when CONFIG_PM_SLEEP is not set, making these
functions unused.

To resolve this, use the SYSTEM_SLEEP_PM_OPS() and RUNTIME_PM_OPS()
macros, which were introduced in commit 1a3c7bb0 ("PM: core: Add new
*_PM_OPS macros, deprecate old ones"). They are designed to avoid these
compiler warnings while still guarding their use on
CONFIG_PM{,_SLEEP}=y.

Fixes: 7e4167c9 ("drm/msm/gpu: Park scheduler threads for system suspend")
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20220411181249.2758344-1-nathan@kernel.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

The fourth param is size, rather than range_end.

Note that we could increase the address space size if we had a way to
prevent buffers from spanning a 4G split, mostly just to avoid fw bugs
with 64b math.

Fixes: 84c31ee1 ("drm/msm/a6xx: Add support for per-instance pagetables")
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220407202836.1211268-1-robdclark@gmail.comSigned-off-by: NRob Clark <robdclark@chromium.org>

The mutex wasn't really protecting anything before.  Before the previous
patch we could still be racing with the scheduler's kthread, as that is
not necessarily frozen yet.  Now that we've parked the sched threads,
the only race is with jobs retiring, and that is harmless, ie.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220310234611.424743-4-robdclark@gmail.com

In the system suspend path, we don't want to be racing with the
scheduler kthreads pushing additional queued up jobs to the hw
queue (ringbuffer).  So park them first.  While we are at it,
move the wait for active jobs to complete into the new system-
suspend path.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220310234611.424743-3-robdclark@gmail.com

Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220310234611.424743-2-robdclark@gmail.com

These casts need to happen before the shift.  The only time it would
matter would be if "rev.core" is >= 128.  In that case the sign bit
would be extended and we do not want that.

Fixes: afab9d91 ("drm/msm/adreno: Expose speedbin to userspace")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NAkhil P Oommen <quic_akhilpo@quicinc.com>
Link: https://lore.kernel.org/r/20220307133105.GA17534@kiliSigned-off-by: NRob Clark <robdclark@chromium.org>

Fixes: f6d62d09 ("drm/msm/a6xx: add support for Adreno 660 GPU")
Signed-off-by: NRob Clark <robdclark@chromium.org>
Reviewed-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220305173405.914989-1-robdclark@gmail.com

Any app controlled perfcntr collection (GL_AMD_performance_monitor, etc)
does not require counters to maintain state across context switches.  So
clear them if systemwide profiling is not active.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220304005317.776110-5-robdclark@gmail.com

Add a SYSPROF param for system profiling tools like Mesa's pps-producer
(perfetto) to control behavior related to system-wide performance
counter collection.  In particular, for profiling, one wants to ensure
that GPU context switches do not effect perfcounter state, and might
want to suppress suspend (which would cause counters to lose state).

v2: Swap the order in msm_file_private_set_sysprof() [sboyd] and
    initialize the sysprof_active refcount to one (because the under/
    overflow checking in refcount_t doesn't expect a 0->1 transition)
    meaning that values greater than 1 means sysprof is active.
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220304005317.776110-4-robdclark@gmail.com

It was always expected to have a use for this some day, so we left a
placeholder.  Now we do.  (And I expect another use in the not too
distant future when we start allowing userspace to allocate GPU iova.)
Signed-off-by: NRob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20220304005317.776110-3-robdclark@gmail.com