Some camera CTS tests pass down the following usage:
GRALLOC_USAGE_HW_TEXTURE | GRALLOC_USAGE_SW_WRITE_OFTEN,
which we convert. Since we generally want to create a tiled buffer when
GRALLOC_USAGE_HW_TEXTURE is specified and tiled buffers are inefficient for
frequent software access, many drivers don't support this combination.
When this occurs, let's drop the BO_USE_RENDERING flag and try the allocation again
with different flags.
BUG=chromium:616275
TEST=run cts --disable-reboot --class android.hardware.camera2.cts.MultiViewTest
passes on kevin
Change-Id: Id3364edb849fe92d4710c765ed664e8aa4a4738d
Reviewed-on: https://chromium-review.googlesource.com/424318
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This adds support for allocating AFBC (ARM FrameBuffer Compression)
buffers with minigbm for Rockchip SoCs. AFBC buffers are allocated
through the new gbm_bo_create_with_modifiers() entry point. Callers are
responsible for determining which modifiers are valid for the intended
use case and pass in that list. gbm will then pick the optimal modifier
and allocate a buffer with that layout. The chosen modifier can be
queries through gbm_bo_get_format_modifier().
Callers of the new entry point are expected to forward the modifier when
using the buffer with other APIs (EGL, KMS etc). The old gbm_bo_create()
entry point continues to work as before and won't allocate AFBC buffers.
BUG=chrome-os-partner:56407
TEST=drm-tests null_platform_test with AFBC support
Change-Id: I1aa345b0d79c4545b7bfc17e9699ef6ad57c68e2
Reviewed-on: https://chromium-review.googlesource.com/386318
Commit-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Let's try to organize the flags such that one entry in the supported
combination list implies a certain type of buffer. For example, we only
create linear buffers in our Mediatek, so the following entries are
equivalent:
{DRM_FORMAT_XRGB8888, DRM_FORMAT_MOD_NONE,
BO_USE_RENDERING | BO_USE_SW_READ_RARELY | BO_USE_SW_WRITE_RARELY},
{DRM_FORMAT_XRGB8888, DRM_FORMAT_MOD_NONE,
BO_USE_CURSOR | BO_USE_LINEAR | BO_USE_SW_READ_OFTEN |
BO_USE_SW_WRITE_OFTEN},
Since they both translate into a XRGB8888 linear buffer on Mediatek, let's merge
the two entries. Do similiar operations for every driver.
BUG=none
TEST=try-bots
Change-Id: I0be97c2deec5310f426632f85d1525a1345498e6
Reviewed-on: https://chromium-review.googlesource.com/421499
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
With CL:397941, hshi@ figured out how to detile blocklinear buffers
for tegra. Let's add that logic to our tegra map()/unmap() functions.
This can be useful for various tests.
BUG=chromium:673570
TEST=tiled_bo_test draws ellipse texture on Tegra (there are artifacts
due another bug though)
Change-Id: I7c2e7222ba67457ffd3641ba42a775ac4a667ec8
Reviewed-on: https://chromium-review.googlesource.com/421279
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Haixia Shi <hshi@chromium.org>
The pre-submit hook script checks that copyright messages don't
contain "(c)".
This CL removes "(c)" from all the copyrights header in minigbm
that still have it.
BUG=None
TEST=emerge-$BOARD minigbm.
Change-Id: I1922d9d29b78d124302d497310fe1c1cfd6fc695
Reviewed-on: https://chromium-review.googlesource.com/421588
Commit-Ready: David Reveman <reveman@chromium.org>
Commit-Ready: Daniele Castagna <dcastagna@chromium.org>
Tested-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Adding a nouveau backend to minigbm can be useful to test ozone code
on our workstations.
This CL adds a nouveau backend that uses dumb buffers.
This is enough to run ozone_gl_unittests and ozone_demo on our
workstations.
BUG=None
TEST='Ran ozone_demo on my workstation.'
Change-Id: I4e690192c9d9944b9907e64253205a94605a76eb
Reviewed-on: https://chromium-review.googlesource.com/421606
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tegra20 and Tegra30 both required the buffer line stride to be aligned
on 8 byte boundaries. Tegra114 and Tegra124 increased the alignment to
64 bytes.
The kernel automatically does this for us for dumb buffers, but since the
tegra gem create API doesn't return the stride, we'll have to do it here.
BUG=chromium:673570
TEST=tiled_bo_test succeeds
Change-Id: I2222f033813a31d3eed1a6794fbf044fba33eec0
Reviewed-on: https://chromium-review.googlesource.com/421278
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Haixia Shi <hshi@chromium.org>
It has nothing to do with the preprocessor.
BUG=none
TEST=builds
Change-Id: Ib5c851b0127d36bf52cce1e5c81cfed0eb3b541d
Reviewed-on: https://chromium-review.googlesource.com/415112
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We never set the width and height in drv_dumb_bo_create.
We really should do this.
TEST=none
BUG=none
Change-Id: I630866bcf5086fbb3679f772fe0f2857d37f22c2
Reviewed-on: https://chromium-review.googlesource.com/417164
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Only include information needed to import in the handle. We
were previously including the address space of another process in
the handle, which is a potential security risk.
BUG=chromium:616275
TEST=arc-cros-gralloc works on oak, minnie, cyan
CQ-DEPEND=CL:416399
Change-Id: I10230053e305865db0dde26a596403ec0b9e4f4c
Reviewed-on: https://chromium-review.googlesource.com/416400
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
If the vgem driver and a hardware driver are both present on
a machine, and if the vgem driver corresponds to a lower
number rendernode, we'll end up picking the vgem driver. This is
not the desired behavior, so let's fix it.
BUG=chromium:616275
TEST=mediatek driver loads
CQ-DEPEND=CL:416396
Change-Id: Ib2647f4dbaf3c45fab97bbbcbb94e09c1daa6d5d
Reviewed-on: https://chromium-review.googlesource.com/416397
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
For some reason, we use HAL_PIXEL_FORMAT_YV12 instead of
HAL_PIXEL_FORMAT_YCbCr_420_888 as our YUV format on mediatek
based boards. We also pass down a different use flags. Since
mediatek only supports linear buffers the moment, just lump all
the flags together for our YUV supported combination.
BUG=chromium:616275
TEST=Played Youtube video in Oak ARC++ container
CQ-DEPEND=CL:416292
Change-Id: Iac4797517048981235cd17ad464eb1e3852c4072
Reviewed-on: https://chromium-review.googlesource.com/416396
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
While running Android in QEMU, I encountered a few crashes
due to unsupported formats. Add them here.
BUG=chromium:616275
TEST=Run arc-cros-gralloc in QEMU
CQ-DEPEND=CL:416291
Change-Id: Ie9a9dee0cba7c8b83592c40a3249ebcb30391346
Reviewed-on: https://chromium-review.googlesource.com/416292
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We're planning on using Mesa with llvmpipe when running
the Android container in a virtual machine. It's faster
than softpipe. llvmpipe requires alignment to a 64-byte
tile size, so add it here. This is the analogue to
norvez@'s drm_gralloc commiti (ag/1599269).
BUG=b:28802929, chromium:616275
TEST=run arc-cros-gralloc in QEMU
CQ-DEPEND=CL:414537
Change-Id: If4160d376447ce218df3bc410a8427b284de74fd
Reviewed-on: https://chromium-review.googlesource.com/416291
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
The Play Store wants a ABGR8888 HW cursor, and we can't in
general support this, so let's ignore the cursor flag rather
than fail the allocation.
We also interpret GRALLOC_USAGE_HW_COMPOSER as BO_USE_SCANOUT
| BO_USE_RENDERING. This fails with YV12, since we can't scanout
from it on Intel/Mediatek. Let's first try to allocate with the
scanout flag enabled and then fall-back to rendering if it's
not supported (i.e, first try overlay but then try OpenGL).
In addition, let's interpret GRALLOC_USAGE_HW_FB the same as
GRALLOC_USAGE_HW_COMPOSER since the framebuffer device
(Chrome in our case) wants to scanout but can also fall back.
BUG=chromium:616275
TEST=run cts --package com.drawelements.deqp.egl on minnie
CQ-DEPEND=CL:414536
Change-Id: I57cd681ca8ff0186698bd0a046c3a7b346f3e434
Reviewed-on: https://chromium-review.googlesource.com/414537
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Many GL drivers assume that first value in the native_handle data
array is the fd associated with the graphics buffer, i.e,
int prime_fd = handle->data[0];
This in our case until 4bfc7401. We added 64-bit modifiers in
our import data, so all values in the drv_import_fd_data struct get
8-byte aligned. In our cros_gralloc_handle, 4 bytes of padding
are added between native_handle_t and drv_import_fd_data to make
the alignment work. To counter-act this, we can stop embedding
drv_import_fd_data in cros_gralloc_handle.
BUG=chromium:616275
TEST=Mali driver doesn't return an error when running cros_gralloc
CQ-DEPEND=CL:414585
Change-Id: Ib6c165e98126468b96fa7119d5ca13eebee1655c
Reviewed-on: https://chromium-review.googlesource.com/414536
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
With CL:405019, when drmModeGetPlaneResources failed, creation of
the driver failed. This was an issue for our vgem backend, which
we use to run ARC++ with QEMU. Let's not add KMS flags for vgem
since we know that doesn't work.
BUG=b:31942635
TEST=arc-cos-gralloc with vgem works
CQ-DEPEND=CL:415442
Change-Id: I33a812ab9a24e2e35a47d28f720c4cc2e83eb8f0
Reviewed-on: https://chromium-review.googlesource.com/416290
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
With CL:405019, drv_insert_supported_combination appended flags if the
{format, modifier} pair was already in the list. This would result
in the BO_USE_RENDERING flag being in the same supported combination
as BO_USE_LINEAR, even though the arrays in the drivers try to separate
these cases. Initially, add all the combinations specified by
the drivers. When querying KMS, add a helper function that modifies
existing combinations if they already exist.
BUG=b:31942635,
TEST=graphics_Gbm, Chrome boots on minnie
CQ-DEPEND=CL:414584
Change-Id: I64326be2078ae745fca2c819e8344797aef3c667
Reviewed-on: https://chromium-review.googlesource.com/415442
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We were incorrectly advertising the scanout and cursor flags in
the drivers.
Chrome never used the BO_USE_CURSOR flag (see chromium:666488), and we
set it for incorrect formats. Let's only advertise ARGB8888/XRGB8888
cursors if they were previously advertised, and prevent cursors from being
used as render targets.
For scanout, formats can vary from kernel version to kernel version.
For example, the v3.18 i915 driver can't scanout NV12, but the upstream v4.4
i915 driver can. Let's query the KMS API in those cases.
In addition, we would also like to move to a place where our backends can
determine if a specific {format, usage, format modifier} tuple is supported.
The plan is to add modifiers to the properties that are exposed in KMS, which
can help with optimization.
BUG=b:31942635, chromium:666488
TEST=Ran graphics_Gbm and checked if Chrome boots on cyan, minnie, and
nyan_big
CQ-DEPEND=CL:413325
Change-Id: Ifd3fd1c8063db97b3f1fe057ace82d22def76943
Reviewed-on: https://chromium-review.googlesource.com/405019
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Ilja H. Friedel <ihf@chromium.org>
We were duplicating formats. The original rationale behind this was
DRV_FORMAT_* would be a superset of Android and DRM formats. However,
there are only 2 HAL flexible formats not defined by DRM, and we can
deal with these easily. The DRM format namespace is large enough to
handle any additions we may need.
BUG=NONE
TEST=Ran graphics_Gbm,
arc-cros-gralloc still builds
Change-Id: Ie173eee6ac6926947a3b98c3ae809e38a0ea8014
Reviewed-on: https://chromium-review.googlesource.com/405790
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
On device with 32-bit userspace on 64-bit kernel we need to make
sure mmap64 is used to import buffer, or the call may fail because
of invalid offset.
BUG=None
TEST=Use libgbm to import drm_gralloc buffer on Elm.
Change-Id: I1b70d105e6f135d8fa534fb99cad266eed910ea9
Reviewed-on: https://chromium-review.googlesource.com/405147
Commit-Ready: Ricky Liang <jcliang@chromium.org>
Tested-by: Ricky Liang <jcliang@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Adding ABGR8888 breaks the software cursor on ARC++,
XBGR8888 is not supported by the DRM driver.
BUG=b:32554065
BUG=chrome-os-partner:59436
TEST=Open play store on elm, cursor appears fine.
Change-Id: I7366d2b2acfc50415c381131ba7cf8b70c0de5d8
Reviewed-on: https://chromium-review.googlesource.com/408536
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
This is helpful for importing multiplanar formats (see b/31999328)
and importing AFBC format modifiers.
BUG=chrome-os-partner:56407
TEST=drm-tests null_platform_test with AFBC support
test_that -b cyan $IP1 graphics_Gbm to check for regressions
Change-Id: If7ed9b54e18069ca69b2dbda2b01d59ce58ebeef
Reviewed-on: https://chromium-review.googlesource.com/401439
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
All of these drivers don't support the ability to directly scan-out
YV12 to the display, so this should not be set.
Let's set rendering flags since the expected use case is importing
Android YV12 buffers into EGL.
BUG=b/32260847
TEST=AdaptivePlaybackTest#testH264_adaptiveDrc
Change-Id: I53d4eaf9c3f359c1c83762cf3e655cc0cf5168d5
Reviewed-on: https://chromium-review.googlesource.com/401040
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We need ABGR8888, XBGR8888, and RGB565 buffers for mediatek.
We also need to add certain flags to our flexible YUV formats.
BUG=chromium:616275
TEST=run dEQP EGL tests on elm.
CQ-DEPEND=CL:398424
Change-Id: Ia3122b4e792911575e13fcbeb4f77b5691290a2d
Reviewed-on: https://chromium-review.googlesource.com/399924
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
The Play store passes down the 0x8933 flag sometimes, which translates
to:
GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_OFTEN |
GRALLOC_USAGE_HW_TEXTURE | GRALLOC_USAGE_HW_COMPOSER |
GRALLOC_USAGE_HW_FB | GRALLOC_USAGE_CURSOR
so we need to handle this case with ABGR8888 buffers. In addition,
the dEQP EGL tests require RGB565 and XBGR8888 formats to succeed.
BUG=chromium:616275
TEST=Play angry birds on minnie, also verified all EGL dEQP tests pass:
run cts --package com.drawelements.deqp.egl
CQ-DEPEND=CL:392548
Change-Id: Ifb4953741bdd4c85a210e499061c8c4a0a6a731e
Reviewed-on: https://chromium-review.googlesource.com/398424
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
When running x86 ARC++ images on a virtual machine, we use
the vgem driver. We should support it here too.
BUG=chromium:616275
TEST=container boots when running QEMU with cros_gralloc. Note
videos (i.e, YUV formats) don't work on QEMU, but they never did
with gralloc_drm either.
CQ-DEPEND=CL:392548
Change-Id: If9f6b8035f2a88068980bede5121ef4599b37272
Reviewed-on: https://chromium-review.googlesource.com/392549
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
For NV12 buffers to work on Android, we need to use the same
logic that we use in gralloc_drm_rockchip. Otherwise, video
playback doesn't work in the container.
BUG=chromium:616275
TEST=Play Youtube app. Also ran plane_test (which defaults to NV12).
CQ-DEPEND=CL:392547
Change-Id: I8dbd989f2638c99200866f8191450c71114bdbe5
Reviewed-on: https://chromium-review.googlesource.com/392548
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
The Play Store wants a HAL_PIXEL_FORMAT_RGBA_8888 (ABGR with fourcc)
buffer with the 0x8933 flag sometimes, which translates to:
GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_OFTEN |
GRALLOC_USAGE_HW_TEXTURE | GRALLOC_USAGE_HW_COMPOSER |
GRALLOC_USAGE_HW_FB | GRALLOC_USAGE_CURSOR
Some dEQP EGL tests also need XBGR8888 buffers with
GRALLOC_USAGE_SW_WRITE_OFTEN | GRALLOC_USAGE_SW_READ_OFTEN flags.
In addition, we need to support YUV buffers with these usage flags:
GRALLOC_USAGE_EXTERNAL_DISP | GRALLOC_USAGE_HW_COMPOSER |
GRALLOC_USAGE_TEXTURE
for Youtube videos to work, so add that too.
BUG=chromium:616275
TEST=Play Angry birds and run Youtube app on Cyan. Verified all dEQP
EGL tests pass:
run cts --package com.drawelements.deqp.egl
CQ-DEPEND=CL:392546
Change-Id: I3a4a03e4b300240a167e1fbc3eb3e23c55551c8b
Reviewed-on: https://chromium-review.googlesource.com/392547
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
FrameBufferSurface.cpp (used by SurfaceFlinger) requires
GRALLOC_USAGE_HW_FB and GRALLOC_USAGE_HW_COMPOSER flags.
It's annoying to update so many flags in driver-supported lists, and
difficult to read. Let's remove redundant flags and try to keep the
ones that one have a distinct and granular meaning.
CQ-DEPEND=CL:362062
Change-Id: I6e1974b02e90a4a98c350867d71050fee728ce3a
Reviewed-on: https://chromium-review.googlesource.com/392546
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
It is desirable to have a gralloc implementation based on the same
drivers we use for minigbm. This will help synchronize the code between
CrOS and the Android container.
BUG=chromium:616275
TEST=Ran the gralloc unit test:
test_that -b veyron_minnie-cheets $IP1 graphics_Gralloc
Verified it succeeded.
CQ-DEPEND=CL:395066
Change-Id: Iff11eba3a92268327ef00eb12b4eabe6fc190cf3
Reviewed-on: https://chromium-review.googlesource.com/362062
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We previously added the gbm_bo_map/gbm_bo_unmap (see CL:393927)
entry points since we wanted to do driver-specific detiling during
screenshot capture tests. We ignored most the parameters and mapped
the entire buffer. This CL adds the ability to:
1) Return the starting address within a byte given a specific x, y
in the buffer.
2) Handle the case where there are more than one kernel buffers
per buffer object. Currently, only the Exynos driver would use
this capability.
BUG=chromium:653284
TEST=Ran cros_gralloc with modified code
CQ-DEPEND=CL:393927
Change-Id: I19d75d2f16489c0184e96305fb643f18477e1cdb
Reviewed-on: https://chromium-review.googlesource.com/395066
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
This reverts commit bb19d6abec.
This was chumped w/out explanation, and the bots have all been
dead since due to graphics_Gbm check failures. Reverting in
the hope it'll fix things. It can reland via the CQ.
BUG=chromium:654245
Change-Id: I0d88f7731e9e90fffee1485056d787430eb0b850
Reviewed-on: https://chromium-review.googlesource.com/395727
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
BUG=chrome-os-partner:56407
TEST=drm-tests null_platform_test with AFBC support
Change-Id: If7ed9b54e18069ca69b2dbda2b01d59ce58ede0b
Reviewed-on: https://chromium-review.googlesource.com/387145
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Trybot-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
We want to add gbm_bo_map/gbm_bo_unmap entry points so certain tests
and Chrome can use driver specific map logic. This is based on the
upstream entry points in Mesa, with the addition of a plane parameter.
Currently, we just map the entire buffer and don't attempt to do partial
mappings or use the map flags. We should do this in the future...
BUG=chromium:653284
TEST=minigbm builds
Change-Id: I0423c10c55bab8fac6d6d7c6a699ab71b43aa61b
Reviewed-on: https://chromium-review.googlesource.com/393927
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Oak-cheets is using YV12 as it's Android flexible YUV format, so
we need to support it. Additionally, we're trying to enable
YV12 on Mali with EXT_image_dma_buf_import. Instead of having
redundant switch statements in every driver, let's add a helper
function to do this.
BUG=chrome-os-partner:54632, b/29059119, chromium:616275
TEST=Ran plane_test, graphics_Gbm on veyron_minnie
Change-Id: I4798225db809941367e58dde962576535b8d767c
Reviewed-on: https://chromium-review.googlesource.com/377884
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
