SQUASHME! [VPG]: drm/i915: Unpin GGTT vma of the batch_obj at the end of execbuffer
SQUASHME! - This patch should be squashed into the following existing patch:
Author: John Harrison <John.C.Harrison@Intel.com>
Date: Wed Apr 9 13:03:34 2014 +0100
FOR_UPSTREAM [VPG]: drm/i915: Split i915_dem_do_execbuffer() in half
Some of the pwrite calls on the batch buffer were failing, due to the associated
GGTT vma marked as pinned. To update the batch buffer, 3D UMD uses the
pwrite interface and for that KMD decides to use the pwrite-fast method.
The pwrite-fast method tries to update object pages through the GTT mapping, to
avoid the overhead of cache flushing, for that it first binds the object
in the Aperture space(256 MB region). This leads to a rebinding if the object
is mapped outside the Aperture space and that fails if the vma is marked as
pinned resulting in an unsuccessful pwrite call.
This GGTT vma pinning of batch buffer is happening from the execbuffer path.
In the secure parsing mode, the batch buffer is being pinned in GGTT apart from
being pinned to PPGTT. The PPGTT vma is unpinned at the end of execbuffer
but the GGTT vma is unpinned when the Scheduler removes the corresponding
request from its queue on the completion. This pinning of GGTT vma for extra
duration has been causing some of the pwrite calls to fail for the batch buffer.
While unbinding any vma (PPGTT/GGTT), the KMD checks whether the object
associated with the vma is active or not and not whether the vma itself
is part of the corresponding vm’s active list or not. So while unbinding the
GGTT vma also, KMD will have to wait for the object to become inactive, if
only the PPGTT vma was linked in the active list and the object was marked as active.
So the unpinning of GGTT vma for the batch bufer can also be safely performed
at the end of execbuffer, as the object is already marked as active and the
associated PPGTT vma is also moved to the corresponding vm's active list.
That's how it was being done initially in the Upstream patch from Daniel Vetter,
before the advent of Scheduler.
This issue is so far seen only on VLV.
On CHV, batch buffer is not being pinned in GGTT due to some issue with Full PPGTT mode.
On BXT, the UMD provided batch buffer is not being submitted to the Hw, rather
KMD is copying the contents to its own internal pool of batch buffers,
which are then pinned in GGTT and submitted to Hw, so the pwrite calls from
the UMD actually operates on the set of batch buffers, allocated by UMD,
hence no conflict.
Signed-off-by: Ankitprasad Sharma <email@example.com>
Signed-off-by: Akash Goel <firstname.lastname@example.org>
2 files changed