| Age | Commit message (Collapse) | Author |
|---|
|
9p is going to be built into the kernel binary in aosp/3073413. Removing
the other modules is necessary to support ARM, otherwise we will be
adding symbols for things we don't actually use.
Bug: 332937984
Test: tools/bazel run //common-modules/virtual-device:virtual_device_aarch64_dist
tast run $DUT arc.Boot.vm
Change-Id: I6e7ed3daf2b57e4c39131cf05faf1c5e4bc90e6b
|
|
No longer needed as we use erofs instead
Bug: b/332937984
Test: tools/bazel run //common-modules/virtual-device:virtual_device_x86_64_dist
Change-Id: I0906bc0fa7174f9c354e524e392e038ff1b7fde2
|
|
into android13-5.15-arcvm
|
|
The FUSE tmpfile implementation in Linux upstream cannot be backported
to android13-5.15 because it breaks the ABI. Set up FUSE vendor module
to provide a non-atomic implementation of tmpfiles that can connect
to the vendor hooks in the common kernel. Allow handlers for other
vendor hooks to be added easily.
This implementation is based off of the changes to the ARCVM kernel
in crrev/c/2581186, crrev/c/2581136, and crrev/c/2601035. Vendor hooks
for tmpfiles are added to the android13-5.15 common kernel in
aosp/2956757.
BUG=323975715
BUG=318581825
TEST=arc.Boot.vm,
cts -m CtsBionicTestCases -t dlext#dlopen_ext_use_o_tmpfile_fd,
cts -m CtsPerfettoTestCases -t PerfettoCmdlineTest#NoDataNoFileWithoutTrigger
Change-Id: I069f7943670d2c4891106e78cb5b1fac8cb4e1d8
Signed-off-by: Tiffany Yang <ynaffit@google.com>
|
|
Use `enum virtio_video_queue_type` instead of `uint32_t` in the 3rd arg
of prototype definition of virtio_video_cmd_resource_destroy_all to fix
mismatch error on `-Werror=enum-int-mismatch`.
BUG=b:295256641
TEST=make O=../v5.10-arcvm_build x86_64_arcvm_defconfig
TEST=make -j`nproc` O=../v5.10-arcvm_build bzImage
Change-Id: I07fec352cabbde37e843588e3222b3ccc1286878
Signed-off-by: Hikaru Nishida <hikalium@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5219941
Reviewed-by: Suleiman Souhlal <suleiman@google.com>
Commit-Queue: Suleiman Souhlal <suleiman@google.com>
Signed-off-by: Tiffany Yang <ynaffit@google.com>
|
|
Add a missing bounds check and fix a potential integer overflow in
vfd_out_lock.
BUG=b:283747290
TEST=tast run DUT arc.Boot.vm
Change-Id: I7ac37921f8e89904d28b32ee183667502e32eb51
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4592734
Reviewed-by: Suleiman Souhlal <suleiman@chromium.org>
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
The underlying memory will be filled soon, zalloc is unnecessary.
BUG=b:272432362
TEST=manual - run ARCVM with updated kernel
Change-Id: Ia4e843d1a53b25c78ccf0c1df6114fff022803bf
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4383724
Reviewed-by: Suleiman Souhlal <suleiman@chromium.org>
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
support is needed by native context VirtIO-GPU Mesa drivers, it also will
be used by Venus and Virgl contexts.
Reviewed-by; Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> # amdgpu nctx
Tested-by: Rob Clark <robdclark@gmail.com> # freedreno nctx
Reviewed-by: Rob Clark <robdclark@gmail.com>
Acked-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-4-dmitry.osipenko@collabora.com
(cherry picked from commit 7cb8d1ab8cbda554341dac8b54fd135dedff4245
git://anongit.freedesktop.org/drm/drm-misc drm-misc-next)
BUG=b:253779836
TEST=sanity test turnip native ctx on strongbad
Signed-off-by: Rob Clark <robdclark@chromium.org>
Change-Id: I5923558cbb8773e1e9f1c3b0b41a9875d1c8dd0b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4766618
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Chia-I Wu <olv@google.com>
Bug: b/310208240
Test: tast run $DUT arc.PlayStore.vm
Change-Id: I20cba76a728093c8a94ca05d6dce75fa25c8421a
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
We don't want to create a fence for every command submission. It's
only necessary when userspace provides a waitable token for submission.
This could be:
1) bo_handles, to be used with VIRTGPU_WAIT
2) out_fence_fd, to be used with dma_fence apis
3) a ring_idx provided with VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK
+ DRM event API
4) syncobjs in the future
The use case for just submitting a command to the host, and expecting
no response. For example, gfxstream has GFXSTREAM_CONTEXT_PING that
just wakes up the host side worker threads. There's also
CROSS_DOMAIN_CMD_SEND which just sends data to the Wayland server.
This prevents the need to signal the automatically created
virtio_gpu_fence.
In addition, VIRTGPU_EXECBUF_RING_IDX is checked when creating a
DRM event object. VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is
already defined in terms of per-context rings. It was theoretically
possible to create a DRM event on the global timeline (ring_idx == 0),
if the context enabled DRM event polling. However, that wouldn't
work and userspace (Sommelier). Explicitly disallow it for
clarity.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # edited coding style
Link: https://patchwork.freedesktop.org/patch/msgid/20230707213124.494-1-gurchetansingh@chromium.org
(cherry picked from commit 70d1ace56db6c79d39dbe9c0d5244452b67e2fde
git://anongit.freedesktop.org/drm/drm-misc drm-misc-next)
BUG=b:253779836
TEST=sanity test turnip native ctx on strongbad
Signed-off-by: Rob Clark <robdclark@chromium.org>
Change-Id: If1e844f23e848f1a5ed3a420bf6b77a54f3a055d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4766617
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Chia-I Wu <olv@google.com>
Bug: b/310208240
Test: tast run $DUT arc.PlayStore.vm
Change-Id: I00cadc4433906ae416abb7987aa1c20c5e8ab117
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
Use dma-fence-unwrap API for waiting each dma-fence of the in-fence array
individually. Sync file's in-fence array always has a non-matching fence
context ID, which doesn't allow to skip waiting of fences with a matching
context ID in a case of a merged sync file fence.
Suggested-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-3-dmitry.osipenko@collabora.com
(cherry picked from commit eba57fb5498f2858768321e64570caea188455b8)
BUG=b:253779836
TEST=sanity test turnip native ctx on strongbad
Signed-off-by: Rob Clark <robdclark@chromium.org>
Change-Id: I2bdeeb52181480797825cc4e97dd23fceaf9790b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4766616
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Bug: b/310208240
Test: tast run $DUT arc.PlayStore.vm
Change-Id: I7f2559aa7d5e1a992636c8cbe40acc6385c41ff4
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
Move virtio_gpu_execbuffer_ioctl() into separate virtgpu_submit.c file,
refactoring and optimizing the code along the way to ease addition of new
features to the ioctl.
The optimization is done by using optimal ordering of the job's submission
steps, reducing code path from the start of the ioctl to the point of
pushing job to virtio queue. Job's initialization is now performed before
in-fence is awaited and out-fence setup is made after sending out job to
virtio.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-2-dmitry.osipenko@collabora.com
(cherry picked from commit e4812ab8e6b142e1ce19b50fcf744e20ea9adfe3)
BUG=b:253779836
TEST=sanity test turnip native ctx on strongbad
Signed-off-by: Rob Clark <robdclark@chromium.org>
Change-Id: I72038d127304b4fec727462b4f6015b3e86a2504
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4763663
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Bug: b/310208240
Test: tast run $DUT arc.PlayStore.vm
Change-Id: I4d1fcd40b64e7f7febef65989c6302111737ac72
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
When VIRTGPU_EXECBUF_RING_IDX is used, we should be considering the
timeline that the EB if running on rather than the global driver fence
context.
Fixes: 85c83ea915ed ("drm/virtio: implement context init: allocate an array of fence contexts")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20220812224001.2806463-1-robdclark@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 3007dc2af6e86ac00b4daf7414142637fdf50bfa)
BUG=b:253779836
TEST=sanity test turnip native ctx on strongbad
Change-Id: I5b5ce0abe5b8ab0480beb91a765ebe00fde015ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4763662
Tested-by: Rob Clark <robdclark@chromium.org>
Auto-Submit: Rob Clark <robdclark@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Rob Clark <robdclark@chromium.org>
Bug: b/310208240
Test: tast run $DUT arc.PlayStore.vm
Change-Id: I63034508ee50bd020360c9a9b067a0bec8537c93
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
The ->ring_idx_mask variable is a u64 so static checkers, Smatch in
this case, complain if the BIT() is not also a u64.
drivers/gpu/drm/virtio/virtgpu_ioctl.c:50 virtio_gpu_fence_event_create()
warn: should '(1 << ring_idx)' be a 64 bit type?
Fixes: cd7f5ca33585 ("drm/virtio: implement context init: add virtio_gpu_fence_event")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/YygN7jY0GdUSQSy0@kili
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 37a78445763a5921bb54e9bad01937d0dfa521c1)
BUG=b:253779836
TEST=sanity test turnip native ctx on strongbad
Signed-off-by: Rob Clark <robdclark@chromium.org>
Change-Id: Ic3bd10f478dbb59b8c55a255899d3f5d2a671f2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4763661
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Bug: b/310208240
Test: tast run $DUT arc.PlayStore.vm
Change-Id: Ic23a968184f4574322ffecf3a90556a2af4cf890
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
VirtIO-GPU got a new config option for disabling KMS. There were two
problems left unnoticed during review when the new option was added:
1. The IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) check in the code was
inverted, hence KMS was disabled when it should be enabled and vice versa.
2. The disabled KMS crashed kernel with a NULL dereference in
drm_kms_helper_hotplug_event(), which shall not be invoked with a
disabled KMS.
Fix the inverted config option check in the code and skip handling the
VIRTIO_GPU_EVENT_DISPLAY sent by host when KMS is disabled in guest to fix
the crash.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Fixes: 72122c69d717 ("drm/virtio: Add option to disable KMS support")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230306163916.1595961-1-dmitry.osipenko@collabora.com
(cherry picked from commit aad9729ec0e009440ac8c1a4be2204e4d3c08977)
BUG=b:253779836
TEST=sanity test turnip native ctx on strongbad
Signed-off-by: Rob Clark <robdclark@chromium.org>
Change-Id: Idbff68606a5095aada54da6251202c83aea46852
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4763660
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Bug: b/310208240
Test: tast run $DUT arc.PlayStore.vm
Change-Id: I55bfee533c6cb65e47b96c5dc47e637ca9d7134b
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
As the modesetting ioctls are a big surface area for potential security
bugs to be found (it's happened in the past, we should assume it will
again in the future), it makes sense to have a build option to disable
those ioctls in cases where they serve no legitimate purpose.
v2: Use more if (IS_ENABLED(...))
v3: Also permit the host to advertise no scanouts
v4: Spiff out commit msg
v5: Make num_scanouts==0 and DRM_VIRTIO_GPU_KMS=n behave the same
v6: Drop conditionally building virtgpu_display.c and early-out of
it's init/fini fxns instead
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230302233506.3146290-1-robdclark@gmail.com
(cherry picked from commit 72122c69d71784e390527819754ea456421c4501)
Conflicts:
drivers/gpu/drm/virtio/virtgpu_drv.c
BUG=b:253779836
TEST=sanity test turnip native ctx on strongbad
Change-Id: I796421661ed41372ed895820ace6bef59c5ef885
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4763659
Tested-by: Rob Clark <robdclark@chromium.org>
Auto-Submit: Rob Clark <robdclark@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Rob Clark <robdclark@chromium.org>
Bug: b/310208240
Test: tast run $DUT arc.PlayStore.vm
Change-Id: I47d4cf13059d07c9b4efeecc54142bb59a31eff6
Signed-off-by: Richard Fung <richardfung@google.com>
|
|
Bug: b/302746140
Test: tast run $DUT arc.VideoDecodeAccel.*
tast run $DUT arc.VideoEncodeAccel.*
Change-Id: Iba3b5c2908b8cb6ed78885eecd2f4d466c69167e
|
|
Bug: b/302746140
Test: tast run $DUT arc.VideoDecodeAccel.*
tast run $DUT arc.VideoEncodeAccel.*
Change-Id: I3b56f41a1b04c40f4f82ae9f27f3670f66505806
|
|
This patch modifies how driver checks if debug parameter is set in order
to allow enabling debugging after module have been loaded. Furthermore
command request and response logging was added.
Signed-off-by: Bartłomiej Grzesik <bgrzesik@google.com>
BUG=None
TEST=echo 1 > /sys/module/virtio_video/parameters/debug; dmesg
Change-Id: I93fd4a848af763f30b95919ff705aab84499ca5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4254045
Reviewed-by: Marcin Wojtas <mwojtas@google.com>
Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Bartłomiej Grzesik <bgrzesik@google.com>
|
|
This patch defers partial initialization of virtio video device to global
kernel workqueue in order to reduce probe execution time whenever
CMD_QUERY_CAPABILITY fails to respond (eg. hypervisor backend failure).
Initialization of V4L2 Device was moved to a deferred function to prevent
usage of the device before full initialization is finished. For this reason
v4l2_err no longer could be used for printing and was replaced with
dev_err. Furthermore a switch to video_register_device_no_warn to suppress
index duplication warning.
Signed-off-by: Bartłomiej Grzesik <bgrzesik@google.com>
BUG=b:235763012
TEST=Request sign off on Chromebook during VM boot
Change-Id: I7aa2a92810e1b920fee8ba104a8f9c7f401ec00d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4177375
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Marcin Wojtas <mwojtas@google.com>
Tested-by: Hubert Mazur <hmazur@google.com>
Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
|
|
A drain can not occur before all buffers are sent, but since
a drain and worker (which handles sending buffers to the hypervisor)
runs on different treads they can run in parallel which can lead to
data races between buffers and drain. To prevent that drain will
check if all buffers were sent already and if not wait for
a notification from the worker which will be sent when it finishes
sending buffers.
Signed-off-by: Patryk Busse <pbu@semihalf.com>
BUG=b:232394659
TEST=android.mediav2.cts.CodecEncoderTest
Change-Id: If7e8db7e70832b0b6bbf9fca6afe4645f96be2c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4098528
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Patryk Busse <pbu@semihalf.com>
|
|
Prior this patch, if a v4l2_m2m_ctx_release was called between queueing
worker and it's execution, the worker would try to lock on an NULL
mutex, causing kernel crash.
This patch cancels a rending worker, before releasing an
v4l2_m2m_ctx.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:245795223
TEST=None
Change-Id: I23f82d9409ca2c7d528df16f999c7ec32f75e91a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4106180
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Reviewed-by: Marcin Wojtas <mwojtas@google.com>
Auto-Submit: Bartłomiej Grzesik <bag@semihalf.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
Do not call set_params during REQBUFS(0). If the count is zero, the
queue is freed and we should not do any further processing. Calling
set_params in this case is correctly identified by CrosVM as a mistake
and the following error is emitted:
[ERROR devices::virtio::video::decoder] parameter for input cannot be
changed once decoding started
BUG=b:161774071
TEST=emerge-brya sys-kernel/arcvm-kernel-ack-5_10
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Change-Id: Icb5012df2a5e7085d3f8f84e86f7f59903803f07
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4066822
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Bartłomiej Grzesik <bgrzesik@google.com>
|
|
H.264 is the only format that features a level. Querying that property
on other formats results in the following log by crosvm:
specified format has no level: VP8
returning error response: invalid argument
While it is not fatal, it can be confused with an actual error, so stop
querying for level on non-H264 format.
BUG=b:161774071
TEST=emerge-brya sys-kernel/arcvm-kernel-ack-5_10
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Change-Id: Id18807859bd145d0fce533e0cf844a465095fc81
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4066821
Reviewed-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
|
|
Timestamps related to video buffers are in nanoseconds
but lower layers of the system expect this information to
be presented in microseconds. To keep compatibility with remaining
part of the system and do not modify logic related to handling
information about time in ARCVM, timestamps for encoder buffers are
adjusted to hold value in microseconds.
BUG=b:230794145
TEST=android.media.cts.VideoCodecTest#testBasicAVCCBR
Change-Id: I67222bca7dc5e8eb829f519b0235c4320ce37264
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4062034
Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-by: Marcin Wojtas <mwojtas@google.com>
Tested-by: Patryk Busse <pbu@semihalf.com>
|
|
formats.
The linked list was initialized in a fashion where elements with larger
indices were added to the beginning. This effectively reversed their order,
and resulted in wrong supported format combinations being reported.
To initialize a list in order of iteration, list_add_tail should be used
instead of list_add.
BUG=b:239897269
TEST=https://crrev.com/c/3920263 reports the correct format combinations
(h264: NV12/YV12, h265,vp8,vp9: YV12 only).
Signed-off-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Change-Id: Ieffd49bc697e7f076393d7ca141d500bc39e07b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3929881
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
|
|
This patch changes tracing functions to rely on request, rather then on
response. Currently the crosvm's implementation of virtio-video backend
does not passes the stream id in the command response and fixing this is
not required and would be time consuming.
BUG=b:217825939 b:217827216 b:232531771
TEST=echo 1 > /sys/kernel/tracing/events/virtio_video/enable \
&& cat /sys/kernel/debug/tracing/trace
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
Change-Id: Iefaefc413be3f3a120e76afd6b172da7cda715eb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3921725
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Reviewed-by: Marcin Wojtas <mwojtas@google.com>
|
|
This patch adds virtio_video trace points for debugging purposes:
* virtio_video:virtio_video_resource_queue
* virtio_video:virtio_video_resource_queue_done
* virtio_video:virtio_video_cmd
* virtio_video:virtio_video_cmd_done
using linux/tracepoint.h and DEFINE_EVENT interface.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:217825939 b:217827216 b:232531771
TEST=echo 1 > /sys/kernel/tracing/events/virtio_video/enable \
&& cat /sys/kernel/debug/tracing/trace
Change-Id: I1220f076d72276add343573469b1de4a5f0c2c0a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3859572
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
This is a reland of commit 9c43883fe0b6bb2116fae9923ea6445aa179151f
Original change's description:
> CHROMIUM: media: virtio: remove current_frame field from stream struct
>
> Field current_frame was used to store currently used stream format
> information provided by hypervisor. It was originaly set by
> virtio_video_try_fmt function. This function is used to check if
> provided format can be handled by the device. Same functionality is
> expected from currently unsupported VIDIOC_TRY_FMT. This function modified
> state of the driver, which is forbiden by spec for this ioctl.
> The field was used only in VIDIOC_S_PARM implementation for encoder.
>
> This patch removes current_frame field, by introducing new function
> (virtio_video_find_format). These changes are needed for future support
> for VIDIOC_TRY_FMT and to fix VIDIOC_S_PARM. Both are causing
> v4l2-compliance to fail. With this patch VIDIOC_S_PARM will no
> longer fail in early stages of encoder (before VIDIOC_S_FMT call).
>
> Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
>
> BUG=b:160440787
> TEST=v4l2-compliance -d /dev/video0
> TEST=v4l2-compliance -d /dev/video1
> TEST=tast run eve arc.Video*
>
> Change-Id: I9fc3ef0f320125be027a824092fc6d594d698473
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3423528
> Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
> Tested-by: Patryk Busse <pbu@semihalf.com>
> Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
> Reviewed-by: Patryk Busse <pbu@semihalf.com>
> Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Bug: b:160440787
Change-Id: I293a60b5f172251d22476f32a4c96f0c1d72501d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3853864
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Tested-by: Marcin Wojtas <mwojtas@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
|
|
The virtio-video spec states:
timestamp: ... For VIRTIO_VIDEO_QUEUE_TYPE_OUTPUT, the driver MUST set
it to 0.
For compliance purposes, only set this value for input queues. The struct
is zero-initialized on allocation, so timestamp will be 0 otherwise.
BUG=b:239897269
TEST=v4l2r decoding tests from crosvm book and FFmpeg encoding tests
(https://crrev.com/c/3836232) passes.
TEST=tast arc.VideoDecodeAccel*_vm
TEST=tast arc.VideoEncodeAccel*_vm
Change-Id: Id19a352dfe036273699440ee9d053fd79700baef
Signed-off-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3852533
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
|
|
This reverts commit 9c43883fe0b6bb2116fae9923ea6445aa179151f.
Reason for revert: broke CTS b/243319006
Original change's description:
> CHROMIUM: media: virtio: remove current_frame field from stream struct
>
> Field current_frame was used to store currently used stream format
> information provided by hypervisor. It was originaly set by
> virtio_video_try_fmt function. This function is used to check if
> provided format can be handled by the device. Same functionality is
> expected from currently unsupported VIDIOC_TRY_FMT. This function modified
> state of the driver, which is forbiden by spec for this ioctl.
> The field was used only in VIDIOC_S_PARM implementation for encoder.
>
> This patch removes current_frame field, by introducing new function
> (virtio_video_find_format). These changes are needed for future support
> for VIDIOC_TRY_FMT and to fix VIDIOC_S_PARM. Both are causing
> v4l2-compliance to fail. With this patch VIDIOC_S_PARM will no
> longer fail in early stages of encoder (before VIDIOC_S_FMT call).
>
> Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
>
> BUG=b:160440787
> TEST=v4l2-compliance -d /dev/video0
> TEST=v4l2-compliance -d /dev/video1
> TEST=tast run eve arc.Video*
>
> Change-Id: I9fc3ef0f320125be027a824092fc6d594d698473
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3423528
> Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
> Tested-by: Patryk Busse <pbu@semihalf.com>
> Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
> Reviewed-by: Patryk Busse <pbu@semihalf.com>
> Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
BUG=b:243319006
TEST=android.video.cts.VideoEncoderDecoderTest#testAvcOther0Perf0320x0240
Change-Id: If85063b1e6e6320f42d3e419e64bd0457f5f586d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3849482
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Kazuhiro Inaba <kinaba@chromium.org>
Tested-by: Shao-Chuan Lee <shaochuan@chromium.org>
Commit-Queue: Shao-Chuan Lee <shaochuan@chromium.org>
|
|
VIDIOC_G_PARM and VIDIOC_S_PARM ioctls are used for setting and getting
stream frame rate for encoder device. Till this point the VIDIOC_G_PARM
was not supported for output queue. And in both, VIDIOC_G_PARM and
VIDIOC_S_PARM handlers V4L2_TYPE_IS_OUTPUT was used to distinguish queue
types, which could lead to incorrect behaviour when non multiplanar type
was given.
This patch fixes v4l2-compliance fails by adding support for VIDIOC_G_PARM
on output queue and disallowing these ioctls for non multiplanar types.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: If36197f182444d42bdf103fafafab52d727a4117
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3429243
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Patryk Busse <pbu@semihalf.com>
Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
|
|
Before this patch v4l2-compliance was failing when hypervisor reported
allowed minimum frame rate equal to zero for encoder device.
This patch fixes this issue, but returning a fraction with numerator
set to 1 and denumator set to U32_MAX in case of minimum frame rate
equal to zero.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: Ic805e46468a3fbfd4426d16e96cee531dd26bad1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3429242
Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Patryk Busse <pbu@semihalf.com>
|
|
This patch adds support for previosly unsupported VIDIOC_TRY_FMT ioctl
for encoder and decoder devices. It is implemented using already existing
function virtio_video_try_fmt.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: I4b1e48ef3a8a00a0de9d7ac3983cbe7456bb8060
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3423863
Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
Tested-by: Patryk Busse <pbu@semihalf.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
|
|
Field current_frame was used to store currently used stream format
information provided by hypervisor. It was originaly set by
virtio_video_try_fmt function. This function is used to check if
provided format can be handled by the device. Same functionality is
expected from currently unsupported VIDIOC_TRY_FMT. This function modified
state of the driver, which is forbiden by spec for this ioctl.
The field was used only in VIDIOC_S_PARM implementation for encoder.
This patch removes current_frame field, by introducing new function
(virtio_video_find_format). These changes are needed for future support
for VIDIOC_TRY_FMT and to fix VIDIOC_S_PARM. Both are causing
v4l2-compliance to fail. With this patch VIDIOC_S_PARM will no
longer fail in early stages of encoder (before VIDIOC_S_FMT call).
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: I9fc3ef0f320125be027a824092fc6d594d698473
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3423528
Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
Tested-by: Patryk Busse <pbu@semihalf.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Patryk Busse <pbu@semihalf.com>
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
|
|
not multiplanar
virtio-video driver at the moment only supports multiplanar buffer
types. In VIDIOC_S_FMT and VIDIOC_G_FMT, V4L2_TYPE_IS_OUTPUT macro is
used to distinguish OUTPUT and CAPTURE buffers. This leads to those
ioctls treating V4L2_BUF_TYPE_VIDEO_CAPTURE the same as
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE (same problem applies for OUTPUT
types). This is incorrect and causes v4l2-compliance to fail.
This patch returns EINVAL if passed buffer type is not multiplanar.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: I3fd19908cb615e218d1edb3ac229b2fdf9fb36a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3401973
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
changes
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE and V4L2_CID_MIN_BUFFERS_FOR_OUTPUT
controls specify minimum buffers that application has to request using
VIDIOC_REQBUFS. In virtio-video this value is acquired from hypervisor
after setting required parameters. There is possibility that this value
can change after changing stream parameters.
Furthermore v4l2-compliance requires that V4L2_EVENT_CTRL subscription
is supported if user controls exists. Currently driver returns EINVAL
when subscribing to V4L2_EVENT_CTRL.
This patch allows V4L2_EVENT_CTRL subscription and queues event, if
change in min_buffers value has been detected.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
TEST=tast run eve arc.Video*
Change-Id: I2e27e623e28e198532dbe5b174aa712dc124ee4d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3348418
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
Originally the virtio-video spec required the resource type to be decided
when a stream a created. However we don't know what kind of buffers
user-space is going to allocate until it calls VIDIOC_REQBUFS, way after
stream creation.
The driver worked this around by supporting a single type
of resource (virtio objects), but now that we want to also support
buffers in guest memory we need to be able to set the resource type
later. The GET/SET_PARAMS_EXT commands have been introduced to allow
that, so switch this driver to use them instead of GET/SET_PARAMS.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
BUG=b:193202566
TEST=Android Youtube can play videos on Hatch.
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on Hatch.
Change-Id: I742a81b62dc1c1197f16f76c28496f133a492683
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3349429
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
|
|
codec is in use
Currently values from VIDIOC_S_CTRLS are passed blindly to hypervisor,
no matter what codec is in use. This will always fail or cause undefined
behaviour.
This patch makes VIDIOC_S_CTRLS implementation for encoder return EINVAL
if trying to set H264 specific controls while different format is used.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:161774071
TEST=tast run eve arc.Video*
Change-Id: Idc267e99a5834164c501572142258297fd433028
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3395052
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
Use v4l2_m2m_ioctl_enc/dec.try_command() to deal
with command validation and setting of flags and
encoder/decoder parameters.
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
TEST=v4l2-compliance -d /dev/video1
Signed-off-by: Zyta Szpak <zr@semihalf.com>
Change-Id: I0bdadd9326f4ffc9b4445e40ed7a149c518e1198
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3386680
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Zyta Szpak <zyta.szpak@semihalf.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
seperate function
In order to change stream parameters driver queues SET_PARAMS and
GET_PARAMS commands to hypervisor. This pattern repeats for multiple
scenarios (eg. VIDIOC_S_FMT, VIDIOC_S_PARM ioctls implementation).
This patch extracts those function pairs into a new function
virtio_video_update_params, which will help avoid code duplication in
future patch adding queueing event on user controls change and other
potential patches.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
BUG=b:161774071
TEST=tast run eve arc.Video*
TEST=v4l2-compliance -d /dev/video0
Change-Id: Ie4e472b7467b0ea440f77ad27a8b2ce720203e9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3358199
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
The resource type does not need its own enum to be defined - we can
reuse the types from the virtio-video spec and avoid some tedious value
mapping.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
BUG=b:193202566
TEST=Android Youtube can play videos on Hatch.
Change-Id: I84e3ecf7e68ffa95445e6313f4bed73d9b7bcaca
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3349428
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
|
|
There is a difference between the way virtio-video and V4L2 define their
planes. For virtio-video, a plane is always a component plane, and
whether these planes are grouped together in a single buffer is set by a
format flag. For V4L2, a plane corresponds to a memory plane, and
whether a frame uses a single memory plane or one memory plane per
component plane is defined by the format (e.g. NV12 is single-buffer,
but NV12M has 2 buffers, one per component plane).
The problem is that the driver directly maps the component planes into
V4L2 planes that are reported to user-space, even when using a
single-buffer layout. This results in incorrect information being given
to user-space, e.g. the NV12 pixel format having 2 planes.
Fix this by aggregating the virtio-video component plane information
into a single V4L2 memory plane when a single-planar V4L2 format is in
use.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
BUG=b:161774071
BUG=b:212214039
TEST=Android Youtube can play videos on zork-arc-r.
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on zork-arc-r.
Change-Id: Ic02b40ceb0be4c16d40c795c27320705e931de23
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3358090
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
|
|
v4l2-compliance fails if it detects that VIDIOC_ENUM_FRAMEINTERVALS
ioctl is supported for a memory to memory device other then encoder.
Currently virtio-video allows calling VIDIOC_ENUM_FRAMEINTERVALS ioctl
for decoder devices.
In case of crosvm this call always returns EINVAL, because no
frame rates are provided by hypervisor for decoder device.
This patch disables this ioctl for virtio-video in order to comply
with v4l2-compliance.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
TEST=tast run eve arc.Video*
Change-Id: I708cc89f1eb98103692d78fdda3e14928fdb120c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3365197
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Bartłomiej Grzesik <bgrzesik@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
A video device signals end of stream by sending a V4L2_EVENT_EOS to
subscribed userspace application. The driver is already queueing EOS
event when virtio buffer has appropriate flag.
This patch lets userspace application to subscribe to V4L2_EVENT_EOS,
by adding required logic to VIDIOC_SUBSCRIBE_EVENT ioctl.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=tast run eve arc.Video*
TEST=v4l2-compliance -d /dev/video0
Change-Id: I6615a91e06b2aa74068b05d4386870cfb960cd3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3348417
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
EVENT_SOURCE_CHANGE is signaled whenever decoder detects changes in
source parameters (e.g resolution change). Those changes can occur
only to decoder. Hence v4l2-compliance fails if it is possible
to subscribe to V4L2_EVENT_SOURCE_CHANGE on encoder device.
This patch changes VIDIOC_SUBSCRIBE_EVENT ioctl implementation, to
return EINVAL when trying to subscribe to V4L2_EVENT_SOURCE_CHANGE
on encoder device.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=tast run eve arc.Video*
TEST=v4l2-compliance -d /dev/video0
Change-Id: If16ec4bc8462358369dc66aa0674eac589bbb9c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3348416
Tested-by: Bartłomiej Grzesik <bag@semihalf.com>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
dereference
Currently for loop in VIDIOC_ENUM_FRAMEINTERVALS has a soft inequality
in it's condition. This causes out of bound array indexing and in some
scenarios ends in null pointer dereference and kernel panic.
This patch fixes the panic, by changing soft inequality into hard and by
adding additional if that makes sure that appropriate frame information
was found.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
Change-Id: I8bc68e73d0f570dcf922703704a5d457304cedb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3341518
Tested-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-by: Marcin Wojtas <mwojtas@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
|
|
Currently whenever the client uses VIDIOC_S_PARM ioctl with output
timeperframe's denominator equal to zero, kernel panics due to division
by zero. Also the return value of VIDIOC_S_PARM and VIDIOC_G_PARM ioctls
is returning fraction representing frames per second rather then
time per frame.
This patch fixes this panic, by fixing invalid return values and
replacing zeros in requested time per frame with steam's present
values.
Signed-off-by: Bartłomiej Grzesik <bag@semihalf.com>
BUG=b:203607295 b:208401566
TEST=tast run eve arc.VideoEncodeAccelPerf.* arc.VideoEncodeAccel.*
TEST=Custom Android application that enqueues frames with timestamps
with gaps 5s from one to another. Make sure that kernel doesn't crash.
Change-Id: I8cc41a3864f6ae1a73bf1b9e92168e357afc4a0a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3308799
Reviewed-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Bartłomiej Grzesik <bgrzesik@google.com>
Tested-by: Bartłomiej Grzesik <bgrzesik@google.com>
|
|
DMA ops are not supposed to be set by the driver, but rather by the
platform code. Besides we could not really figure out why this was here
in the first place ; on x86 the ops are not used at all, and on ARM they
are set but create failures.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
BUG=b:202352463
TEST=Android Youtube can play videos on trogdor-arc-r.
TEST=Android Youtube can play videos on zork-arc-r.
Change-Id: Idbd1c77a240f55a2de2716c78ab81df3b4033e95
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3320657
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
|
|
memory type
Since crosvm is soon going to advertize support for buffers in guest
memory, and we have no way in the virtio-video protocol to switch the
memory type dynamically yet, use virtio objects by default as this is
the memory type we are currently using on Chrome OS.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
BUG=b:209523781
TEST=Android Youtube can play videos on zork-arc-r.
Change-Id: I65b628026f5f6d4f5bf8e2ab8e47c03b97d350f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3319806
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Hikaru Nishida <hikalium@chromium.org>
|
|
This reverts commit 82e4012a8ae5c8468ee5b84cda09134a10167dd5.
Reason for revert: ARCVM encoder stops functioning because it still expects the old (incorrect) format description.
BUG=b:205488531
BUG=b:205356442
TEST=ARCVM encoder works again.
Original change's description:
> CHROMIUM: drivers: media: virtio: fix reported V4L2 planes layout
>
> There is a mismatch between the way virtio-video and V4L2 define their
> planes. For virtio-video, a plane is always a color plane, and whether
> color planes are grouped together in a single buffer is set by an
> attribute. For V4L2, a plane is a buffer that can contain one or several
> color planes.
>
> V4L2 uses this latter definition for the "planes" it reports to
> user-space, but the driver currently unconditionally maps the virtio
> color planes to V4L2 plane buffers, despite always using the
> SINGLE_BUFFER layout when communicating formats to the host. This
> results in incorrect information being given to user-space, e.g. the
> NV12 pixel format having 3 planes (NV12 in V4L2 is always single buffer,
> its multi-buffer variant is called NV12M).
>
> Fix this by aggregating the virtio-planes into a single buffer to
> conform to what V4L2 expects.
>
> Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
>
> BUG=b:161774071
> TEST=Android Youtube can play videos on Hatch.
>
> Change-Id: I99c8a7dde58c9048a4f7a08c3925bc6a2626f543
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3247492
> Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
> Tested-by: Alexandre Courbot <acourbot@chromium.org>
> Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
> Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: b:161774071
Change-Id: I8ed8bf6fae1e89a053fce1e7d8b6c78ddf4d17df
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3271531
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
|
