rger contiguous page.
To make a summary what I think we need here:
1. Alignment requirement for vertical direction
2. whether the device supports scatter list
3. what is the page size if the device would support iommu
4. plane layout in memory
Sincerely
Randy Li
From: "Hsia-Jun(Randy) Li"
Those modifiers only record the parameters would effort pixel
layout or memory layout. Whether physical memory page mapping
is used is not a part of format.
Signed-off-by: Hsia-Jun(Randy) Li
---
include/uapi/drm/drm_fou
. Adding a document for the future v4l2 extended
fmt.
v1:
first draft of DRM modifiers
Try to put basic tile formats into v4l2 fourcc
Hsia-Jun(Randy) Li (1):
drm/fourcc: Add Synaptics VideoSmart tiled modifiers
Randy Li (1):
Documentation/gpu: Add Synaptics tiling formats documentation
Documen
Signed-off-by: Randy Li
Signed-off-by: Hsia-Jun(Randy) Li
---
Documentation/gpu/drivers.rst | 1 +
Documentation/gpu/synaptics.rst | 81 +
2 files changed, 82 insertions(+)
create mode 100644 Documentation/gpu/synaptics.rst
diff --git a/Documentation/gpu
Sent from my iPad
> On Dec 1, 2022, at 5:39 PM, Daniel Vetter wrote:
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
>> On Thu, Dec 01, 2022 at 12:49:16AM
+0800, Hsia-Jun Li wrote:
>> From: "Hsia-Jun(Randy) Li"
>>
>> Those modifiers only record the parameters would effort pixel
>> layout or memory layout. Whether physical memory page mapping
>> is used is not a part of format.
>>
>> Sig
> On Nov 24, 2022, at 12:42 AM, Daniel Vetter wrote:
>
> On Wed, Nov 23, 2022 at 10:58:11PM +0800, Jisheng Zhang wrote:
>>> On Wed, Nov 23, 2022 at 05:19:57PM +0800, Hsia-Jun Li wrote:
>>> From: "Hsia-Jun(Randy) Li"
>>> Memory Traffic Reductio
> On Nov 24, 2022, at 1:27 AM, Daniel Vetter wrote:
>
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
>> On Thu, Nov 24, 2022 at 01:14:48AM +0800, Randy Li wrote:
>
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
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
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
ff-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++---
2 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/roc
oblem with him.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 30 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++---
2 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_
Also the weston only use the only two achors with a same
size and pixel format, I need more users to verify this
patch.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 44 ++---
2
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 | 1 +
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 9
I wonder why this patches are still not merged and well review.
So I just re-send them. I wish it is merged in a short time, or
I can't add a new pixel format to weston.
You can use the Gstreamer to verify this patch.
Randy Li (2):
drm/fourcc: add a 10bits fully packed variant of NV12
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/roc
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/roc
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. The color gamut
follows the BT.2020 standard.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm
quest 10bits yuv format support,
so I can't add the pixel format they don't use as I did a year ago.
You would ignore those patches.
v3:
I put a code comment in a wrong commit in the previous commit,
move it back.
v2:
add more comment to describe this pixel format
Randy Li (2):
drm/fourc
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 | 1 +
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 9
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/roc
quest 10bits yuv format support,
so I can't add the pixel format they don't use as I did a year ago.
You would ignore those patches.
Randy Li (2):
drm/fourcc: add a 10bits fully packed variant of NV12
drm/rockchip: Support 10 bits yuv format in vop
drivers/gpu/drm/drm_fourcc.c
On 05/22/2018 05:26 PM, Maarten Lankhorst wrote:
Op 20-05-18 om 19:17 schreef Randy Li:
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. The color gamut
follows the BT.2020 standard
need to
set the plane offset and stride when you are using the other files.
Randy Li (2):
drm/fourcc: add a 10bits fully packed variant of NV12
drm/rockchip: Support 10 bits yuv format in vop
drivers/gpu/drm/drm_fourcc.c| 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27
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. The color gamut
follows the BT.2020 standard.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/roc
: I4e8a34609d5b292d7da77385ff15bebbf258090c
Signed-off-by: Randy Li
Signed-off-by: Randy Li
---
.../display/rockchip/analogix_dp-rockchip.txt | 4 ++
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 52 ++
2 files changed, 56 insertions(+)
diff --git
a/Documentation
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
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
2017年01月17日 15:58, Randy Li wrote:
Hello:
I want to enable the video output at RK3288 Firefly board, but I
found if I enable CONFIG_DRM_FBDEV_EMULATION, the HDMI would crash
down sometimes but sometimes it works. After disable that opinion, I
never meet a problem. I have not verified it with eDP
] [] (do_work_pending) from []
(slow_work_pending+0xc/0x20)
[ 34.464856] ---[ end trace 95ed2c3f167607d5 ]---
--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended
(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
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
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
could move those sync job to one of drmWaitVBlank() or
drmModePageFlip.
But I found most of atomic_commit() would have a sync internal,
waiting vbank. So those functions like drmWaitVBlank() or
drmModePageFlip are not necessary after drmModeSetPlane()?
--
Randy Li
The third produce
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
On 10/28/2016 05:11 PM, Shawn Lin wrote:
> On 2016/10/23 3:18, Randy Li wrote:
>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>> This patch would try to enable them first. The eDP_AV
On 10/27/2016 11:03 PM, Xiang, Haihao wrote:
>> -Original Message-
>> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>> Of Randy Li
>> Sent: Monday, October 24, 2016 3:59 PM
>> To: libva at lists.freedesktop.org
>> Cc:
le of those kind of
display in VA-API or the documents would help(I would not image there is
a VA-API documents)
--
Randy Li
The third produce department
I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first. The eDP_AVDD_1V8 more
likely to be applied to eDP phy, but I have no time to confirmed
it yet.
Signed-off-by: Randy Li
On 10/20/2016 03:18 PM, Tomeu Vizoso wrote:
> On 19 October 2016 at 15:52, Randy Li wrote:
>> Hello,
>>
>> Recently, I want to use a eDP panel in my RK3288 platform, but I got the
>> following message:
>>
>> [8.935918] i2c i2c-6: of_i2c: mo
Hello,
Recently, I want to use a eDP panel in my RK3288 platform, but I got
the following message:
[8.935918] i2c i2c-6: of_i2c: modalias failure on /dp at ff97/ports
[8.936018] rockchip-drm display-subsystem: bound ff97.dp (ops
rockchip_dp_component_ops [analogix_dp_rockchip
On 10/17/2016 04:02 PM, Mark yao wrote:
> On 2016å¹´10æ17æ¥ 15:12, Heiko Stuebner wrote:
>> Am Montag, 17. Oktober 2016, 14:45:30 CEST schrieb Randy Li:
>>> Hello Tomasz:
>>>Heiko told me you are in charge of the graphics part of chromium, I
>>> think
xserver branch 1.18 from upstream, it is there
https://github.com/rockchip-linux/xserver/tree/rockchip-1.18
But the version I made would omit some pixels when it is drawing, I have
not found out why.
--
Randy Li
The third produce department
ror message, I have to disable the
>> display system that time.
>> In the today test, I meet the same problem with rk3399 evb board in
>> 4.4.
>> I have no idea what caused that, and it is a little hard to debug as
>> kernel still would never ki
The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.
Signed-off-by: Randy Li
---
.../display/panel/chunghwa,claa070wp03xg.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 27 ++
2 files change
It is actually a lvds panel connected through a rga-lvds bridge.
The touchscreen is communicated with i2c bus but the driver is not
support now.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++--
1 file changed, 52 insertions(+), 2
The timings issue is still here, this version is just some modifications
in dts file.
Randy Li (2):
ARM: dts: samsung: add rga-lvds panel in itop elite
drm/panel: Add support for Chunghwa CLAA070WP03XG panel
.../display/panel/chunghwa,claa070wp03xg.txt | 7 +++
arch/arm/boot/dts
The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.
Signed-off-by: Randy Li
---
.../display/panel/chunghwa,claa070wp03xg.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 27 ++
2 files change
It is actually a lvds panel connected through a rga-lvds bridge.
The touchscreen is communicated with i2c bus but the driver is not
support now.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++--
1 file changed, 52 insertions(+), 2
.inv_vden = 0,
},
}
Randy Li (2):
ARM: dts: samsung: add rga-lvds panel in itop elite
drm/panel: Add support for Chunghwa CLAA070WP03XG panel
.../display
is not supported in currently driver.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/exynos4412-itop-elite.dts | 35 ++---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts
b/arch/arm/boot/dts/exynos4412-itop
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 alw
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 dri
et help from someone.
--
Randy Li
The third produce department
On 08/24/2016 11:35 PM, Xiang, Haihao wrote:
>
>
>> -Original Message-----
>> From: Randy Li [mailto:randy.li at rock-chips.com]
>> Sent: Wednesday, August 24, 2016 6:30 PM
>> To: Xiang, Haihao ; libva at lists.freedesktop.org
>> Cc: nicolas.dufresne at col
63 matches
Mail list logo
