linux.git/drivers/media/platform/qcom, branch v5.8

media: venus: venc,vdec: Return EBUSY on S_FMT while streaming

2020-05-05T11:07:47+00:00

According to the v4l spec s_fmt must return EBUSY while the
particular queue is streaming. Add such check in encoder and
decoder s_fmt methods.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: Mark last capture buffer

2020-05-05T11:07:15+00:00

According to stateful Codec API the decoder will process all
remaining buffers from before the source change event in
dynamic-resolution-change state and mark the last buffer with
V4L2_BUF_FLAG_LAST.

In Venus case the firmware doesn't mark that last buffer and
some mechanism have to be created in v4l decoder driver.
Fortunately the firmware interface (HFI) claims that the
decoder output buffers will be returned to v4l decoder
driver before it send the insufficient event.

In order to do that we save last queued in the driver capture
buffer in the event_notify and issue flush on output firmware
buffers queue. Once the saved buffer is returned (as a result of
flush command) we mark it as LAST. For all that possible we
extend HFI flush command with one more argument and one more
flush_done HFI driver callback.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: vdec: Init registered list unconditionally

2020-05-05T11:06:09+00:00

Presently the list initialization is done only in
dynamic-resolution-change state, which leads to list corruptions
and use-after-free. Init list_head unconditionally in
vdec_stop_capture called by vb2 stop_streaming without takeing
into account current codec state.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: vdec: Mark flushed buffers with error state

2020-05-05T11:05:26+00:00

Once the hfi_session_flush is issued by the vdec all queued
buffers to firmware should be returned to the v4l driver. Some
of those buffers are not processed at the time of flush command,
those buffers has filled len zero (no data). Catch that in
buffer_done callback and mark not filled capture buffers with
error state so that client can discard them.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: helpers: Done buffers per queue type

2020-05-05T11:04:59+00:00

Currently calling venus_helper_buffers_done() will return buffers to
user for both capture and output queues in the same call. This is
wrong because both queues are really separate and calling
stop_streaming on one queue shouldn't return buffers for the other.
Solve this by add a new queue type argument and fix the clients of
the helper function.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: core: Constify codec frequency data array

2020-05-05T11:04:01+00:00

The array is not changed in the code, so make it const.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: core: Fix mutex destroy in remove

2020-05-05T11:03:47+00:00

The hfi_destroy function is called too early in remove method. It
destroys a mutex which is used later in the .remove from pmruntime.
Solve the issue by moving hfi_destroy after last usage of the mutex.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: core: Add missing mutex destroy

2020-05-05T11:03:25+00:00

This adds missing mutex_destroy in remove method of venus core driver.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: core: remove CNOC voting while device suspend

2020-04-14T10:39:14+00:00

The Venus driver is voting Configuration NoC during .probe but not clear
voting in .suspend. Because of this NoC is up during shutdown also. As a
consequence the whole device could leak energy while in .suspend.

So correct this by moving voting in .resume and unvoting
in .suspend

Signed-off-by: Mansur Alisha Shaik 
Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab

media: venus: hfi_msgs.h: Replace zero-length array with flexible-array member

2020-04-14T10:38:57+00:00

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Stanimir Varbanov 
Signed-off-by: Mauro Carvalho Chehab