On 4/10/19 11:57 PM, Nicolas Dufresne wrote:
Le mercredi 10 avril 2019 à 20:42 +0800, ayaka a écrit :
From: Randy Li
TODO:
task finish
finish a task before it would be dequeued
iommu attach won't reload buffers
Signed-off-by: Randy Li
Signed-off-by: Randy Li
---
drivers/staging/Kc
previous mail.
Besides, this patch won't solve all the problem, if you
don't disable the size_aligned of the iova driver or
there would be a gap between the plane 0 and plane 1.
This patch is used for showing the problem we met not
for merging.
Signed-off-by: Randy Li
---
drivers/me
From: Randy Li
Signed-off-by: Randy Li
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 84f14b132e8f
From: Randy Li
Signed-off-by: Randy Li
---
drivers/staging/Kconfig | 2 ++
drivers/staging/Makefile | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index c0901b96cfe4..5f84035e2a89 100644
--- a/drivers/staging/Kconfig
+++ b/drivers
I don't care, I don't want to store buffers for a session.
I just want to use it to verify the FFmpeg.
I want the memory region !!!
It can save more time if those data are prepared in userspace.
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/mpp_dev_common.c | 3 +--
drive
ink I need to do some work at v4l2 core.
Randy Li (6):
arm64: dts: rockchip: add power domain to iommu
staging: video: rockchip: add v4l2 decoder
[TEST]: rockchip: mpp: support qptable
staging: video: rockchip: add video codec
arm64: dts: rockchip: boost clocks for rk3328
arm64: dts: roc
From: Randy Li
It is based on the vendor driver sent to mail list before.
Only MPEG2 video for VDPU2 works. And it need a patch to
fill the QP table.
I have finished the register table of the rkvdec and rk hevc
decoder. But I can't feed its proper input stream, I will
talk the reason
On 1/22/19 2:26 PM, Alexandre Courbot wrote:
Documents the protocol that user-space should follow when
communicating with stateless video decoders.
The stateless video decoding API makes use of the new request and tags
APIs. While it has been implemented with the Cedrus driver so far, it
shoul
format and
rebased.
Cc: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Randy Li
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_fourcc.c | 9 +
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 4
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 12
for that
driver is sent before.
Randy Li (2):
drm/fourcc: Add new P010, P016 video format
drm/fourcc: add a 10bits fully packed variant of NV12
drivers/gpu/drm/drm_fourcc.c | 13 +
include/uapi/drm/drm_fourcc.h | 29 +
2 files changed, 42 insertions(+)
--
2.20.1
Please don't do that
I reply the
Re: [PATCHv4 00/10] As was discussed here (among other places):
talking about the disadvantage of using the buffer tag, driver won't
aware which buffer will be used for current picture unless all the
previous work are done.
On 1/7/19 7:36 PM, Hans Verkuil
On 12/5/18 6:20 PM, hverkuil-ci...@xs4all.nl wrote:
From: Hans Verkuil
https://lkml.org/lkml/2018/10/19/440
using capture queue buffer indices to refer to reference frames is
not a good idea. A better idea is to use a 'tag' where the
application can assign a u32 tag to an output buffer, whic
On 12/12/18 8:51 PM, Paul Kocialkowski wrote:
Hi,
On Wed, 2018-12-05 at 21:59 +0100, Jernej Škrabec wrote:
+
+#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE 0x01
+#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER 0x02
+#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
+
+#define V4L2_
Signed-off-by: Randy Li
---
drivers/staging/Kconfig | 2 ++
drivers/staging/Makefile | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e4f608815c05..81634dd0a283 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
Fixing those deprecated function from vendor kernel.
Removing those features don't exist in upstream kernel.
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/mpp_dev_common.c | 12 ++--
drivers/staging/rockchip-mpp/mpp_dev_common.h | 2 +-
drivers/staging/rockchi
ff-by: Randy Li
---
.../boot/dts/rockchip/rk3399-sapphire.dtsi| 29
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 68 +--
2 files changed, 90 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
b/arch/arm64/boot/dts/rockchip/r
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/Kconfig | 52 +
drivers/staging/rockchip-mpp/Makefile | 16 +
drivers/staging/rockchip-mpp/mpp_debug.h | 87 ++
drivers/staging/rockchip-mpp/mpp_dev_common.c | 971 ++
drivers/staging/rockchip-mpp
ould attend the FOSDEM 2019, if you have any problem, I think you can
catch me easily there.
Randy Li (4):
staging: video: rockchip: video codec for vendor API
staging: video: rockchip: fixup for upstream
staging: video: rockchip: add video codec
arm64: dts: rockchip: add video codec
32
mask);
+void rga_start(struct rockchip_rga *rga);
+void rga_cmd_set(struct rga_ctx *ctx, void *src_mmu_pages, void
*dst_mmu_pages);
+
+#endif
--
Randy Li
y not meet any
problem to understand it.
Best regards,
Hugues.
On 05/19/2017 10:15 AM, Randy Li wrote:
On 05/19/2017 04:08 PM, Hugues FRUCHET wrote:
Hi all,
Here is the latest st-delta MPEG2 code:
[PATCH v6 0/3] Add support for MPEG-2 in DELTA video decoder
http://www.mail-archive.com/
this constraint, but the point here is to define
control interface, as far as I have understood code, Request API will not
affect those control definitions.
Some updates inline thereafter regarding activities on this subject; me for
MPEG-2 on ST platform and Randy Li, Nicolas Dufresne, Ayaka for
the V4L2_PIX_FMT_P010,
which uses the unused 6 bits to store the next pixel. And with
the alignment requirement of the hardware, it usually would be
some extra space left at the end of a stride.
Signed-off-by: Randy Li
---
Documentation/media/uapi/v4l/pixfmt-p010.rst | 126
The rockchip use a special pixel format for those yuv pixel
format with 10 bits color depth.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++---
drivers/gpu/drm/rockchip
pixel format
V6: reversed Cb/Cr order in comments
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.
Cc: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Randy Li
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm
kchip, although it is not common used pixel format,
but it could save lots of memory, it may be welcome by the
other vendor, also I think the 3GR serial from Intel would
use the same pixel format as the video IP comes from rockchip.
Randy Li (3):
drm_fourcc: Add new P010, P016 video format
v4l: Add
(It is more important than API
compatible especially for those 4K video). And I want to know more ideas
about this topic.
I would begin the writing the new driver after the coming culture new
year vacation(I would go to the Europe), I wish we can decide the final
mechanism before I begin this job.
Hello all:
I have recently finish the learning of the H.264 codec and ready to
write the driver. Although I have not get deep in syntax of H.264 but I
think I just need to reuse and extended the VA-API H264 Parser from
gstreamer. The whole plan in userspace is just injecting a parsing
operat
pixel formats in v4l2, as it doesn't have a flag like drm does.
I have not met the usage of those 16 bits per-channel format,
it is a very large color range, even the DSLR only use 12 bits.
Randy Li (2):
drm_fourcc: Add new P010, P016 video format
[media] v4l: Add 10/16-bits per channel YUV
s new decoder has supported those 10 bits format for
profile_10 HEVC/AVC video.
Signed-off-by: Randy Li
v4l2
---
Documentation/media/uapi/v4l/pixfmt-p010.rst | 86
Documentation/media/uapi/v4l/pixfmt-p010m.rst | 94 ++
Documentation/media/uapi/v4l/pixfmt-p016.rst
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.
Signed-off-by: Randy Li
C/AVC video.
Signed-off-by: Randy Li
---
include/uapi/linux/videodev2.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..9e03f20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videod
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.
Signed-off-by: Randy Li
---
include/uapi/drm/drm_fourcc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/in
Those pixel formats comes from Gstreamer and ffmpeg. Currently,
the VOP(video output mixer) found on RK3288 and future support
those pixel formats are input. Also the decoder on RK3288
could use them as output.
Randy Li (2):
drm_fourcc: Add new P010 video format
[media] v4l: Add 10-bits per
cc also Ayaka to this email. He's a Rockchip employee in charge
of Linux Support.
Should you have deeper technical questions about this, he will
probably be able to answer that :)
Cheers,
Lionel
--
Randy Li
The third produce department
--
To unsubscribe from this list: send the line "
On 11/04/2016 09:55 PM, Hugues FRUCHET wrote:
Hi Randy,
thanks for reply, some comments below:
On 10/27/2016 03:08 AM, Randy Li wrote:
On 10/26/2016 11:09 PM, Hugues FRUCHET wrote:
Hi,
This RFC aims to start discussions in order to define the codec specific
controls structures to
ip VDPAU driver supporting it, but it is .
* H264
- Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested with
Chromium -> V4L2
- Randy Li for Rockchip RK3288 VPU support [6] tested with VLC? ->
libVA + rockchip-va-driver -> V4L2
I only tested it with Gstreamer -> VA-API element
the config store?
--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any
On 09/27/2016 03:52 PM, Hans Verkuil wrote:
On 27/09/16 05:43, Randy Li wrote:
Hello:
I have just done a JPEG HW encoder for the RK3288. I have been told
that I can't use the standard way to generate huffman table, the VPU
supports only 10 levels with a different huffman table.
If I
So where Should I place the huffman table?
--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privi
ugh a book, I hope that it make me explaining
the situation easily.
--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may co
The generic decoder settings for H.264. It is modified from
the VA-API. Adding the extra data required by the Rockchip.
Signed-off-by: Randy Li
---
include/uapi/linux/videodev2.h | 103 +
1 file changed, 103 insertions(+)
diff --git a/include/uapi/linux
iver rk_v4l2
[3] https://github.com/hizukiayaka/linux-kernel rk3288-media
Randy Li (2):
[media] v4l2-ctrls: add H.264 decoder settings controls
v4l2-ctrls: add generic H.264 decoder codec settings structure
drivers/media/v4l2-core/v4l2-ctrls.c | 2 +
include/uapi/linux/v4l2-controls.h |
These two controls would be used to set the H.264 codec settings
for decoder.
Signed-off-by: Randy Li
---
drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++
include/uapi/linux/v4l2-controls.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers
On 08/29/2016 01:49 PM, Andrzej Hajda wrote:
Hi,
On 08/27/2016 11:55 AM, Randy Li wrote:
Hi:
I have been reported that the setting the profile, level and bitrate
through the v4l2 extra controls would not make the encoded result
different. I tried it recently, it is true. Although the
Hi:
I have been reported that the setting the profile, level and bitrate
through the v4l2 extra controls would not make the encoded result
different. I tried it recently, it is true. Although the h264 parser
would tell me the result have been applied as different h264 profile and
level, but
On 08/26/2016 06:56 PM, Hans Verkuil wrote:
On 08/26/2016 12:05 PM, Randy Li wrote:
On 08/26/2016 05:34 PM, Hans Verkuil wrote:
Hi Randi,
On 08/26/2016 04:13 AM, Randy Li wrote:
Hello,
We always use some kind of hack work to make our Video Process
Unit(Multi-format Video Encoder
On 08/26/2016 05:34 PM, Hans Verkuil wrote:
Hi Randi,
On 08/26/2016 04:13 AM, Randy Li wrote:
Hello,
We always use some kind of hack work to make our Video Process
Unit(Multi-format Video Encoder/Decoder) work in kernel. From a
customize driver(vpu service) to the customize V4L2 driver
ent in charge of VPU, and I
am just beginning to learning DRM(thank the help from Intel again), I am
not so good at memory part as well(I am more familiar with CMA not the
IOMMU way), I may need know guide about the implementations when I am
going to submit driver, I hope I could get help from
49 matches
Mail list logo
