On 2018-12-21 17:44, Chen-Yu Tsai wrote:
> On Fri, Dec 21, 2018 at 11:21 PM wrote:
>> From: Marcus Cooper
>>
>> Bypass the regmap cache when flushing the i2s FIFOs and modify the tables
>> to reflect this.
>>
>> Signed-off-by: Marcus Cooper
>> ---
>> sound/soc/sunxi/sun4i-i2s.c | 29 +--
This patch enables HDMI CEC on RK3328 devices
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index
Update regulator-name to match node and schematics.
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
b/arch/arm64/boot/dts/rockchip/rk3328
This patchset fixes two regulator names and adds nodes to
enable use of leds and ir on Rock64.
Jonas Karlman (3):
arm64: dts: rockchip: fix regulator name on rk3328-rock64
arm64: dts: rockchip: add leds node on rk3328-rock64
arm64: dts: rockchip: add ir-receiver node on rk3328-rock64
Add led nodes on Rock64.
Use heartbeat trigger for the red standby led and
use mmc0 trigger for the white power led.
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip
Add ir-receiver node to enable on-board IR on Rock64.
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock64
On 2019-03-02 15:19, Katsuhiro Suzuki wrote:
> Ping...
>
> On 2019/02/18 2:34, Katsuhiro Suzuki wrote:
>> This patch adds HDMI sound (I2S0) node for rock64.
>>
>> After apply this patch, UART2 will fail to allocate DMA resources
>> but UART driver can work fine without DMA.
>>
>> This error is rela
On 2019-04-10 17:45, Doug Anderson wrote:
> Hi,
>
> On Fri, Mar 29, 2019 at 2:55 PM Douglas Anderson
> wrote:
>> It appears that there is a typo in the rk3288 TRM. For
>> GRF_SOC_CON0[7] it says that 0 means "vepu" and 1 means "vdpu". It's
>> the other way around.
>>
>> How do I know? Here's m
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 && (sl
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-06 17:12, Ez
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 E
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-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
although it can be superseded
> + * by the chroma-specific 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, a
MI. If you don't think so, please tell me.
> I wait your sound patch and after re-check this patch.
>
> Best Regards,
> Katsuhiro Suzuki
>
> On 2019/03/03 4:26, Katsuhiro Suzuki wrote:
>> Hello Jonas,
>>
>> Thanks for your comments.
>>
>> On 2019/
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
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
] 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
: 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
ts 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
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.
>>
>>
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 transmitti
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 sync
: 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-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 address
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 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
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-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 Murp
The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
also been identified as needing this workaround with a single iteration.
Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based on
device version")
Signed-off-by: Jonas Karlman
---
drive
.
Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drive
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
- aclk_usb3otg
Fixes: fe3511ad8a1c ("clk: rockchip: add clock controller for rk3328")
Signed-off-by: Jonas Karlman
---
drivers/clk/rockchip/clk-rk3328.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3328.c
b/drivers/cl
On 2019-02-20 10:57, Sean Young wrote:
> On Mon, Feb 18, 2019 at 09:59:36PM +0000, Jonas Karlman wrote:
>> This RC map is based on remote key schema at [1], the mouse button key
>> did not have an obvious target and was mapped to KEY_CONTEXT_MENU.
> How about BTN_LEFT ?
That s
This patch enables HDMI CEC on Tinker Board S
Signed-off-by: Jonas Karlman
---
arch/arm/boot/dts/rk3288-tinker-s.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-tinker-s.dts
b/arch/arm/boot/dts/rk3288-tinker-s.dts
index 37093922b482..590e3b06bbc4 100644
The following error can be seen during boot:
of: /cpus/cpu@501: Couldn't find opp node
Change cpu nodes to use operating-points-v2 in order to fix this.
Fixes: ce76de984649 ("ARM: dts: rockchip: convert rk3288 to
operating-points-v2")
Signed-off-by: Jonas Karlman
---
ar
The following message can be seen during boot:
rockchip-thermal ff28.tsadc: Missing rockchip,grf property
Fix this by adding rockchip,grf property to tsadc node.
Fixes: b67d6bc38823 ("ARM: dts: rockchip: add main thermal info to rk3288")
Signed-off-by: Jonas Karlman
---
arc
Add keymaps for the following single board computer vendors IR remotes:
- Pine64 IR Remote
- ODROID IR Remote
- Khadas IR Remote
Regards,
Jonas
Jonas Karlman (3):
[media] rc/keymaps: add keytable for Pine64 IR Remote Controller
[media] rc/keymaps: add keytable for ODROID IR Remote Controller
This RC map is based on remote key schema at [1], the mouse button key
did not have an obvious target and was mapped to KEY_CONTEXT_MENU.
[1] http://files.pine64.org/doc/Pine%20A64%20Schematic/remote-wit-logo.jpg
Signed-off-by: Jonas Karlman
---
drivers/media/rc/keymaps/Makefile| 1
The mouse button key did not have an obvious target and
was mapped to KEY_CONTEXT_MENU.
Signed-off-by: Jonas Karlman
---
drivers/media/rc/keymaps/Makefile| 1 +
drivers/media/rc/keymaps/rc-khadas.c | 46
include/media/rc-map.h | 1 +
3 files
This RC map is based on remote key schema at [1]
[1] https://wiki.odroid.com/accessory/connectivity/ir_remote_controller
Signed-off-by: Jonas Karlman
---
drivers/media/rc/keymaps/Makefile| 1 +
drivers/media/rc/keymaps/rc-odroid.c | 46
include/media/rc-map.h
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 profile.
&
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 when
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 bytesper
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 +,
On 2020-06-17 14:07, Huang Jiachai wrote:
> Hi Jonas Karlman,
>
> Is there an another yuv 10bit format with 4:4:4 sub-simpling but
> has no padding?
>
> Maybe we can call it DRM_FORMAT_NV30:
>
> { .format = DRM_FORMAT_NV30, .depth = 0,
>.num_
han Jonker
>
> 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:
>>
>> {
>> 400
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 profile.
&
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
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
igned-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
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
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
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 grad
("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
ues 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 +++---
[2] https://github.com/Kwiboo/linux-rockchip/commits/next-20200605-fmt_10
[3] https://github.com/Kwiboo/linux-rockchip/commits/next-20200605-rkvdec
[4] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.2.2-rkvdec
Regards,
Jonas
Jonas Karlman (2):
drm: drm_fourcc: add NV20 YUV fo
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the
Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 --
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '20' suffix refers to the optimum effective bits per pixel which is
achieved when the total number of luminance samples is a multiple of 4.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/drm_fourcc.c | 4
include/uapi/drm/drm_fourcc.
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
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(&ctx->c
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
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 br
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.
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
1 - 100 of 134 matches
Mail list logo
