The multi-planar formats are being allocated into a single plane,
and the minigbm exynos backend is dropped. So we can use `handle` instead of handles as of now.
Remove some of the helper functions that calculate the number of planes.
There is no need to check if there is more than one kernel buffer per buffer object.
Added a new function `drv_gem_close` in `drv_helpers` that can be used by `drv_gem_bo_destroy` and `drv_prime_bo_import`. It can be used to clean the unused gem_handle.
Bug=b:266776512
TEST=camera and screenshot work fine after deploying the change #strongbad
TEST=camera and screenshot work fine after deploying the change #kukui-arc-r
TEST=camera and screenshot work fine after deploying the change, tested a couple of apps in the Google Play Store, and checked file `dma_buf/bufinfo` to see there's no object leaking. #guybrush
Change-Id: Ib63559504e4cb8f1a32ae90170925146613d694f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4297873
Commit-Queue: Dawn Han <dawnhan@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Dawn Han <dawnhan@google.com>
drv_bo_from_format will apply stride_align to all planes. Since we
always pass 1 for stride_align, there is no change except when the
format is DRM_FORMAT_YVU420_ANDROID.
When the format is DRM_FORMAT_YVU420_ANDROID, and when stride_align is 0
or 1, drv_bo_from_format assumes there is no hw requirement and forces
stride_align to 16. But because we used to require stride to be aligned
to 32, there is no actual change either.
BUG=b:265746435
TEST=subset of CTS and CTS Verifier on grunt, guybrush and skyrim
Change-Id: Ia6ef89bb744c39d2baead07bc47f11b0eea96b97
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4336265
Tested-by: Chia-I Wu <olv@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Dawn Han <dawnhan@google.com>
Remove the parameter to align with upstream gbm.
For some places that use the number of planes. The number is 1. The
multi-planar formats are being allocated into a single plane, and
minigbm exynos backend is dropped. So we can just set the plane
index to 0 if needed.
Fixed the format in i915.c.
Bug=b:266776512
TEST=camera works after deploying the change #strongbad
TEST=camera works after deploying the change #corsola
Change-Id: I0880917754c01b9d0f27d21f3c42d87f00a09f50
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4249501
Commit-Queue: Dawn Han <dawnhan@google.com>
Tested-by: Dawn Han <dawnhan@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olv@google.com>
This is required for modern Android atop a gralloc with the cross_domain
backend or other native backend.
BUG=b:238609372
TEST=build and AHB cts
Change-Id: Id963eeec62c4400cc009384e127c93588c99346e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3777566
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Jason Macnak <natsu@google.com>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
It makes more sense to resovle the format and use_flags together to
avoid duplicates.
Add the helper to vc4 and dumb_driver backends since that's missed
from prior frontend refactoring.
Split the resolve helper in virtgpu_virgl for the 3d and 2d paths to
make code logic cleaner.
BUG=b:199524294
TEST=CQ
Change-Id: I89b633ea484f0fc5bb9b4e0548cad017b9970cc6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3200143
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Reviewed-by: Chia-I Wu <olv@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
1. frontends access the driver via drv.h only
2. the renamed drv_helpers and drv_array_helpers are for driver only
3. remove extern "C" from drv_helpers.h given not exposed to gralloc
4. remove all redundant includes for those helpers
BUG=b:199524294
TEST=CQ and gralloc builds on aosp
Change-Id: I3f4d33076a6a8161804f1b7c26950ff5496507e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3195651
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olv@google.com>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
Only 2d virtgpu backend needs to fallback here because virtio primary
plane only allows DRM_FORMAT_XRGB8888.
Most our platforms cannot display YV12 (except msm), thus the fallback
is required for the converted DRM_FORMAT_YVU420_ANDROID. For virgl
backend, additionally append a BO_USE_LINEAR as a replacement for the
hack inside compute_virgl_bind_flags.
BUG=b:199524294
TEST=CQ
TEST=gralloctest alloc_combinations
TEST=android.media.cts.VideoDecoderRotationTest
Change-Id: Ic87838ea2aae2b0abf87ed898ad75a3d7e556471
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3166775
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
- Sometimes were return -1 and sometimes -errno. Prefer -errno
wherever possible.
- No braces for single line if/else statements. This does not
apply gralloc3/gralloc4, since that directory follows AOSP
style.
BUG=b:178495907
TEST=Cuttlefish CFI
Change-Id: I4c35768e015109730772a972b4b18e8d2c3cbb9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2665001
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Jason Macnak <natsu@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
The early version of the modifier assumed per plane modifiers.
The current version is only one modifier per buffer object.
BUG=none
TEST=compile
Change-Id: Ic3899118d44cb172ee2e4eae346e98cdf8328cf9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2654590
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Read MINIGBM_DEBUG env var when creating a gbm driver
Store value as a flag inside driver
Avoid allocating compressed buffers in the backends
when the flag disables compression
BUG=b:172215587
Change-Id: Idbd6f0aebc1782c1bf5921a6438310a87212d1f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2535658
Tested-by: Pilar Molina Lopez <pmolinalopez@google.com>
Commit-Queue: Pilar Molina Lopez <pmolinalopez@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
With real HW protection on the horizon, let's repurpose the
protection flag to mean that.
Currently, our protected buffer scheme on the Android side
allocates a dummy fd, which is sent to Chrome. Chrome
associates that dummy fd with an unmappable shared memory
buffer. In the entire process, minigbm doesn't really do
anything.
We prevent buffers allocated with the protected
flag from being mapped, but since it's a dummy fd it's not
really useful.
Chrome doesn't use the protected flag yet, but hopefully will
so in the future, but with real HW protection.
BUG=
TEST=
Change-Id: I57be26926539471f062ffeff33b523a3899c35f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2466958
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
We use SCANOUT_VEA_READ_CAMERA_AND_CPU_READ_WRITE for camera
capture use scenario in Chrome. Therefore, NV12 format must be
allowed for all those usage masks. This CL modifies the usages on
all platforms.
BUG=chromium:982201
TEST=video.EncodeAccel.vp8_720p_i420 on eve
Change-Id: I7880e64049f3bbf9dd1c177619e41362baf641f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2240995
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
minigbm has allowed HW_VIDEO_ENCODER usage to YVU420 so that
chrome can allocate YVU420 with HW_VIDEO_ENCODER. But this
format is no longer allocated by chrome with the usage. Let's
delete the code.
BUG=chromium:982201
TEST=None
Change-Id: Ia6bbc24e7782e3e73c2eb00c00127af212ddf486
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2245967
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Auto-Submit: Hirokazu Honda <hiroh@chromium.org>
ARCVM sets encoder/decoder usage on the blob output/input buffers, so
that virtio_gpu knows to perform transfers from/to the host where
appropriate. Recently, virtio_gpu started passing all bind flags to the
host, instead of reducing them in the guest. These factors combined
means that the host backends now need to support encoder/decoder usage
with R8 format.
Test: manually verify ARCVM YouTube
Bug: b:158957350
Change-Id: I58bf657496647f8002c693d17a1186f4cf527b01
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2245540
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This reverts commit b80c6b9737.
Thanks to crrev.com/c/1909686, camera HAL on scarlet can fill
camera content with arbitrary offsets. Remove the workaround
introduced in b80c6b9737.
BUG=b:140152839
TEST=GCA on scarlet
TEST=CCA on scarlet
Cq-Depend: chromium:1906454
Change-Id: I6782e713b8f5dd57c5cdf6d1217adc9f73b61ac3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1999866
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Auto-Submit: Hirokazu Honda <hiroh@chromium.org>
This reverts commit aa6b072d4c.
Reason for revert: This change is unnecessary because HW_VIDEO_ENCODER
usage is unmasked in crrev.com/c/1940034.
Original change's description:
> Enable to allocate XBGR8888 with HW_VIDEO_ENCODER usage
>
> crrev.com/c/1904910 masks the HW_VIDEO_ENCODER usage when
> BO_USE_HW_VIDEO_ENCODER is specified in gralloc. A camera stack allocates
> XBGR8888 buffer with BO_USE_HW_VIDEO_ENCODER usage in ARC++ video
> recording if the camera HAL version is V1. Thanks to crrev.com/c/1904910,
> it is necessary to enable to allocate XBGR8888 with HW_VIDEO_ENCODER usage.
>
> BUG=b:144135251
> TEST=Recording with GCA
>
> Change-Id: I61beee87a1531c0dea371861ffb31ce2189ef854
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1934068
> Tested-by: Hirokazu Honda <hiroh@chromium.org>
> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
> Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Bug: b:144135251
Cq-Depend: chromium:1940034
Change-Id: I8d64c97399a601487fc84a6ecae337c235bd4464
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1947685
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Auto-Submit: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
crrev.com/c/1904910 masks the HW_VIDEO_ENCODER usage when
BO_USE_HW_VIDEO_ENCODER is specified in gralloc. A camera stack allocates
XBGR8888 buffer with BO_USE_HW_VIDEO_ENCODER usage in ARC++ video
recording if the camera HAL version is V1. Thanks to crrev.com/c/1904910,
it is necessary to enable to allocate XBGR8888 with HW_VIDEO_ENCODER usage.
BUG=b:144135251
TEST=Recording with GCA
Change-Id: I61beee87a1531c0dea371861ffb31ce2189ef854
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1934068
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
crrev.com/c/1729176 corrected a wrong NV12 buffer allocation on rockchip. After
the CL, the width and height both are aligned by 16. Since GBM API doesn't
notify the aligned height to an application. The application must handle the
planes with offsets.
It turns out that Camera HAL on ChromeOS doesn't handle the allocated buffer
with offsets. In other words, it doesn't think of extra data between planes.
This causes, in a camera preview, a green line at bottom and a strange blue line
due to misposition of color planes.
This CL is a temproal workaround for the Camera HAL issue. This CL changes
minigbm implementation to not align height. This works because present video
encoder and decoder always calls GBM API with the height already aligned by
video driver. Note that a camera stack on encoding process will have to allocate
a proper buffer with non-aligned height in the future. This must be a temporal
workaround.
BUG=b:140152839
TEST=Confirm no green line in camera view and recorded video with Camera app
Change-Id: Ide53fa6801fc4bdabcfbe46004d01f5ab83a002f
Reviewed-on: https://chromium-review.googlesource.com/1775953
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Ready: Hirokazu Honda <hiroh@chromium.org>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Required to build for arm64 on mediatek, and let's fix the
rockchip one, while we're at it.
BUG=b:140228960
TEST=emerge-kevin-arc64 -av arc-cros-gralloc
TEST=emerge-kukui -av arc-cros-gralloc (with ARC++ 64-bit)
Change-Id: I8e04355a4d247b44ac86963331be72495655d321
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1775949
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Auto-Submit: Nicolas Boichat <drinkcat@chromium.org>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Chrome needs to allocate a linear buffer that a hardware video encoder can read
and cpu can read and write. There is no use flag in gbm that specifies the
former. This CL introduces a new use flag for that.
BUG=b:138703716
TEST=None
Change-Id: Ied0321914a366294a47e4fc5c2a8f08ee0351bd8
Reviewed-on: https://chromium-review.googlesource.com/1728729
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The size and offsets are computed with the given height that is not aligned.
This CL changes to compute them with an aligned height
Bug: None
Test: video_decode_accelerator_tests on kevin
Change-Id: I3e316400d2ab40beee8785f337e9451408ef7318
Reviewed-on: https://chromium-review.googlesource.com/1729176
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
This CL adds BO_USE_HW_VIDEO_DECODER to the potential list of flags
supported by RockChip, AMD and MediaTek for formats that can be used
for video playback -or- for protected buffer allocation.
Change-Id: Ib617a4138ecdf2fa00900aacd8afb412f77f78d5
BUG=chromium:857095
TEST=compiled minigbm for the said platforms.
Reviewed-on: https://chromium-review.googlesource.com/1117606
Commit-Ready: Miguel Casas <mcasas@chromium.org>
Tested-by: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
When compiling for arm64 uint64_t is considered to be unsigned long,
which caused a format error.
BUG=none
TEST=emerge
Change-Id: Ic5559ba5dce1725dd34eed60609bc1a65735c7f2
Reviewed-on: https://chromium-review.googlesource.com/1102468
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Daniel Batyai <dbatyai@inf.u-szeged.hu>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Some CTS tests apparently require HAL_PIXEL_FORMAT_RGB_888 now.
This format is DRM_FORMAT_BGR888 in <drm_fourcc.h>. Let's add it
to the revelant drivers.
BUG=b:80496655
TEST=emerge-eve minigbm, let lab test
Change-Id: Ia9dadbd2c17c137262865679af1d97d55b1a7087
Reviewed-on: https://chromium-review.googlesource.com/1089493
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Ilja H. Friedel <ihf@chromium.org>
This reverts commit 292da5365a.
Reason for revert: The Android framework uses successful allocation of HAL_PIXEL_FORMAT_RGBA_FP16 to test for wide-gamut capabilities. We don't want to advertise this, so let's revert.
android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
can pass if the framework falls back to RGBA8888, as is the plan.
Original change's description:
> minigbm: add support for HAL_PIXEL_FORMAT_RGBA_FP16
>
> This is needed to support the following CTS test:
>
> android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
>
> There have been some rumblings about adding 64-bit formats to <drm_fourcc.h>:
>
> https://lists.freedesktop.org/archives/intel-gvt-dev/2017-July/001469.html
>
> However, nothing has landed, so let's just define our own format
> for the time being.
>
> BUG=b:77973662
> TEST=Compile for kevin and kevin-arcnext
> Unfortunately, my P setup refuses to work, so let the lab
> test.
>
> Change-Id: I1fea16400ba6632a8ef17105e27bc7799d2af515
> Reviewed-on: https://chromium-review.googlesource.com/1029355
> Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
> Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Bug: b:77973662
Change-Id: I9e4b79b06dd565189a2e783e8453f08af173d84c
Reviewed-on: https://chromium-review.googlesource.com/1045805
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This is needed to support the following CTS test:
android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
There have been some rumblings about adding 64-bit formats to <drm_fourcc.h>:
https://lists.freedesktop.org/archives/intel-gvt-dev/2017-July/001469.html
However, nothing has landed, so let's just define our own format
for the time being.
BUG=b:77973662
TEST=Compile for kevin and kevin-arcnext
Unfortunately, my P setup refuses to work, so let the lab
test.
Change-Id: I1fea16400ba6632a8ef17105e27bc7799d2af515
Reviewed-on: https://chromium-review.googlesource.com/1029355
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This code might be loaded by a daemonized process now, so the existing
logging to stderr goes nowhere. It's better to use the Android logger.
Change-Id: I19f088b8f049f07c9c6839038d2971fad1a0e852
Reviewed-on: https://chromium-review.googlesource.com/971360
Commit-Ready: Alistair Strachan <astrachan@google.com>
Tested-by: Alistair Strachan <astrachan@google.com>
Reviewed-by: Alistair Strachan <astrachan@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
In the case where process A is writing to the buffer, and process
B is reading from the buffer via a shadow buffer, we should update
the shadow buffer.
This issue seems to only pop on renderscript tests on Mediatek devices,
but that's due the various differences between 3D driver implementations.
Let's modify rockchip for correctness as well.
BUG=b:69700010
TEST=run cts -m CtsViewTestCases -t android.view.cts.SurfaceViewSyncTests
passes on Oak
Change-Id: Id551027a2093f5423ee380d8935637d6256d2295
Reviewed-on: https://chromium-review.googlesource.com/795038
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Two reasons for this:
1) We can use drv_array for driver combinations (see next patch)
2) It's less verbose.
BUG=chromium:764871
TEST=gbmtest passes
Change-Id: I39bea6e2e9e4c76d2ca78566926a79bdc17f11d0
Reviewed-on: https://chromium-review.googlesource.com/758148
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
This sets better expectations for what we expect from the
backends.
BUG=chromium:764871
TEST=mmap_test
Change-Id: I7fb815b58fae8e9fbd73bf7c0263c7db44488844
Reviewed-on: https://chromium-review.googlesource.com/770519
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Joe Kniss <djmk@google.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Since some drivers (AMDGPU, Tegra) may have to do expensive tiling
and detiling operations, we should try to take advantage of the
access regions passed in by gralloc and gbm. Let's refactor struct
map_data so we can separate the actual mapping and access region.
Here is the Coccinelle rule used in this change:
@@ struct map_info *M; @@
- (M)
+ M->vma
In addition, struct map_data was also renamed to struct mapping.
BUG=chromium:764871
TEST= mmap_test -g on Kevin
Change-Id: Idb094aa3b5f81e45ce3a2f4fb2d9bf8fba32bf29
Reviewed-on: https://chromium-review.googlesource.com/758144
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Joe Kniss <djmk@google.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
DRM_FORMAT_MOD_NONE means that the buffer layout is "not modified", as
opposed to "no modifier present". In other words, linear, since the
assumption is that that's the starting point. This was later
clarified by introducing the DRM_FORMAT_MOD_LINEAR as a alias for
DRM_FORMAT_MOD_NONE and DRM_FORMAT_MOD_INVALID as a NULL-like value
for modifiers.
This commit replaces DRM_FORMAT_MOD_NONE with DRM_FORMAT_MOD_LINEAR
where we mean linear (which is most places) and DRM_FORMAT_MOD_INVALID
where we want to indicate "no modifier" (in struct kms_item).
BUG=chromium:763760
TEST=Intel GPU board boots and has X-tiled framebuffers.
Change-Id: I93e1419e1ab4c04ad6ef3d48ada19487b880886d
Reviewed-on: https://chromium-review.googlesource.com/737409
Commit-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
When the map flags do not feature BO_TRANSFER_WRITE, we should
not copy back any shadow buffers we maintain.
BUG=b:67434931
TEST=android.view.cts.SurfaceViewSyncTests on Mediatek/Rockchip
Change-Id: I7078bfc5a8d770a52949d43ea68efc4a870e9227
Reviewed-on: https://chromium-review.googlesource.com/703875
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Some eagle-eyed observers have commented that we lose some
potentially useful information for the (*bo_map) callback when
we convert our map flags to page protection flags. Let's not
lose this information, so pass in the map flags. We can convert
to page protection flags using a helper function.
BUG=chromium:764871
TEST=Boot Android and play games on Eve
Change-Id: Ie2cf395109eb5a8de663dfb97a343d20ff0df30c
Reviewed-on: https://chromium-review.googlesource.com/691425
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We use the terms "flags" and "usage" interchangeably in this repo,
since they essentally mean the same thing. However, let's be a
little more consistent since it's kind of confusing, especially
when buffer map flags come to play. Let's:
- refer to everything in the drv_* layer as use_flags
- refer to everything in the gbm/gralloc layers as
usages
BUG=chromium:764871
TEST=emerge-eve {arc-cros-gralloc, minigbm}
Change-Id: If987d72369b895f38cde87e50ce1080f78f2a084
Reviewed-on: https://chromium-review.googlesource.com/691423
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
