On 2020-08-10 14:57, Ezequiel Garcia wrote:
> On Sun, 2020-08-09 at 23:11 +0200, Jernej Škrabec wrote:
>> Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je Ezequiel Garcia napisal(a):
>>> On Sat, 8 Aug 2020 at 18:01, Jonas Karlman wrote:
>>>> On 2020-08-0
On 2020-08-10 17:28, Ezequiel Garcia wrote:
> On Mon, 2020-08-10 at 14:55 +0000, Jonas Karlman wrote:
>> On 2020-08-10 14:57, Ezequiel Garcia wrote:
>>> On Sun, 2020-08-09 at 23:11 +0200, Jernej Škrabec wrote:
>>>> Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je
inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro
when configuring vco_div_5 on RK3328.
Fix this by using correct vco_div_5 macro for RK3328.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-roc
-drm-rockchip
Regards,
Jonas
Algea Cao (1):
phy/rockchip: inno-hdmi: Support more pre-pll configuration
Huicong Xu (1):
phy/rockchip: inno-hdmi: force set_rate on power_on
Jonas Karlman (3):
phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328
phy/rockchip: inno-hdmi: remove
-off-by: Jonas Karlman
Acked-by: Heiko Stuebner
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 74 ---
1 file changed, 49 insertions(+), 25 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index
for consistency.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/ro
no_c is not used in any calculation, lets remove it.
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno
-bit and Deep Color.
This result in pre/post pll not being re-configured when switching between
regular 8-bit and Deep Color video formats.
Fix this by calling set_rate in power_on to force pre pll re-configuration.
Signed-off-by: Huicong Xu
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip
a rounded pixel rate that exist
in the pre pll config table.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Zheng Yang
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletion
c matrix for non-4:2:0 YUV formats.
> + * @non_intra_quantiser_matrix: The quantization matrix coefficients
> + * for non-intra-coded frames, in zigzag scanning order. It is relevant
> + * for both luma and chroma components, although it can be superseded
> + * by the chroma-specific matrix for non-4:2
On 2019-09-02 18:18, Jonas Karlman wrote:
> On 2019-09-02 16:00, Philipp Zabel wrote:
>> Hi Jonas,
>>
>> On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
>>> Scaling list supplied from userspace using ffmpeg and libva-v4l2-request
>>> is already
On 2019-09-03 15:21, Philipp Zabel wrote:
> On Sun, 2019-09-01 at 12:45 +0000, Jonas Karlman wrote:
>> This need code cleanup and formatting
>>
>> Signed-off-by: Jonas Karlman
> The previous patches all work, but this patch breaks decoding of
> progressive content
On 2019-09-03 17:01, Philipp Zabel wrote:
> On Tue, 2019-09-03 at 14:02 +0000, Jonas Karlman wrote:
>> On 2019-09-03 15:21, Philipp Zabel wrote:
>>> On Sun, 2019-09-01 at 12:45 +0000, Jonas Karlman wrote:
>>>> This need code cleanup and formatting
>>
On 2019-09-03 12:58, Philipp Zabel wrote:
> Hi Jonas,
>
> On Sun, 2019-09-01 at 12:45 +0000, 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:
> Do you mean "A decoded 8-bit 4:2:0 fr
On 2019-09-03 20:08, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
>> Hi,
>>
>> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
>>> Hi,
>>>
>>> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
From: Yakir Yang
When
with speaker mask FL|FR|RC gets selected instead of
ca_id 0x0b with speaker mask FL|FR|LFE|FC|RL|RR for 6 channels
Fix this by reorder the channel allocation list with
most specific speaker mask at the top.
Signed-off-by: Jonas Karlman
---
sound/soc/codecs/hdmi-codec.c | 115
This patch add a VPU device node for rk3328.
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index
On 2020-08-18 23:38, Ezequiel Garcia wrote:
> On Tue, 2020-08-18 at 20:17 +0000, Jonas Karlman wrote:
>> Hi Ezequiel,
>>
>> On 2020-08-14 15:36, Ezequiel Garcia wrote:
>>> Currently, the drivers makes no distinction between per_request
>>> and mandator
Hi Ezequiel,
On 2020-08-14 15:36, Ezequiel Garcia wrote:
> Currently, the drivers makes no distinction between per_request
> and mandatory, as both are used in the same request validate check.
>
> The driver only cares to know if a given control is
> required to be part of a request, so only one
On 2020-08-06 17:12, Ezequiel Garcia wrote:
> The prediction weight parameters are only required under
> certain conditions, which depend on slice header parameters.
>
> As specified in section 7.3.3 Slice header syntax, the prediction
> weight table is present if:
>
> ((weighted_pred_flag &&
On 2020-10-29 13:38, Ezequiel Garcia wrote:
> On Mon, 2020-10-12 at 23:39 +0000, Jonas Karlman wrote:
>> Hi,
>>
>> On 2020-10-12 22:59, Adrian Ratiu wrote:
>>> Dear all,
>>>
>>> This series introduces a regmap infrastructure for the Hantro driver
configuration
Huicong Xu (1):
phy/rockchip: inno-hdmi: force set_rate on power_on
Jonas Karlman (3):
phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328
phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate
phy/rockchip: inno-hdmi: do not power on rk3328 post pll
a rounded pixel rate that exist
in the pre pll config table.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Zheng Yang
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletion
-bit and Deep Color.
This result in pre/post pll not being re-configured when switching between
regular 8-bit and Deep Color video formats.
Fix this by calling set_rate in power_on to force pre pll re-configuration.
Signed-off-by: Huicong Xu
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip
for consistency.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/ro
no_c is not used in any calculation, lets remove it.
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno
-off-by: Jonas Karlman
Acked-by: Heiko Stuebner
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 74 ---
1 file changed, 49 insertions(+), 25 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index
inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro
when configuring vco_div_5 on RK3328.
Fix this by using correct vco_div_5 macro for RK3328.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-roc
Hi,
On 2020-10-12 22:59, Adrian Ratiu wrote:
> Dear all,
>
> This series introduces a regmap infrastructure for the Hantro driver
> which is used to compensate for different HW-revision register layouts.
> To justify it h264 decoding capability is added for newer VC8000 chips.
>
> This is a
Hi Neil,
On 2019-09-18 10:05, Neil Armstrong wrote:
> Hi Jonas,
>
> On 26/05/2019 23:18, Jonas Karlman wrote:
>> Add support for HDR metadata using the hdr_output_metadata connector
>> property,
>> configure Dynamic Range and Mastering InfoFrame accordingly.
>>
On 2019-09-04 15:07, Ezequiel Garcia wrote:
> 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
the values in the scaling list
should already be in matrix order.
Fix this by removing the reordering and change to use two memcpy.
Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Jonas Karlman
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 70 +++---
("media: v4l: Add definitions for HEVC stateless decoding")
Signed-off-by: Jonas Karlman
---
drivers/media/v4l2-core/v4l2-ctrls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b2
Update devicetree binding documentation for Rockchip VPU on RK3328.
Signed-off-by: Jonas Karlman
---
.../devicetree/bindings/media/rockchip-vpu.txt | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt
b
] http://kwiboo.libreelec.tv/test/samples/
[2] https://github.com/Kwiboo/rockchip-vpu-regtool
[3] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.0.4
[4]
https://github.com/Kwiboo/FFmpeg/compare/4.0.4-Leia-18.4...45df99d31062e068073cf899dce559e334c9127f
Regards,
Jonas
Jonas Karlman
The RK3399 SoC has two VPU blocks capable of H264 decoding, VPU2 and RKVDEC,
this enables support for H264 decoding using the VPU2 block.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/hantro/rk3399_vpu_hw.c | 21 +++-
1 file changed, 20 insertions(+), 1 deletion
This need code cleanup and formatting
Signed-off-by: Jonas Karlman
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 26 ++--
drivers/staging/media/hantro/hantro_h264.c| 126 --
drivers/staging/media/hantro/hantro_hw.h | 4 +
3 files changed, 100 insertions(+), 56
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
---
drivers/staging/media/hantro/rk3288_vpu_hw.c | 4 ++
Rockchip RK3399 SoC has the same Hantro G1 IP block
as RK3288, but the registers are entirely different.
In a similar fashion as MPEG-2 and VP8 decoding,
it's simpler to just add a separate implementation.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/hantro/Makefile | 1
: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Jonas Karlman
---
drivers/staging/media/hantro/hantro_g1_h264_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
b/drivers/staging/me
Use generated code from my rockchip-vpu-regtool
This need code cleanup and formatting
Signed-off-by: Jonas Karlman
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 661 +++---
drivers/staging/media/hantro/hantro_h264.c| 14 +
drivers/staging/media/hantro/hantro_hw.h
bits to support H264 decoding")
Signed-off-by: Jonas Karlman
---
drivers/staging/media/hantro/hantro_v4l2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c
b/drivers/staging/media/hantro/hantro_v4l2.c
index 3dae52abb96c..3a
RK3328 SoC has the same decoder IP block as RK3399,
lets enable H264 decoding on RK3328.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/hantro/rk3399_vpu_hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw.c
b/drivers
reordering and write the scaling matrix in an order expected by
the VPU, also only allocate memory for the two 8x8 lists used.
Fixes: a9471e25629b ("media: hantro: Add core bits to support H264 decoding")
Signed-off-by: Jonas Karlman
---
drivers/staging/media/hantro/hantro_h
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.
Signed-off-by: Jonas Karlman
---
Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 12
include/media/h264-ctrls.h
pic_size in hantro_h264_dec_hw_ctx struct is no longer used,
lets remove it.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/hantro/hantro_h264.c | 5 -
drivers/staging/media/hantro/hantro_hw.h | 3 ---
2 files changed, 8 deletions(-)
diff --git a/drivers/staging/media/hantro
an
additional check for High Profile (100).
Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Jonas Karlman
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 33 +++
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/drive
be avoided.
Signed-off-by: Jonas Karlman
---
drivers/media/cec/cec-core.c | 4
drivers/media/cec/cec-notifier.c | 23 ++-
drivers/media/cec/cec-priv.h | 1 +
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/media/cec/cec-core.c b/drivers
On 2019-09-02 10:10, Neil Armstrong wrote:
> On 01/09/2019 18:14, Jonas Karlman wrote:
>> Update CEC phys addr and EDID on HPD event, fixes lost CEC phys addr and
>> stale EDID when HDMI cable is unplugged/replugged or AVR is powered on/off.
>>
>> Signed-off-by: Jonas
On 2019-09-02 13:46, Hans Verkuil wrote:
> On 9/1/19 2:45 PM, Jonas Karlman wrote:
>> Rockchip RK3399 SoC has the same Hantro G1 IP block
>> as RK3288, but the registers are entirely different.
>>
>> In a similar fashion as MPEG-2 and VP8 decoding,
>> it
On 2019-09-02 16:00, Philipp Zabel wrote:
> Hi Jonas,
>
> On Sun, 2019-09-01 at 12:45 +0000, Jonas Karlman wrote:
>> Scaling list supplied from userspace using ffmpeg and libva-v4l2-request
>> is already in matrix order and can be used without applying the inverse
>> sca
On 2019-09-02 15:02, Ezequiel Garcia wrote:
> 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
: reported physical address 2.0.0.0 for logical
address 5
[ 291.296199] cec-dw_hdmi: reported physical address 2.0.0.0 for logical
address 11
Signed-off-by: Jonas Karlman
---
drivers/media/cec/cec-adap.c | 9 -
drivers/media/cec/cec-core.c | 18 ++
drivers/media/cec/cec
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 it a little bit harder to
spot differences
and to keep the RK3399 version of the code in
On 2019-10-04 16:20, Robin Murphy wrote:
> On 04/10/2019 04:39, Soeren Moch wrote:
>>
>> On 04.10.19 04:13, Shawn Lin wrote:
>>> On 2019/10/4 8:53, Soeren Moch wrote:
On 04.10.19 02:01, Robin Murphy wrote:
> On 2019-10-03 10:50 pm, Soeren Moch wrote:
>> According to the RockPro64
RK3328 SoC has the same decoder IP block as RK3399,
lets enable VP8 decoding on RK3328.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/hantro/rk3399_vpu_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw.c
b/drivers
This patch add a VPU device node for rk3328.
Signed-off-by: Jonas Karlman
---
It would be great if this can be considered for v5.4,
related dt-bindings commit has been merged in media tree for v5.4.
Decoding using hantro driver has been tested on a Pine64 Rock64 RK3328 device.
---
arch/arm64
On 2019-10-07 19:45, Ezequiel Garcia wrote:
> From: Francois Buergisser
>
> The setting of the motion vectors usage and the setting of motion
> vectors address are currently done under different conditions.
>
> When decoding pre-recorded videos, this results of leaving the motion
> vectors
This patch enables Dynamic Range and Mastering InfoFrame on H6.
Cc: Maxime Ripard
Cc: Jernej Skrabec
Signed-off-by: Jonas Karlman
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 ++
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
2 files changed, 3 insertions(+)
diff
This patch enables Dynamic Range and Mastering InfoFrame on GXL, GXM and G12A.
Cc: Neil Armstrong
Signed-off-by: Jonas Karlman
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
/rockchip-linux/kernel/commit/d1943fde81ff41d7cca87f4a42f03992e90bddd5
Cc: Zheng Yang
Signed-off-by: Jonas Karlman
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 81 +++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++
include/drm
This patch enables Dynamic Range and Mastering InfoFrame on RK3328 and RK3399.
Cc: Sandy Huang
Cc: Heiko Stuebner
Signed-off-by: Jonas Karlman
Reviewed-by: Heiko Stuebner
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff
On 2019-10-08 05:29, Tomasz Figa wrote:
> Hi Jonas,
>
> On Tue, Oct 8, 2019 at 3:33 AM Jonas Karlman wrote:
>> On 2019-10-07 19:45, Ezequiel Garcia wrote:
>>> From: Francois Buergisser
>>>
>>> The setting of the motion vectors usage and the setting o
On 2019-10-08 07:27, Tomasz Figa wrote:
> Hi Ezequiel, Jonas,
>
> On Tue, Oct 8, 2019 at 2:46 AM Ezequiel Garcia wrote:
>> From: Jonas Karlman
>>
>> TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels,
>> change frmsize max_width/max
On 2019-10-08 12:26, Tomasz Figa wrote:
> On Tue, Oct 8, 2019 at 3:23 PM Jonas Karlman wrote:
>> On 2019-10-08 05:29, Tomasz Figa wrote:
>>> Hi Jonas,
>>>
>>> On Tue, Oct 8, 2019 at 3:33 AM Jonas Karlman wrote:
>>>> On 2019-10-07 19:45, Ezequi
On 2019-10-08 15:53, Tomasz Figa wrote:
> On Tue, Oct 8, 2019 at 10:35 PM Tomasz Figa wrote:
>> On Tue, Oct 8, 2019 at 7:42 PM Tomasz Figa wrote:
>>> On Tue, Oct 8, 2019 at 3:31 PM Jonas Karlman wrote:
>>>> On 2019-10-08 07:27, Tomasz Figa wrote:
>>>&g
On 2019-10-08 16:12, Jonas Karlman wrote:
> On 2019-10-08 15:53, Tomasz Figa wrote:
>> On Tue, Oct 8, 2019 at 10:35 PM Tomasz Figa wrote:
>>> On Tue, Oct 8, 2019 at 7:42 PM Tomasz Figa wrote:
>>>> On Tue, Oct 8, 2019 at 3:31 PM Jonas Karlman wrote:
>>>&g
On 2019-10-04 19:24, Sören Moch wrote:
>
> On 04.10.19 17:33, Shawn Lin wrote:
>> On 2019/10/4 22:20, Robin Murphy wrote:
>>> On 04/10/2019 04:39, Soeren Moch wrote:
On 04.10.19 04:13, Shawn Lin wrote:
> On 2019/10/4 8:53, Soeren Moch wrote:
>>
>> On 04.10.19 02:01, Robin
V4L2_CID_MPEG_VIDEO_H264_SPS);
V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS line should be removed not SPS :-)
With that fixed,
Reviewed-by: Jonas Karlman
Best regards,
Jonas
> run->sps = ctrl ? ctrl->p_cur.p : NULL;
> ctrl = v4l2_ctrl_find(>ctrl_hdl,
>
Hi,
On 2020-07-24 21:08, Ezequiel Garcia wrote:
> Hello Jonas,
>
> On Wed, 2020-07-22 at 21:52 +0000, Jonas Karlman wrote:
>> On 2020-07-15 22:22, Ezequiel Garcia wrote:
>>> As discussed recently, the current interface for the
>>> Decoded Picture Buffer is n
On 2020-07-15 22:22, Ezequiel Garcia wrote:
> 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
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.
>
> This commit introduces enough semantics to support
> frame and field coding, and to signal how DPB entries
> are "used
on a Rock Pi 4 RK3399 device using
the ffmpeg vp9 request api hwaccel at [1].
Decoding up to 3840x2160@30fps media is working great.
(frame scaling was not tested or fully implemented in ffmpeg hwaccel)
Tested-by: Jonas Karlman
[1] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-
pair.
Fix this by using inclusive comparison, less than or equal.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c
b/drivers/staging/media/rkvdec/rkvdec-h264
of
the field instead of height of frame.
Validate pic_width_in_mbs_minus1 and pic_height_in_map_units_minus1
against CAPTURE buffer resolution and use these values to configure HW.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 44 +++---
1 file changed, 39
[1] https://patchwork.linuxtv.org/cover/64977/
[2] https://patchwork.freedesktop.org/series/78099/
[3]
https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3-rkvdec-high-10
[4] https://github.com/Kwiboo/linux-rockchip/commits/linuxtv-rkvdec-high-10
Regards,
Jonas
Jonas Karlman (9):
media: rkvdec: h26
-by: Jonas Karlman
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c
b/drivers/staging/media/rkvdec/rkvdec-h264.c
index c9aebeb8f9b3..9c8e49642cd9 100644
--- a/drivers/staging/media
Add helper functions to calculate plane bytesperline and sizeimage, these
new helpers consider block width and height when calculating plane
bytesperline and sizeimage.
This prepare support for new pixel formats added in next patch that make
use of block width and height.
Signed-off-by: Jonas
group is
packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '15' and '20' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 8 for NV15 and 4 for NV20.
Signed-off-by: Jonas
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 content.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/rkvdec/rkvdec.c | 8
drivers
of supported profiles and level.
In current state only Baseline to High profile is supported by the driver.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/rkvdec/rkvdec.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/staging/media/rkvdec/rkvdec.c
b/drivers/staging
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.
Signed-off-by: Jonas Karlman
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 27
Add support and enable decoding of H264 High 10 and 4:2:2 profiles.
H264 frmsize step_width/height is changed to 64 pixels in order to ensure
proper align for 10-bit formats. Incompatible pixelformats gets rejected in
s_fmt/try_fmt ioctl call.
Signed-off-by: Jonas Karlman
---
drivers/staging
On 2020-07-03 04:54, Ezequiel Garcia wrote:
> On Wed, 2020-07-01 at 21:56 +0000, Jonas Karlman wrote:
>> The Rockchip Video Decoder used in RK3399 supports H.264 profiles from
>> Baseline to High 4:2:2 up to Level 5.1, except for the Extended profil
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 validate_fmt operation that is used to validate the
>> pixelformat of CAPTURE buffers.
>>
>&g
On 2020-07-03 04:48, Ezequiel Garcia wrote:
> On Wed, 2020-07-01 at 21:56 +0000, 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 wh
On 2020-07-03 05:21, Ezequiel Garcia wrote:
> Hi Jonas,
>
> On Wed, 2020-07-01 at 21:56 +0000, Jonas Karlman wrote:
>> Use bytesperline and buffer height to calculate the strides configured.
>>
>> This does not really change anything other than ensuring the bytes
On 2020-07-03 16:58, Ezequiel Garcia wrote:
> On Fri, 2020-07-03 at 06:55 +0000, 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 +,
onker
>
> https://lore.kernel.org/lkml/20200620134659.4592-1-jbx6...@gmail.com/
>
> On 1/8/20 10:07 PM, Jonas Karlman wrote:
>> From: Algea Cao
>>
>> Adding the following freq cfg in 8-bit and 10-bit color depth:
>>
>> {
>> 4000, 6
On 2020-07-08 05:19, Ezequiel Garcia wrote:
> On Mon, 2020-07-06 at 21:54 +0000, Jonas Karlman wrote:
>> The Rockchip Video Decoder used in RK3399 supports H.264 profiles from
>> Baseline to High 4:2:2 up to Level 5.1, except for the Extended profil
On 2020-07-08 05:16, Ezequiel Garcia wrote:
> 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 n
ot p_cur to validate the new ctrl value, same for
hantro patch.
With both fixed this and the hantro patch is,
Reviewed-by: Jonas Karlman
Regards,
Jonas
> + /*
> + * TODO: The hardware supports 10-bit and 4:2:2 profiles,
> + * but it's currently broken
This extract setting decoded pixfmt into a helper method, current code is
replaced with a call to the new helper method.
The helper method is also called from a new function in next patch.
Signed-off-by: Jonas Karlman
---
Changes in v2:
- New patch
---
drivers/staging/media/rkvdec/rkvdec.c
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.
Signed-off-by: Jonas Karlman
---
Changes in v2:
- Reworked validation of pixelformat
Limitations
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 what is configured in HW.
Signed-off-by: Jonas Karlman
---
Changes in v2:
- Drop code refactoring
---
drivers
group is
packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '15' and '20' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 8 for NV15 and 4 for NV20.
Signed-off-by: Jonas
Add helper functions to calculate plane bytesperline and sizeimage, these
new helpers consider block width and height when calculating plane
bytesperline and sizeimage.
This prepare support for new pixel formats added in next patch that make
use of block width and height.
Signed-off-by: Jonas
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/rkvdec/rkvdec.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/staging/media/rkvdec/rkvdec.c
b/drivers
-by: Jonas Karlman
---
Changes in v2:
- Only align decoded buffer instead of using frmsize step_width
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 20
drivers/staging/media/rkvdec/rkvdec.c | 19 +--
2 files changed, 29 insertions(+), 10 deletions(-)
diff
and pic_height_in_map_units_minus1
against OUTPUT buffer resolution and use these values to configure HW.
Signed-off-by: Jonas Karlman
---
Changes in v2:
- Validate against coded_fmt instead of decoded_fmt
- Validation moved to rkvdec_try_ctrl
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 4
1 - 100 of 134 matches
Mail list logo
