From: Boris Brezillon
The Rockchip VDEC supports VP9 profile 0 up to 4096x2304@30fps. Add
a backend for this new format.
Signed-off-by: Boris Brezillon
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/rkvdec/Makefile |2 +-
drivers/staging/media/rkvdec/rkvdec-vp9.c | 1577
/V4L2_VP9_PROFILE_MAX/
* Fix wrong kfree(ctx).
* constify a couple structs on rkvdec-vp9.c
*** BLURB HERE ***
Boris Brezillon (2):
media: uapi: Add VP9 stateless decoder controls
media: rkvdec: Add the VP9 backend
Ezequiel Garcia (1):
media: rkvdec: Fix .buf_prepare
.../userspace-api/media/v4l/biblio.rst
From: Boris Brezillon
Add the VP9 stateless decoder controls plus the documentation that goes
with it.
Signed-off-by: Boris Brezillon
Signed-off-by: Ezequiel Garcia
---
.../userspace-api/media/v4l/biblio.rst| 10 +
.../media/v4l/ext-ctrls-codec.rst | 550
On Wed, 13 May 2020 at 22:32, Xiongfeng Wang wrote:
>
> Hi Ezequiel,
>
> Thanks for your reply !
>
> On 2020/5/14 3:32, Ezequiel Garcia wrote:
> > On Mon, 11 May 2020 at 05:49, Xiongfeng Wang
> > wrote:
> >>
> >> When I cat module param
On Mon, 11 May 2020 at 05:49, Xiongfeng Wang wrote:
>
> When I cat module parameter 'dma_mode' by sysfs, it displays as follows.
> It is better to add a newline for easy reading.
>
> [root@hulk-202 ~]# cat /sys/module/tw686x/parameters/dma_mode
> memcpy[root@hulk-202 ~]#
>
> Signed-off-by:
On Fri, 2020-05-08 at 18:56 +0200, Tomasz Figa wrote:
> On Fri, May 8, 2020 at 6:26 PM Ezequiel Garcia wrote:
> > On Fri, 2020-05-08 at 12:34 +0200, Hans Verkuil wrote:
> > > On 05/05/2020 15:41, Ezequiel Garcia wrote:
> > > > From: Boris Brezillon
> > > &g
Hi Heiko,
On Fri, 2020-04-03 at 13:15 -0300, Helen Koike wrote:
> From: Shunqian Zheng
>
> Designware MIPI D-PHY, used for ISP0 in rk3399.
>
> Verified with:
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml
>
> Signed-off-by:
Hi Hans,
On Fri, 2020-04-17 at 09:18 +0200, Hans Verkuil wrote:
> On 03/04/2020 18:15, Helen Koike wrote:
> > The Rockchip ISP bindings was moved out of staging.
> > Update MAINTAINERS file with the new path.
>
> Shouldn't there be a reference to
>
On Fri, 2020-05-08 at 12:34 +0200, Hans Verkuil wrote:
> On 05/05/2020 15:41, Ezequiel Garcia wrote:
> > From: Boris Brezillon
> >
> > The Rockchip VDEC supports VP9 profile 0 up to 4096x2304@30fps. Add
> > a backend for this new format.
> >
> > Signed-
Hi Hans,
On Fri, 2020-05-08 at 12:27 +0200, Hans Verkuil wrote:
> On 05/05/2020 15:41, Ezequiel Garcia wrote:
> > From: Boris Brezillon
> >
> > Add the VP9 stateless decoder controls plus the documentation that goes
> > with it.
> >
> > Signed-
gic to only set the output CSC mode when the output is YUV and
> the input is RGB. Also add a comment to clarify the rationale.
>
> Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support")
> Signed-off-by: Paul Kocialkowski
Reviewed-by: Ezequiel Garcia
Thanks!
> ---
&g
de selection.
> The two nested tests for input colorspace are simplified into a single one,
> with a logical and, making the whole more readable.
>
> Signed-off-by: Paul Kocialkowski
Reviewed-by: Ezequiel Garcia
Thanks a lot for the nice cleanup.
> ---
> drivers/media/platf
Hello,
On Wed, 15 Apr 2020 at 10:33, Baolin Wang wrote:
>
> Hi Ezequiel,
>
> On Wed, Apr 15, 2020 at 6:09 AM Ezequiel Garcia
> wrote:
> >
> > Every hwspinlock driver is expected to depend on the
> > hwspinlock core, so it's possible to simplify the
> >
On Tue, 2020-05-05 at 16:05 +0200, Tomasz Figa wrote:
> On Tue, May 5, 2020 at 3:59 PM Ezequiel Garcia wrote:
> > On Tue, 2020-05-05 at 15:56 +0200, Tomasz Figa wrote:
> > > Hi Ezequiel,
> > >
> > > On Tue, May 5, 2020 at 3:41 PM Ezequiel Garcia
> > &
On Tue, 2020-05-05 at 15:56 +0200, Tomasz Figa wrote:
> Hi Ezequiel,
>
> On Tue, May 5, 2020 at 3:41 PM Ezequiel Garcia wrote:
> > The driver should only set the payload on .buf_prepare
> > if the buffer is CAPTURE type, or if an OUTPUT buffer
> > has a zeroed payload
From: Boris Brezillon
Add the VP9 stateless decoder controls plus the documentation that goes
with it.
Signed-off-by: Boris Brezillon
Signed-off-by: Ezequiel Garcia
---
.../userspace-api/media/v4l/biblio.rst| 10 +
.../media/v4l/ext-ctrls-codec.rst | 581
From: Boris Brezillon
The Rockchip VDEC supports VP9 profile 0 up to 4096x2304@30fps. Add
a backend for this new format.
Signed-off-by: Boris Brezillon
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/rkvdec/Makefile |2 +-
drivers/staging/media/rkvdec/rkvdec-vp9.c | 1577
style issues pointed out by Nicolas internally.
* s/VP9_PROFILE_MAX/V4L2_VP9_PROFILE_MAX/
* Fix wrong kfree(ctx).
* constify a couple structs on rkvdec-vp9.c
Boris Brezillon (2):
media: uapi: Add VP9 stateless decoder controls
media: rkvdec: Add the VP9 backend
Ezequiel Garcia (1):
media
The driver should only set the payload on .buf_prepare
if the buffer is CAPTURE type, or if an OUTPUT buffer
has a zeroed payload.
Fix it.
Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/rkvdec/rkvdec.c | 10 +++
o.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> index ed3f511f066f..16d82309e7b6 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -13,6 +13,8 @@
> * Marek Szyprowski,
> */
>
> +#include
> +
> #include
> #include
> #include
> @@ -450,12 +452,24 @@ static int cedrus_start_streaming(struct vb2_queue *vq,
> unsigned int count)
> return -EINVAL;
> }
>
> - if (V4L2_TYPE_IS_OUTPUT(vq->type) &&
> - dev->dec_ops[ctx->current_codec]->start)
> - ret = dev->dec_ops[ctx->current_codec]->start(ctx);
> + if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
> + ret = pm_runtime_get_sync(dev->dev);
It's entirely up to you, but you could do get_sync/put
between .device_run, as everything should happen
in the context of v4l2_m2m_ops.device_run.
(In that case, I believe you'd want to enable autosuspend.)
Not sure there's much to gain from an power consumption
pov, though.
With the Originally-by changed:
Reviewed-by: Ezequiel Garcia
Thanks,
Ezequiel
uot;)
> Suggested-by: Jernej Škrabec
> Suggested-by: Paul Kocialkowski
> Signed-off-by: Samuel Holland
Reviewed-by: Ezequiel Garcia
Thanks,
Ezequiel
> ---
>
> v2: added patch
>
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> drivers/staging/me
+Nicolas
On Sat, 2020-05-02 at 20:37 +0200, Boris Brezillon wrote:
> On Fri, 01 May 2020 13:57:49 -0300
> Ezequiel Garcia wrote:
>
> > > > +
> > > > +.. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}|
> > > > +
> > > > +.. flat-table:: en
Hi Hans,
Thanks a lot for your review, I'm preparing a new version.
On Thu, 2020-04-16 at 13:47 +0200, Hans Verkuil wrote:
> On 10/04/2020 13:51, Ezequiel Garcia wrote:
> > From: Boris Brezillon
> >
> > Add the VP9 stateless decoder controls plus the do
On Tue, 28 Apr 2020 at 09:47, Hillf Danton wrote:
>
>
> Sun, 26 Apr 2020 20:48:12 -0700
> > syzbot found the following crash on:
> >
> > HEAD commit:c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
> > git tree: upstream
> > console output:
On Friday, October 18, 2019 13:54 -03, Zhou Yanjie wrote:
>
> >
> > I also have a general question. Should we perhaps rename the driver
> > from jz4740_mmc.c to ingenic.c (and the file for the DT bindings, the
> > Kconfig, etc), as that seems like a more appropriate name? No?
>
> I am very
New iteration, seems that we are finally converging.
For this v5, we are only doing some changes on
the gamma_set implementation. As a result, the code
is more readable. See the changelog in patch 2 for more
information.
Thanks!
Ezequiel Garcia (3):
dt-bindings: display: rockchip: document
, and the latter
is supported by a different driver. This prevents the DRM driver
from requesting an entire register space.
The current implementation works for RGB 10-bit tables, as that
is what seems to work on RK3288.
Signed-off-by: Ezequiel Garcia
---
Changes from v4:
* Cleaned-up gamma_set implementation
it
by using the same condition everywhere, which matches the profiles
that support motion vectors.
Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Francois Buergisser
Signed-off-by: Ezequiel Garcia
---
v2:
* New patch.
drivers/staging/me
and for decoder conformance checking.
"""
As a side note, this change matches various vendors downstream codebases,
including ChromiumOS and IMX VPU libraries.
Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Francois Buergisser
Signe
From: Jonas Karlman
TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels,
change frmsize max_width/max_height to match TRM.
Fixes: 760327930e10 ("media: hantro: Enable H264 decoding on rk3288")
Signed-off-by: Jonas Karlman
---
v2:
* No changes.
53 ("media: rockchip/vpu: Prepare things to support decoders")
Signed-off-by: Ezequiel Garcia
--
v2:
* Call try_fmt_out before using the format,
pointed out by Philipp.
drivers/staging/media/hantro/hantro_v4l2.c | 28 +++---
1 file changed, 19 insertions(+), 9 dele
for interlaced content.
The fix can be applied independently so I'm including it
here.
Patches 3 and 4 correspond to fixes found by Francois Buergisser
while doing some tests on ChromeOS.
Ezequiel Garcia (1):
media: hantro: Fix s_fmt for dynamic resolution changes
Francois Buergisser (2):
media: hantro
On Thu, 2019-10-03 at 19:39 +, Jonas Karlman wrote:
> On 2019-10-03 21:08, Ezequiel Garcia wrote:
> > The MPEG-2 decoder register macros can be re-used from hantro_g1_regs.h,
> > and the re-definitions removed.
>
> I am not a very big fan of this change as it makes i
The MPEG-2 decoder register macros can be re-used from hantro_g1_regs.h,
and the re-definitions removed.
Signed-off-by: Ezequiel Garcia
---
.../media/hantro/hantro_g1_mpeg2_dec.c| 186 ++
drivers/staging/media/hantro/hantro_g1_regs.h | 58 +++---
2 files changed, 96
Format negotation helpers, hantro_find_format()
and hantro_get_default_fmt() can be simplified,
making the code a little bit clearer.
More importantly, this change is preparation work
for the post-processor usage.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_v4l2.c
color conversion via post-processing,
which means the driver now exposes YUV packed, in addition to NV12.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/Makefile | 1 +
drivers/staging/media/hantro/hantro.h | 84 ++-
drivers/staging/media/hantro
, maintaining an immutable
topology, and now exposing the subdevices to userspace.
Suggested-by: Helen Koike
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro.h | 21 +-
drivers/staging/media/hantro/hantro_drv.c | 250 +++--
drivers/staging/media/hantro
ay controllers support YUV.
* The post-processor implementation still supports RK3288
only. However, a generic register infrastructure is introduced
to make addition of other variants such as RK3399 really easy.
Ezequiel Garcia (4):
media: hantro: Cleanup format negotiation helpers
+Doug, Heiko:
On Fri, 2019-09-06 at 15:54 +0200, Jacopo Mondi wrote:
> Update CMM settings at in the atomic commit tail helper method.
> The CMM is updated with new gamma values provided to the driver
> in the GAMMA_LUT blob property.
>
> When resuming from system suspend, the DU driver is
Hi Zhou,
Thanks for your interest in this driver, I'm glad
so see it's more used.
On Thu, 2019-09-05 at 15:38 +0800, Zhou Yanjie wrote:
> Adjust the macro definition name to match the corresponding
> register name in the datasheet.
>
It's not really an issue to have slighlt different
names on
A few more comments...
On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
> A decoded 8-bit 4:2:0 frame need memory for up to 448 macroblocks
> and is laid out in memory as follow:
>
> +---+
> > Y-plane 256 MBs |
> +---+
> > UV-plane 128 MBs |
>
Hi Jonas,
Thanks for fixing this, I'm happy we are reducing the amount
of black magic here.
On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
> A decoded 8-bit 4:2:0 frame need memory for up to 448 macroblocks
> and is laid out in memory as follow:
>
> +---+
> > Y-plane
Hi Jonas,
Thanks for your patch.
On Mon, 2019-09-02 at 16:18 +, Jonas Karlman wrote:
[..]
>
> > > diff --git a/drivers/staging/media/hantro/hantro_h264.c
> > > b/drivers/staging/media/hantro/hantro_h264.c
> > > index 0d758e0c0f99..e2d01145ac4f 100644
> > > ---
On Wed, 2019-09-04 at 15:28 +0200, Philipp Zabel wrote:
> On Wed, 2019-09-04 at 10:01 -0300, Ezequiel Garcia wrote:
> > On Wed, 2019-09-04 at 12:13 +0200, Philipp Zabel wrote:
> > > Hi Ezequiel,
> > >
> > > On Tue, 2019-09-03 at 14:12 -0300, Ezequiel Garcia
Hello Jonas,
Thank you for the patch.
On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
> TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels,
> change frmsize max_width/max_height to match TRM.
>
The RK3288 TRM v1.1 (2015-8-20) I have here mentions a maximum
of
On Wed, 2019-09-04 at 12:13 +0200, Philipp Zabel wrote:
> Hi Ezequiel,
>
> On Tue, 2019-09-03 at 14:12 -0300, Ezequiel Garcia wrote:
> > Commit 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support
> > decoders")
> > changed the conditions under S_F
53 ("media: rockchip/vpu: Prepare things to support decoders")
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_v4l2.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c
b/drivers/
Hi Jonas,
Thanks for the series, I'll be reviewing this shortly.
On Sun, 2019-09-01 at 12:42 +, Jonas Karlman wrote:
> This series contains fixes and improvements for the hantro H264 decoder.
>
> Patch 1-6 fixes issues and limitations observed when preparing support
> for field encoded
On Thu, 2019-08-22 at 15:47 +0200, Hans Verkuil wrote:
> On 8/22/19 1:54 PM, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Mon 19 Aug 19, 17:53, Hans Verkuil wrote:
> > > On 8/19/19 2:41 PM, Paul Kocialkowski wrote:
> > > > Hi,
> > > >
On Mon, 2019-08-19 at 14:41 +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Fri 16 Aug 19, 13:01, Ezequiel Garcia wrote:
> > The V4L2_PIX_FMT_H264_SLICE_RAW name was originally suggested
> > because the pixel format would represent H264 slices without any
> > start co
From: Hertz Wong
Add helpers and patch hantro_{drv,v4l2}.c to prepare addition of H264
decoding support.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
Tested-by: Philipp Zabel
---
Changes in v7:
* Comment on the source of the CABAC constant table.
* Remove unneeded menu_skip_mask.
From: Hertz Wong
Now that the generic bits have been added, we can activate H264 decoding
on rk3288.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
---
Changes in v7:
* None.
Changes in v6:
* None.
Changes in v5:
* None.
Changes in v4:
* None.
---
From: Hertz Wong
Add the G1 specific bits to support H264 decoding.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
Tested-by: Philipp Zabel
---
Changes from v7:
* None.
Changes from v6:
* None.
Changes from v5:
* None.
Changes from v4:
* Update to use pic_size from the H264 private
From: Boris Brezillon
Some decoders use intra slice/frame references. The capture buffer
pointed by these references might be new and thus have invalid
timestamp which prevents the decoder logic from retrieving the
vb2_buffer object based on the output buf timestamp.
Copy all metadata (including
} decoding/{slice,frame}-based decoding/
* Add Paul's R-b
Changes in v2:
* Allow decoding multiple slices in per-slice decoding mode
* Minor doc improvement/fixes
doc api ext-ctrls-codec
Signed-off-by: Ezequiel Garcia
---
.../media/uapi/v4l/ext-ctrls-codec.rst| 57
that this is independent of the H264 decoding mode,
which specifies the granularity of the decoding operations.
Either in frame-based or slice-based mode, this new control
will allow to define the start code expected on H264 slices.
Signed-off-by: Ezequiel Garcia
Tested-by: Philipp Zabel
---
Changes in v7
From: Boris Brezillon
Those lists can be extracted from the dpb, let's simplify userspace
life and build that list kernel-side (generic helpers will be provided
for drivers that need this list).
Signed-off-by: Boris Brezillon
Reviewed-by: Nicolas Dufresne
Reviewed-by: Ezequiel Garcia
In order to introduce other controls, the control initialization
needs to support an initial struct v4l2_ctrl_control.
While here, let's cleanup the control initialization,
removing unneeded fields.
Signed-off-by: Ezequiel Garcia
---
Changes in v7:
* None.
Changes in v6:
* None.
Changes in v5
for
backwards compatibility.
Signed-off-by: Ezequiel Garcia
---
Changes in v7:
* None.
Changes in v6:
* Remove incorrect menu_skip_mask.
Changes in v6:
* Adjust to control renames.
Changes in v5:
* Clarify commit log.
Changes in v4:
* New patch.
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 18
Brezillon (3):
media: uapi: h264: Add the concept of decoding mode
media: uapi: h264: Get rid of the p0/b0/b1 ref-lists
media: hantro: Move copy_metadata() before doing a decode operation
Ezequiel Garcia (4):
media: uapi: h264: Rename pixel format
media: uapi: h264: Add the concept
-by: Ezequiel Garcia
Tested-by: Philipp Zabel
---
Changes in v7:
* None.
Changes in v6:
* None.
Changes in v5:
* None.
Changes in v4:
* New patch.
---
Documentation/media/uapi/v4l/pixfmt-compressed.rst | 4 ++--
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
drivers/staging/media
From: Rasmus Villemoes
Our list_sort() utility has always supported a context argument that
is passed through to the comparison routine. Now there's a use case
for the similar thing for sort().
This implements sort_r by simply extending the existing sort function
in the obvious way. To avoid
On Fri, 2019-08-16 at 09:41 +0200, Hans Verkuil wrote:
> On 8/14/19 9:59 PM, Ezequiel Garcia wrote:
> > From: Hertz Wong
> >
> > Add helpers and patch hantro_{drv,v4l2}.c to prepare addition of H264
> > decoding support.
> >
> > Signed-off-by: Hertz W
On Fri, 2019-08-16 at 09:38 +0200, Hans Verkuil wrote:
> On 8/14/19 9:59 PM, Ezequiel Garcia wrote:
> > The cedrus VPU is slice-based and expects V4L2_PIX_FMT_H264_SLICE
> > buffers to contain H264 slices with no start code.
> >
> > Expose this to userspace with t
On Fri, 2019-08-16 at 09:34 +0200, Hans Verkuil wrote:
> On 8/14/19 9:59 PM, Ezequiel Garcia wrote:
> > From: Boris Brezillon
> >
> > Some stateless decoders don't support per-slice decoding granularity
> > (or at least not in a way that would make them efficient or ea
From: Rasmus Villemoes
Our list_sort() utility has always supported a context argument that
is passed through to the comparison routine. Now there's a use case
for the similar thing for sort().
This implements sort_r by simply extending the existing sort function
in the obvious way. To avoid
From: Boris Brezillon
Those lists can be extracted from the dpb, let's simplify userspace
life and build that list kernel-side (generic helpers will be provided
for drivers that need this list).
Signed-off-by: Boris Brezillon
Reviewed-by: Nicolas Dufresne
Reviewed-by: Ezequiel Garcia
From: Hertz Wong
Now that the generic bits have been added, we can activate H264 decoding
on rk3288.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
---
Changes in v6:
* None.
Changes in v5:
* None.
Changes in v4:
* None.
---
drivers/staging/media/hantro/rk3288_vpu_hw.c | 21
From: Hertz Wong
Add the G1 specific bits to support H264 decoding.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
Tested-by: Philipp Zabel
---
Changes from v6:
* None.
Changes from v5:
* None.
Changes from v4:
* Update to use pic_size from the H264 private context struct.
* Remove
From: Hertz Wong
Add helpers and patch hantro_{drv,v4l2}.c to prepare addition of H264
decoding support.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
Tested-by: Philipp Zabel
---
Changes in v6:
* Fixed duplicated CABAC table memcpy.
* Adjust to renamed controls.
Changes in v5:
*
From: Boris Brezillon
Some decoders use intra slice/frame references. The capture buffer
pointed by these references might be new and thus have invalid
timestamp which prevents the decoder logic from retrieving the
vb2_buffer object based on the output buf timestamp.
Copy all metadata (including
for
backwards compatibility.
Signed-off-by: Ezequiel Garcia
---
Changes in v6:
* Adjust to control renames.
Changes in v5:
* Clarify commit log.
Changes in v4:
* New patch.
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 20
1 file changed, 20 insertions(+)
diff --git
that this is independent of the H264 decoding mode,
which specifies the granularity of the decoding operations.
Either in frame-based or slice-based mode, this new control
will allow to define the start code expected on H264 slices.
Signed-off-by: Ezequiel Garcia
Tested-by: Philipp Zabel
---
Changes in v6
-by: Ezequiel Garcia
Tested-by: Philipp Zabel
---
Changes in v6:
* None.
Changes in v5:
* None.
Changes in v4:
* New patch.
---
Documentation/media/uapi/v4l/pixfmt-compressed.rst | 4 ++--
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus_dec.c
In order to introduce other controls, the control initialization
needs to support an initial struct v4l2_ctrl_control.
While here, let's cleanup the control initialization,
removing unneeded fields.
Signed-off-by: Ezequiel Garcia
---
Changes in v6:
* None.
Changes in v5:
* None.
Changes in v4
From: Boris Brezillon
Some stateless decoders don't support per-slice decoding granularity
(or at least not in a way that would make them efficient or easy to use).
Expose a menu to control the supported decoding modes. Drivers are
allowed to support only one decoding but they can support both
: h264: Get rid of the p0/b0/b1 ref-lists
media: hantro: Move copy_metadata() before doing a decode operation
Ezequiel Garcia (4):
media: uapi: h264: Rename pixel format
media: uapi: h264: Add the concept of start code
media: cedrus: Cleanup control initialization
media: cedrus: Specify H264
On Wed, 2019-08-14 at 13:49 +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Wed 14 Aug 19, 10:11, Hans Verkuil wrote:
> > On 8/12/19 9:35 PM, Ezequiel Garcia wrote:
> > > Stateless decoders have different expectations about the
> > > start code that is prepended
On Wed, 2019-08-14 at 14:23 +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Mon 12 Aug 19, 16:35, Ezequiel Garcia wrote:
> > From: Boris Brezillon
> >
> > Some stateless decoders don't support per-slice decoding granularity
> > (or at least not in a way that
for
backwards compatibility.
Signed-off-by: Ezequiel Garcia
---
Changes in v5:
* Clarify commit log.
Changes in v4:
* New patch.
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b
From: Boris Brezillon
Some decoders use intra slice/frame references. The capture buffer
pointed by these references might be new and thus have invalid
timestamp which prevents the decoder logic from retrieving the
vb2_buffer object based on the output buf timestamp.
Copy all metadata (including
From: Hertz Wong
Add the G1 specific bits to support H264 decoding.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
Tested-by: Philipp Zabel
---
Changes from v5:
* None.
Changes from v4:
* Update to use pic_size from the H264 private context struct.
* Remove unused variable.
---
From: Hertz Wong
Now that the generic bits have been added, we can activate H264 decoding
on rk3288.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
---
Changes in v5:
* None.
Changes in v4:
* None.
---
drivers/staging/media/hantro/rk3288_vpu_hw.c | 21 +++-
1 file
From: Hertz Wong
Add helpers and patch hantro_{drv,v4l2}.c to prepare addition of H264
decoding support.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
Tested-by: Philipp Zabel
---
Changes in v5:
* None.
Changes in v4:
* Rework extra_size0, exposing the size via TRY_FMT/S_FMT
to
In order to introduce other controls, the control initialization
needs to support an initial struct v4l2_ctrl_control.
While here, let's cleanup the control initialization,
removing unneeded fields.
Signed-off-by: Ezequiel Garcia
---
Changes in v5:
* None.
Changes in v4:
* New patch
From: Boris Brezillon
Those lists can be extracted from the dpb, let's simplify userspace
life and build that list kernel-side (generic helpers will be provided
for drivers that need this list).
Signed-off-by: Boris Brezillon
Reviewed-by: Nicolas Dufresne
Reviewed-by: Ezequiel Garcia
that this is independent of the H264 decoding mode,
which specifies the granularity of the decoding operations.
Either in frame-based or slice-based mode, this new control
will allow to define the start code expected on H264 slices.
Signed-off-by: Ezequiel Garcia
Tested-by: Philipp Zabel
---
Changes in v5
From: Boris Brezillon
Some stateless decoders don't support per-slice decoding granularity
(or at least not in a way that would make them efficient or easy to use).
Expose a menu to control the supported decoding modes. Drivers are
allowed to support only one decoding but they can support both
]
https://gitlab.collabora.com/ezequiel/ffmpeg/tree/stateless-mpeg2-vp8-h264-v4
Boris Brezillon (3):
media: uapi: h264: Add the concept of decoding mode
media: uapi: h264: Get rid of the p0/b0/b1 ref-lists
media: hantro: Move copy_metadata() before doing a decode operation
Ezequiel Garcia (4
-by: Ezequiel Garcia
Tested-by: Philipp Zabel
---
Changes in v5:
* None.
Changes in v4:
* New patch.
---
Documentation/media/uapi/v4l/pixfmt-compressed.rst | 4 ++--
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus_dec.c| 2 +-
drivers
From: Rasmus Villemoes
Our list_sort() utility has always supported a context argument that
is passed through to the comparison routine. Now there's a use case
for the similar thing for sort().
This implements sort_r by simply extending the existing sort function
in the obvious way. To avoid
On Mon, 2019-08-12 at 12:41 +0200, Philipp Zabel wrote:
> Hi Ezequiel,
>
> On Thu, 2019-08-08 at 07:34 -0300, Ezequiel Garcia wrote:
> > This series is consolidating the two recent H264 series submitted
> > by Boris [1] [2]. Given some patches from [2] have been merged
_write_ref_list(struct cedrus_ctx *ctx,
> if (buf_idx < 0)
> continue;
>
> - ref_buf = to_vb2_v4l2_buffer(ctx->dst_bufs[buf_idx]);
> + ref_buf = to_vb2_v4l2_buffer(cap_q->bufs[buf_idx]);
Ditto about vb2_get_buffer.
With those changes:
Reviewed-by: Ezequiel Garcia
Thanks,
Ezequiel
Hi Jernej,
On Mon, 2019-06-03 at 13:38 +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, May 30, 2019 at 11:15:10PM +0200, Jernej Skrabec wrote:
> > libvdpau-sunxi always disables engine after each decoded slice.
> > Do same in Cedrus driver.
> >
> > Presumably this also lowers power consumption
On Mon, 2019-08-12 at 12:19 +0200, Hans Verkuil wrote:
> On 8/8/19 12:34 PM, Ezequiel Garcia wrote:
> > From: Boris Brezillon
> >
> > Some stateless decoders don't support per-slice decoding granularity
> > (or at least not in a way that would make them efficient or ea
On Mon, 2019-08-12 at 12:11 +0200, Hans Verkuil wrote:
> On 8/8/19 12:34 PM, Ezequiel Garcia wrote:
> > Stateless decoders have different expectations about the
> > start code that is prepended on H264 slices. Add a
> > menu control to express the supported start code types
&g
On Mon, 2019-08-12 at 12:20 +0200, Hans Verkuil wrote:
> On 8/8/19 12:34 PM, Ezequiel Garcia wrote:
> > From: Boris Brezillon
> >
> > Those lists can be extracted from the dpb, let's simplify userspace
> > life and build that list kernel-side (generic helpers will
The cedrus VPU expects V4L2_PIX_FMT_H264_SLICE buffers to contain
H264 slices with no start code. Expose this to userspace with
the newly added menu control.
Signed-off-by: Ezequiel Garcia
---
Changes in v4:
* New patch.
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 20
From: Hertz Wong
Add the G1 specific bits to support H264 decoding.
Signed-off-by: Hertz Wong
Signed-off-by: Boris Brezillon
---
Changes from v4:
* Update to use pic_size from the H264 private context struct.
* Remove unused variable.
---
drivers/staging/media/hantro/Makefile | 1 +
In order to introduce other controls, the control initialization
needs to support an initial struct v4l2_ctrl_control.
While here, let's cleanup the control initialization,
removing unneeded fields.
Signed-off-by: Ezequiel Garcia
---
Changes in v4:
* New patch.
---
drivers/staging/media/sunxi
401 - 500 of 1882 matches
Mail list logo
