Hi Tomasz,
On Tue, 2020-08-04 at 15:35 +0200, Tomasz Figa wrote:
> On Mon, Jul 27, 2020 at 9:43 PM Nicolas Dufresne
> wrote:
> > Le lundi 27 juillet 2020 à 20:10 +0200, Tomasz Figa a écrit :
> > > On Mon, Jul 27, 2020 at 6:18 PM Ezequiel Garcia
> > > wrote:
>
Hello Santiago,
Nice work and welcome to the kernel community.
On Sun, 2020-08-02 at 23:09 -0300, Santiago Hormazabal wrote:
> media: adds support for kt0913 FM/AM tuner chip
>
I don't think this line above should be there.
Also, this seems to be v2. You are missing a "PATCH v2" prefix
on the
Hi Jonas,
On Mon, 2020-07-27 at 23:39 +, Jonas Karlman wrote:
> Hi,
>
> On 2020-07-24 21:08, Ezequiel Garcia wrote:
> > Hello Jonas,
> >
> > On Wed, 2020-07-22 at 21:52 +, Jonas Karlman wrote:
> > > On 2020-07-15 22:22, Ezequiel Garcia wrote:
> &
On Mon, 2020-07-27 at 16:52 +0200, Tomasz Figa wrote:
> On Mon, Jul 27, 2020 at 4:39 PM Ezequiel Garcia
> wrote:
> > Hi Alexandre,
> >
> > Thanks a lot for the review.
> >
> > On Sat, 2020-07-25 at 23:34 +0900, Alexandre Courbot wrote:
> > > On
Hi Alexandre,
Despite you've asked to ignore this review,
let me comment on it.
On Sat, 2020-07-25 at 23:45 +0900, Alexandre Courbot wrote:
> On Thu, Jul 16, 2020 at 5:23 AM Ezequiel Garcia
> wrote:
> > Now that slice invariant parameters have been moved,
> > the driv
Hi Alexandre,
Thanks a lot for the review.
On Sat, 2020-07-25 at 23:34 +0900, Alexandre Courbot wrote:
> On Thu, Jul 16, 2020 at 5:23 AM Ezequiel Garcia
> wrote:
> > The H.264 specification requires in its "Slice header semantics"
> > section that the following val
On Mon, 27 Jul 2020 at 06:06, Alexandre Courbot wrote:
>
> On Thu, Jul 23, 2020 at 6:23 AM Ezequiel Garcia
> wrote:
> >
> > On Mon, 13 Jul 2020 at 03:09, Alexandre Courbot
> > wrote:
> > >
> > > From: Yunfei Dong
> > >
> > > MT81
On Mon, 27 Jul 2020 at 11:24, Ezequiel Garcia
wrote:
>
> On Mon, 27 Jul 2020 at 06:06, Alexandre Courbot wrote:
> >
> > On Thu, Jul 23, 2020 at 6:23 AM Ezequiel Garcia
> > wrote:
> > >
> > > On Mon, 13 Jul 2020 at 03:09, Alexandre Courbot
>
On Mon, 27 Jul 2020 at 06:06, Alexandre Courbot wrote:
>
> On Thu, Jul 23, 2020 at 6:37 AM Ezequiel Garcia
> wrote:
> >
> > On Mon, 13 Jul 2020 at 03:09, Alexandre Courbot
> > wrote:
> > >
> > > The mediatek codecs can use either the VPU or the SCP
On Mon, 27 Jul 2020 at 06:06, Alexandre Courbot wrote:
>
> On Thu, Jul 23, 2020 at 6:40 AM Ezequiel Garcia
> wrote:
> >
> > On Mon, 13 Jul 2020 at 03:09, Alexandre Courbot
> > wrote:
> > >
> > > From: Yunfei Dong
> > >
> >
.
On Mon, 27 Jul 2020 at 06:06, Alexandre Courbot wrote:
>
> On Sat, Jul 25, 2020 at 6:13 AM Ezequiel Garcia
> wrote:
> >
> > Hi Alexandre,
> >
> > I'm slowly making progress on the series. Here's some more comments.
> >
> > On Mon, 13 Jul
On Sun, 26 Jul 2020 at 16:16, Jernej Škrabec wrote:
>
> Hi Ezequiel!
>
> Dne sobota, 25. julij 2020 ob 15:08:37 CEST je Ezequiel Garcia napisal(a):
> > Hi Jernej,
> >
> > As you know, I'm not familiar with this hardware,
> > but I've tried to take a detai
+Enric
Hello Alexandre,
Thanks for the series.
On Wed, 20 May 2020 at 05:27, Alexandre Courbot wrote:
>
> This series adds support for the encoder present on MT8183. It is very similar
> to the one in MT8173, but with different capabilities and using a new firmware
> interface (SCP, while
Hi Alexandre,
Last review on my side, this series looks mostly good.
On Mon, 13 Jul 2020 at 03:09, Alexandre Courbot wrote:
>
> Different chips have different supported bitrate ranges. Move the list
s/bitrate ranges/formats
> of supported formats to the platform data, and split the output and
Hi Jernej,
As you know, I'm not familiar with this hardware,
but I've tried to take a detailed look anyway.
The driver looks mostly good to me, I just have
some minor comments.
More importantly, seems the current uAPI
control is supporting this platform nicely,
which gives us some confidence to
Hi Alexandre,
I'm slowly making progress on the series. Here's some more comments.
On Mon, 13 Jul 2020 at 03:10, Alexandre Courbot wrote:
>
> From: Yunfei Dong
>
> Support the new extended firmware used by MT8183's encoder.
>
If you could add some more information about the MT8183 encoder
and
Hello Jonas,
On Wed, 2020-07-22 at 21:52 +, Jonas Karlman wrote:
> On 2020-07-15 22:22, Ezequiel Garcia wrote:
> > As discussed recently, the current interface for the
> > Decoded Picture Buffer is not enough to properly
> > support field coding.
> >
> &
On Mon, 13 Jul 2020 at 03:09, Alexandre Courbot wrote:
>
> From: Yunfei Dong
>
> Add support for communicating with the SCP firmware, which will be used
> by MT8183.
>
> Signed-off-by: Yunfei Dong
> [acourbot: refactor, cleanup and split]
> Co-developed-by: Alexandre Courbot
> Signed-off-by:
On Mon, 13 Jul 2020 at 03:09, Alexandre Courbot wrote:
>
> The mediatek codecs can use either the VPU or the SCP as their interface
> to firmware. Reflect this in the DT bindings.
>
> Signed-off-by: Alexandre Courbot
> Acked-by: Tiffany Lin
> ---
>
On Mon, 13 Jul 2020 at 03:09, Alexandre Courbot wrote:
>
> From: Yunfei Dong
>
> MT8183's codec firwmare is run by a different remote processor from
> MT8173. While the firmware interface is basically the same, the way to
> invoke it differs. Abstract all firmware calls under a layer that will
>
On Wed, 2020-07-22 at 18:09 +0200, Jernej Škrabec wrote:
> Hi!
>
> Dne sreda, 15. julij 2020 ob 22:22:29 CEST je Ezequiel Garcia napisal(a):
> > As discussed recently, the current interface for the
> > Decoded Picture Buffer is not enough to properly
> > support field c
On Thu, 2020-07-16 at 09:23 +0200, Hans Verkuil wrote:
> On 15/07/2020 22:22, Ezequiel Garcia wrote:
> > Commit 0b0393d59eb4a ("media: uapi: h264: clarify
> > expected scaling_list_4x4/8x8 order") improved the
> > documentation on H264 scaling lists order
On Thu, 2020-07-16 at 09:26 +0200, Hans Verkuil wrote:
> On 15/07/2020 22:22, Ezequiel Garcia wrote:
> > The prediction weight parameters are only required under
> > certain conditions, which depend on slice header parameters.
> >
> > The slice header syntax sp
Now that slice invariant parameters have been moved,
the driver no longer needs this control, so drop it.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 4
drivers/staging/media/rkvdec/rkvdec.c | 5 -
2 files changed, 9 deletions(-)
diff --git
x elements dec_ref_pic_marking() and those related
to pic order count, remain invariant as well, and therefore,
the fields dec_ref_pic_marking_bit_size and pic_order_cnt_bit_size
are also common to all slices.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Nicolas Dufresne
---
.../media/v4l/ext-ctrls
Now that slice invariant parameters have been moved,
the driver no longer needs this control, so drop it.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_drv.c | 5 -
drivers/staging/media/hantro/hantro_h264.c | 5 -
drivers/staging/media/hantro/hantro_hw.h | 2
to be padded to avoid a hole,
which might be also useful to allow future uAPI extensions.
Signed-off-by: Ezequiel Garcia
---
.../userspace-api/media/v4l/ext-ctrls-codec.rst | 5 -
drivers/media/v4l2-core/v4l2-ctrls.c| 13 +
include/media/h264-ctrls.h
.
I'm adding here the change from Jernej, and a change from
Philipp Zabel which apparently fell thru the cracks.
Ezequiel Garcia (8):
media: uapi: h264: Further clarify scaling lists order
media: uapi: h264: Split prediction weight parameters
media: uapi: h264: Increase size
As discussed recently, the current interface for the
Decoded Picture Buffer is not enough to properly
support field coding.
This commit introduces enough semantics to support
frame and field coding, and to signal how DPB entries
are "used for reference".
Signed-off-by: Ezequ
-by: Philipp Zabel
[Ezequiel: rebase]
Signed-off-by: Ezequiel Garcia
Reviewed-by: Nicolas Dufresne
---
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b
Commit 0b0393d59eb4a ("media: uapi: h264: clarify
expected scaling_list_4x4/8x8 order") improved the
documentation on H264 scaling lists order.
This commit improves the documentation by clarifying
that the lists themselves are expected in matrix order.
Signed-off-by: Ezequ
the H264 specification, 'first_mb_in_slice' can be up to
PicSizeInMbs - 1, so increase the size of the field to 32-bits.
Note that v4l2_ctrl_h264_slice_params struct will be modified
in a follow-up commit, and so we defer its 64-bit padding.
Signed-off-by: Ezequiel Garcia
---
Documentation
h264_pred_weight
is 772 bytes.
Signed-off-by: Ezequiel Garcia
---
.../userspace-api/media/v4l/ext-ctrls-codec.rst| 14 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 6 ++
drivers/staging/media/sunxi/cedrus/cedrus.h| 1 +
drivers/staging/media/sunxi/cedrus/cedr
Dufresne
[Ezequiel: Use a macro for the reference picture list length]
Signed-off-by: Ezequiel Garcia
---
.../media/v4l/ext-ctrls-codec.rst | 40 ++-
.../staging/media/sunxi/cedrus/cedrus_h264.c | 6 +--
include/media/h264-ctrls.h| 20 +++---
3 files
Nicolas Dufresne
This looks correct.
Reviewed-by: Ezequiel Garcia
Thanks,
Ezequiel
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_vi
On Sat, 2020-07-11 at 10:21 +, Jonas Karlman wrote:
> On 2020-07-10 23:49, Nicolas Dufresne wrote:
> > Le vendredi 10 juillet 2020 à 09:25 -0300, Ezequiel Garcia a écrit :
> > > +Nicolas
> > >
> > > On Fri, 2020-07-10 at 14:05 +0200, Boris Brezillon wrote:
+Nicolas
On Fri, 2020-07-10 at 14:05 +0200, Boris Brezillon wrote:
> On Fri, 10 Jul 2020 08:50:28 -0300
> Ezequiel Garcia wrote:
>
> > On Fri, 2020-07-10 at 10:13 +0200, Boris Brezillon wrote:
> > > On Fri, 10 Jul 2020 01:21:07 -0300
> > > Ezequiel Garcia wr
On Fri, 2020-07-10 at 08:48 +, Jonas Karlman wrote:
> On 2020-07-10 10:13, Boris Brezillon wrote:
> > On Fri, 10 Jul 2020 01:21:07 -0300
> > Ezequiel Garcia wrote:
> >
> > > Hello Jonas,
> > >
> > > In the context of the uAPI cleanup,
>
On Fri, 2020-07-10 at 10:13 +0200, Boris Brezillon wrote:
> On Fri, 10 Jul 2020 01:21:07 -0300
> Ezequiel Garcia wrote:
>
> > Hello Jonas,
> >
> > In the context of the uAPI cleanup,
> > I'm revisiting this patch.
> >
> > On Sun, 2019-09-01 at 12
Hello Jonas,
In the context of the uAPI cleanup,
I'm revisiting this patch.
On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
> Add DPB entry flags to help indicate when a reference frame is a field picture
> and how the DPB entry is referenced, top or bottom field or full frame.
>
>
is provided.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Philipp Zabel
Reviewed-by: Jonas Karlman
---
drivers/staging/media/hantro/hantro_drv.c | 29 ---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_drv.c
b/drivers/staging
.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Jonas Karlman
---
drivers/staging/media/rkvdec/rkvdec.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/staging/media/rkvdec/rkvdec.c
b/drivers/staging/media/rkvdec/rkvdec.c
index 225eeca73356..accb4a902fdd 100644
-10
and High-422 bitstreams. This needs more work, so for now
they are refused.
The same approach can be use on Cedrus, but since I'm not
very familiar there, I'll leave that to others.
Applies on top of media master.
v2:
* Use p_new instead of p_cur.
* s/PPS/SPS in commit log.
Ezequiel Garcia (2
Hello Jernej,
I'd like to post a new H264 uAPI cleanup series soon,
would you mind resending this, or otherwise do you
mind if I include this patch in the series?
See below for a tiny comment.
On Thu, 4 Jun 2020 at 15:55, Jernej Skrabec wrote:
>
> When dealing with with interlaced frames,
IDEO_H264_LEVEL control, so that userspace can query the
> driver for the list of supported profiles and level.
>
> Signed-off-by: Jonas Karlman
> Reviewed-by: Ezequiel Garcia
> ---
> Changes in v2:
> - Moved to end
> - Collect r-b tag
> ---
> drivers/staging/media
Hi Jonas,
Nice work!
On Mon, 2020-07-06 at 21:54 +, Jonas Karlman wrote:
> Add an optional valid_fmt operation that should return the valid
> pixelformat of CAPTURE buffers.
>
> This is used in next patch to ensure correct pixelformat is used for 10-bit
> and 4:2:2 content.
>
>
On Mon, 2020-07-06 at 09:45 +, Jonas Karlman wrote:
> On 2020-06-26 19:11, Ezequiel Garcia wrote:
> > The hardware only supports 4:2:2, 4:2:0 or 4:0:0 (monochrome),
> > 8-bit or 10-bit depth content.
> >
> > Verify that the PPS refers to a supported bitstream,
On Fri, 2020-07-03 at 19:17 +, Jonas Karlman wrote:
> On 2020-07-03 16:58, Ezequiel Garcia wrote:
> > On Fri, 2020-07-03 at 06:55 +, Jonas Karlman wrote:
> > > On 2020-07-03 05:14, Ezequiel Garcia wrote:
> > > > Hi Jonas,
> > > >
> > > &g
due to re-using the main rockchip,rk3288-cru
> compatible as entry point.
>
> The binding change actually describes the compatibles as one or the other
> so adapt the code accordingly and add a real second entry-point for the
> clock controller.
>
> Signed-off-by: Heiko Stuebn
On Fri, 2020-07-03 at 17:28 +0200, Heiko Stuebner wrote:
> From: Heiko Stuebner
>
> Commit 1627f683636d ("clk: rockchip: Handle clock tree for rk3288w variant")
> added the check for rk3288w-specific clock-tree changes but in turn would
> require a double-compatible due to re-using the main
On Fri, 2020-07-03 at 16:11 +0200, Heiko Stuebner wrote:
> Hi Jagan,
>
> Am Montag, 29. Juni 2020, 21:11:03 CEST schrieb Jagan Teki:
> > On Tue, Jun 2, 2020 at 1:37 PM Mylène Josserand
> > wrote:
> > > The revision rk3288w has a different clock tree about "hclk_vio"
> > > clock, according to the
On Fri, 2020-07-03 at 06:55 +, Jonas Karlman wrote:
> On 2020-07-03 05:14, Ezequiel Garcia wrote:
> > Hi Jonas,
> >
> > Thanks for working on this.
> >
> > On Wed, 2020-07-01 at 21:56 +, Jonas Karlman wrote:
> > > Add an optional valid
Hi Jonas,
On Wed, 2020-07-01 at 21:56 +, Jonas Karlman wrote:
> Use bytesperline and buffer height to calculate the strides configured.
>
> This does not really change anything other than ensuring the bytesperline
> that is signaled to userspace matches was is configured in HW.
>
Are you
Hi Jonas,
Thanks for working on this.
On Wed, 2020-07-01 at 21:56 +, Jonas Karlman wrote:
> Add an optional validate_fmt operation that is used to validate the
> pixelformat of CAPTURE buffers.
>
> This is used in next patch to ensure correct pixelformat is used for 10-bit
> and 4:2:2
+Boris
On Wed, 2020-07-01 at 21:56 +, Jonas Karlman wrote:
> When decoding the second field in a complementary field pair the second
> field is sharing the same frame_num with the first field.
>
> Currently the frame_num for the first field is wrapped when it matches the
> field being
;
> Correct this by not adding 8 to the luma and chroma bit depth value.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Ezequiel Garcia
Thanks!
Ezequiel
> ---
> drivers/staging/media/rkvdec/rkvdec-h264.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
d being decoded, this cause issues to decode the second field in a
> complementary field pair.
>
> Fix this by using inclusive comparison, less than or equal.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Ezequiel Garcia
Thanks!
Ezequiel
> ---
> drivers/staging/media/rkvdec/rk
IDEO_H264_LEVEL control, so that userspace can query the
> driver for the list of supported profiles and level.
>
> In current state only Baseline to High profile is supported by the driver.
>
> Signed-off-by: Jonas Karlman
I think the patch is good so:
Reviewed-by: Ezequiel Garci
On Wed, 2020-07-01 at 21:56 +, Jonas Karlman wrote:
> The width and height in mbs is currently configured based on OUTPUT buffer
> resolution, this works for frame pictures but can cause issues for field
> pictures or when frmsize step_width is changed to support 10-bit decoding.
>
> When
sue is currently innocuous because an
encoder context only supports JPEG.
The codec_ops.done has an argument that codec-specific code
shouldn't need, so drop that as well.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro.h | 7
drivers/staging/media/hantro/hantro_dr
hich is cleaner.
This is just a cosmetic cleanup.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_h264.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_h264.c
b/drivers/staging/media/hantro/hantro_h264.c
in
So far we've been using the .buf_finish hook to distinguish
decoder from encoder. This is unnecessarily obfuscated.
Moreover, we want to move the buf_finish, so use a cleaner
scheme to distinguish the driver decoder/encoder type.
Signed-off-by: Ezequiel Garcia
---
v2:
* Get rid of the helper
Commit 986eee3a5234f fixed hantro_needs_postproc condition,
but missed one case. Encoders don't have any post-processor
hardware block, so also can't be disabled.
Fix it.
Fixes: 986eee3a5234f ("media: hantro: Prevent encoders from using
post-processing")
Signed-off-by: Ezequ
Second iteration, just addressing Philipp's and Robin's
feedback on patch 3.
Thanks,
Ezequiel
Ezequiel Garcia (6):
hantro: h264: Remove unused macro definition
hantro: h264: Rename scaling list handling function
hantro: Rework how encoder and decoder are identified
hantro: Move
The driver doesn't need the bytesused argument.
For decoders, the plane bytesused is known and therefore,
buf_prepare is used to set it. For encoders, it's
handled by the codec_ops.done hook.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_drv.c| 9 -
drivers
The generic H264 reference list builder moved all
the users of this macro, but left the macro.
Remove it.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_h264.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_h264.c
b/drivers
On Thu, 2020-06-25 at 11:05 -0400, Nicolas Dufresne wrote:
> Le mardi 23 juin 2020 à 15:28 -0300, Ezequiel Garcia a écrit :
> > The H.264 specification requires in its "Slice header semantics"
> > section that the following values shall be the
On Fri, 2020-06-26 at 10:52 +0100, Robin Murphy wrote:
> Hi Ezequiel,
>
> On 2020-06-25 17:35, Ezequiel Garcia wrote:
> > So far we've been using the .buf_finish hook to distinguish
> > decoder from encoder. This is unnecessarily obfuscated.
> >
> > Moreover, w
On Fri, 2020-06-26 at 09:58 +0200, Philipp Zabel wrote:
> Hi Ezequiel,
>
> On Thu, 2020-06-25 at 13:35 -0300, Ezequiel Garcia wrote:
> > So far we've been using the .buf_finish hook to distinguish
> > decoder from encoder. This is unnecessarily obfuscated.
> >
&g
is provided.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_drv.c | 29 ---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_drv.c
b/drivers/staging/media/hantro/hantro_drv.c
index 0db8ad455160..361ffaa821ef
-10
and High-422 bitstreams. This needs more work, so for now
they are refused.
The same approach can be use on Cedrus, but since I'm not
very familiar there, I'll leave that to others.
Applies on top of media master.
Ezequiel Garcia (2):
rkvdec: h264: Refuse to decode unsupported bitstream
.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/rkvdec/rkvdec.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/staging/media/rkvdec/rkvdec.c
b/drivers/staging/media/rkvdec/rkvdec.c
index 225eeca73356..0f81b47792f6 100644
--- a/drivers/staging/media
On Thu, 2020-06-25 at 09:52 +0200, Hans Verkuil wrote:
> On 23/06/2020 20:28, Ezequiel Garcia wrote:
> > The H264 interface is now ready to be part of the official
> > public API.
> >
> > In addition, sanitize header includes.
> >
> > Signed-off-by: Ezequi
(Adding Jernej, seems I haven't Cced him!)
On Thu, 2020-06-25 at 10:53 -0400, Nicolas Dufresne wrote:
> Le mardi 23 juin 2020 à 15:28 -0300, Ezequiel Garcia a écrit :
> > Align v4l2_h264_reference to 32-bits, giving some room
> > for future extensions.
> >
> > Sig
On Thu, 2020-06-25 at 17:30 +0200, Tomasz Figa wrote:
> On Tue, Jun 23, 2020 at 8:29 PM Ezequiel Garcia
> wrote:
> > Align v4l2_h264_reference to 32-bits, giving some room
> > for future extensions.
> >
> > Signed-off-by: Ezequiel Garcia
> > ---
> &
sue is currently innocuous because an
encoder context only supports JPEG.
The codec_ops.done has an argument that codec-specific code
shouldn't need, so drop that as well.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro.h | 7
drivers/staging/media/hantro/hantro_dr
Commit 986eee3a5234f fixed hantro_needs_postproc condition,
but missed one case. Encoders don't have any post-processor
hardware block, so also can't be disabled.
Fix it.
Fixes: 986eee3a5234f ("media: hantro: Prevent encoders from using
post-processing")
Signed-off-by: Ezequ
The generic H264 reference list builder moved all
the users of this macro, but left the macro.
Remove it.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_h264.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_h264.c
b/drivers
The driver doesn't need the bytesused argument.
For decoders, the plane bytesused is known and therefore,
buf_prepare is used to set it. For encoders, it's
handled by the codec_ops.done hook.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_drv.c| 9 -
drivers
hich is cleaner.
This is just a cosmetic cleanup.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_h264.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_h264.c
b/drivers/staging/media/hantro/hantro_h264.c
in
So far we've been using the .buf_finish hook to distinguish
decoder from encoder. This is unnecessarily obfuscated.
Moreover, we want to move the buf_finish, so use a cleaner
scheme to distinguish the driver decoder/encoder type.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro
Tackle some low hanging items. There's not much to say here,
see the patches for details.
We'll be soon posting more interesting changes :)
Thanks,
Ezequiel
Ezequiel Garcia (6):
hantro: h264: Remove unused macro definition
hantro: h264: Rename scaling list handling function
hantro: Rework
On Thu, 2020-06-25 at 11:01 -0400, Nicolas Dufresne wrote:
> Le mardi 23 juin 2020 à 15:28 -0300, Ezequiel Garcia a écrit :
> > Slice header syntax element 'first_mb_in_slice' can point
> > to the last macroblock, currently the field can only reference
> > 65536 macroblocks
Hi Yunfei,
Thanks for the patch.
On Sun, 21 Jun 2020 at 22:55, Yunfei Dong wrote:
>
> User driver need to get HDR10+ information for each capture buffer;
> For some encoder cases, user driver need to get encoded message for
> each frame. So add support read-only(Ro) request for capture queue.
>
The H264 interface is now ready to be part of the official
public API.
In addition, sanitize header includes.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_hw.h | 5 ++---
include/media/v4l2-ctrls.h| 3 ++-
include/media
x elements dec_ref_pic_marking() and those related
to pic order count, remain invariant as well, and therefore,
the fields dec_ref_pic_marking_bit_size and pic_order_cnt_bit_size
are also common to all slices.
Signed-off-by: Ezequiel Garcia
---
.../media/v4l/ext-ctrls-codec.rst
From: Jernej Skrabec
When dealing with with interlaced frames, reference lists must tell if
each particular reference is meant for top or bottom field. This info
is currently not provided at all in the H264 related controls.
Make reference lists hold a structure which will also hold flags along
-by: Philipp Zabel
[Ezequiel: rebase]
Signed-off-by: Ezequiel Garcia
---
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext
git/+/refs/heads/master/media/gpu/v4l2/
Ezequiel Garcia (5):
fixup! media: uapi: h264: update reference lists
media: uapi: h264: increase size of fields
media: uapi: h264: pad v4l2_ctrl_h264_pps to 64-bit
media: uapi: h264: Clean slice invariants syntax elements
media: uapi: make H264 state
The struct does not contain 64-bit types, and therefore
doesn't suffer from compatibility issues.
However, having it aligned to 64-bits is cleaner and
has the advantage of allowing future extensions.
Signed-off-by: Ezequiel Garcia
---
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
'first_mb_in_slice' and 'pic_num'.
The v4l2_h264_dpb_entry struct needs to be padded to avoid a hole,
which will be useful to allow future uAPI extensions.
Note that v4l2_ctrl_h264_slice_params struct will be modified
in a follow-up commit, and so we defer its 64-bit padding.
Signed-off-by: Ezequiel
Align v4l2_h264_reference to 32-bits, giving some room
for future extensions.
Signed-off-by: Ezequiel Garcia
---
.../userspace-api/media/v4l/ext-ctrls-codec.rst | 3 +++
drivers/media/v4l2-core/v4l2-ctrls.c | 16
include/media/h264-ctrls.h
Adding Helen to the discussion.
On Tue, 9 Jun 2020 at 04:43, Neil Armstrong wrote:
>
> Hi Nicolas,
>
> On 08/06/2020 20:59, Nicolas Dufresne wrote:
> > Le lundi 08 juin 2020 à 16:43 +0200, Hans Verkuil a écrit :
> >> On 08/06/2020 16:14, Neil Armstrong wrote:
> >>> On 08/06/2020 11:26, Hans
Hi Jernej,
On Thu, 4 Jun 2020 at 15:55, Jernej Skrabec wrote:
>
> Currently H264 interlaced content it's not properly decoded on Cedrus.
> There are two reasons for this:
> 1. slice parameters control doesn't provide enough information
> 2. bug in frame list construction in Cedrus driver
>
> As
Hello Jernej,
Thanks for the patch.
On Wed, 20 May 2020 at 14:12, Jernej Skrabec wrote:
>
> If VPU supports untiled output, it actually supports several different
> YUV 4:2:0 layouts, namely NV12, NV21, YUV420 and YVU420.
>
> Add support for all of them.
>
> Signed-off-by: Jernej Skrabec
> ---
t; + struct rkvdec_scaling_matrix scaling_list;
> u32 rps[RKV_RPS_SIZE];
> struct rkvdec_sps_pps_packet param_set[256];
> u8 err_info[RKV_ERROR_INFO_SIZE];
In particular, I wonder if the error info stuff
is really required.
I guess we'll want to merge a simple fix,
so no need to add
Hi Maxime,
Thanks for posting this patch. I think you can still improve it,
but it's a neat first try! :-)
On Fri, 29 May 2020 at 10:05, Maxime Chevallier
wrote:
>
> Introduce a driver for the camera interface on some Rockchip platforms.
>
> This controller supports CSI2, Parallel and BT656
On Wed, 2020-05-20 at 15:07 +0200, Hans Verkuil wrote:
> On 18/05/2020 19:40, 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.
> >
> > Fix it.
>
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 +++
On Mon, 2020-05-18 at 14:40 -0300, Ezequiel Garcia wrote:
> [PATCH 3/3] media: rkvdec: Add the VP9 backend
Oops, ^ should be v4 here.
Thanks,
Ezequiel
301 - 400 of 1882 matches
Mail list logo
