linux.git/drivers/staging/media, branch v5.5

media: intel-ipu3: Align struct ipu3_uapi_awb_fr_config_s to 32 bytes

2020-01-03T14:02:59+00:00

A struct that needs to be aligned to 32 bytes has a size of 28. Increase
the size to 32.

This makes elements of arrays of this struct aligned to 32 as well, and
other structs where members are aligned to 32 mixing
ipu3_uapi_awb_fr_config_s as well as other types.

Fixes: commit dca5ef2aa1e6 ("media: staging/intel-ipu3: remove the unnecessary compiler flags")
Signed-off-by: Sakari Ailus 
Tested-by: Bingbu Cao 
Signed-off-by: Mauro Carvalho Chehab

media: hantro: Set H264 FIELDPIC_FLAG_E flag correctly

2019-11-10T17:00:08+00:00

The FIELDPIC_FLAG_E bit should be set when field_pic_flag exists in stream,
it is currently set based on field_pic_flag of current frame.
The PIC_FIELDMODE_E bit is correctly set based on the field_pic_flag.

Fix this by setting the FIELDPIC_FLAG_E bit when frame_mbs_only is not set.

Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Jonas Karlman 
Reviewed-by: Boris Brezillon 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: hantro: Remove now unused H264 pic_size

2019-11-10T16:59:28+00:00

pic_size in hantro_h264_dec_hw_ctx struct is no longer used,
lets remove it.

Signed-off-by: Jonas Karlman 
Reviewed-by: Boris Brezillon 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: hantro: Use output buffer width and height for H264 decoding

2019-11-10T16:58:45+00:00

Calculations for motion vector buffer offset is based on width and height
from the configured output format, lets use the same values for macroblock
width and height hw regs.

Signed-off-by: Jonas Karlman 
Reviewed-by: Boris Brezillon 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: hantro: Reduce H264 extra space for motion vectors

2019-11-10T16:57:46+00:00

A decoded 8-bit 4:2:0 frame need memory for up to 448 bytes per
macroblock with additional 32 bytes on multi-core variants.

Memory layout is as follow:

+---------------------------+
| Y-plane   256 bytes x MBs |
+---------------------------+
| UV-plane  128 bytes x MBs |
+---------------------------+
| MV buffer  64 bytes x MBs |
+---------------------------+
| MC sync          32 bytes |
+---------------------------+

Reduce the extra space allocated now that motion vector buffer offset no
longer is based on the extra space.

Only allocate extra space for 64 bytes x MBs of motion vector buffer
and 32 bytes for multi-core sync.

Fixes: a9471e25629b ("media: hantro: Add core bits to support H264 decoding")
Signed-off-by: Jonas Karlman 
Reviewed-by: Boris Brezillon 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: hantro: Fix H264 motion vector buffer offset

2019-11-10T16:57:00+00:00

A decoded 8-bit 4:2:0 frame need memory for up to 448 bytes per
macroblock and is laid out in memory as follow:

+---------------------------+
| Y-plane   256 bytes x MBs |
+---------------------------+
| UV-plane  128 bytes x MBs |
+---------------------------+
| MV buffer  64 bytes x MBs |
+---------------------------+

The motion vector buffer offset is currently correct for 4:2:0 because
the extra space for motion vectors is overallocated with an extra
64 bytes x MBs.

Wrong offset for both destination and motion vector buffer are used
for the bottom field of field encoded content, wrong offset is
also used for 4:0:0 (monochrome) content.

Fix this by setting the motion vector address to the expected 384 bytes
x MBs offset for 4:2:0 and 256 bytes x MBs offset for 4:0:0 content.

Also use correct destination and motion vector buffer offset
for the bottom field of field encoded content.

While at it also extend the check for 4:0:0 (monochrome) to include an
additional check for High Profile (100).

Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Jonas Karlman 
Reviewed-by: Boris Brezillon 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: hantro: Fix s_fmt for dynamic resolution changes

2019-11-10T16:48:56+00:00

Commit 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
changed the conditions under S_FMT was allowed for OUTPUT
CAPTURE buffers.

However, and according to the mem-to-mem stateless decoder specification,
in order to support dynamic resolution changes, S_FMT should be allowed
even if OUTPUT buffers have been allocated.

Relax decoder S_FMT restrictions on OUTPUT buffers, allowing a
resolution modification, provided the pixel format stays the same.

Tested on RK3288 platforms using ChromiumOS Video Decode/Encode
Accelerator Unittests.

[hverkuil: fix typo: In other -> In order]

Fixes: 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
Signed-off-by: Ezequiel Garcia 
Reviewed-by: Boris Brezillon 
Cc:       # for v5.4 and up
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cedrus: Increase maximum supported size

2019-11-10T06:44:10+00:00

There are few variations of 4k resolutions. The biggest one is
4096x2304 which is also supported by HW. It has also nice property that
both width and size are divisible by maximum HEVC CTB size, which is 64.

Signed-off-by: Jernej Skrabec 
Acked-by: Paul Kocialkowski 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cedrus: Fix H264 4k support

2019-11-10T06:43:41+00:00

H264 decoder needs additional or bigger buffers in order to decode 4k
videos.

Signed-off-by: Jernej Skrabec 
Acked-by: Paul Kocialkowski 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cedrus: Properly signal size in mode register

2019-11-10T06:30:01+00:00

Mode register also holds information if video width is bigger than 2048
and if it is equal to 4096.

Rework cedrus_engine_enable() to properly signal this properties.

Signed-off-by: Jernej Skrabec 
Acked-by: Paul Kocialkowski 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab