[PATCH] [TEST]: media: vb2: reverse DMA addr of each plane
With the default iova and dma-iommu driver, the starting
address of a new buffer would be at lower address than
the previous one.
This patch can solve this problem simply, but I want
a way to control the address direction of the IOMMU/IOVA.
The reason why we(ayaka and I) need to do this is simple,
some devices want a contiguous memory for its pixel data.
But with the single plane buffer, there is not a properly way
to export its buffer offsets with the userspace,
since their bytesperline and offset are not full related
to the picture width or height. You can find more detail
in the 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/media/common/videobuf2/videobuf2-core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2-core.c
index 15b6b9c0a2e4..6762d1547e49 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -204,11 +204,11 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
* Allocate memory for all planes in this buffer
* NOTE: mmapped areas should be page aligned
*/
- for (plane = 0; plane < vb->num_planes; ++plane) {
- unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
+ for (plane = vb->num_planes; plane > 0; --plane) {
+ unsigned long size = PAGE_ALIGN(vb->planes[plane - 1].length);
mem_priv = call_ptr_memop(vb, alloc,
- q->alloc_devs[plane] ? : q->dev,
+ q->alloc_devs[plane - 1] ? : q->dev,
q->dma_attrs, size, q->dma_dir, q->gfp_flags);
if (IS_ERR_OR_NULL(mem_priv)) {
if (mem_priv)
@@ -217,15 +217,15 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
}
/* Associate allocator private data with this plane */
- vb->planes[plane].mem_priv = mem_priv;
+ vb->planes[plane - 1].mem_priv = mem_priv;
}
return 0;
free:
/* Free already allocated memory if one of the allocations failed */
- for (; plane > 0; --plane) {
- call_void_memop(vb, put, vb->planes[plane - 1].mem_priv);
- vb->planes[plane - 1].mem_priv = NULL;
+ for (; plane < vb->num_planes; plane++) {
+ call_void_memop(vb, put, vb->planes[plane].mem_priv);
+ vb->planes[plane].mem_priv = NULL;
}
return ret;
--
2.20.1
[PATCH v2 1/6] arm64: dts: rockchip: add power domain to iommu
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..117d02e21932 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -581,6 +581,7 @@
clocks = < ACLK_H265>, < PCLK_H265>;
clock-names = "aclk", "iface";
#iommu-cells = <0>;
+ power-domains = < RK3328_PD_HEVC>;
status = "disabled";
};
@@ -592,6 +593,7 @@
clocks = < ACLK_VPU>, < HCLK_VPU>;
clock-names = "aclk", "iface";
#iommu-cells = <0>;
+ power-domains = < RK3328_PD_HEVC>;
status = "disabled";
};
@@ -603,6 +605,7 @@
clocks = < ACLK_VPU>, < HCLK_VPU>;
clock-names = "aclk", "iface";
#iommu-cells = <0>;
+ power-domains = < RK3328_PD_VPU>;
status = "disabled";
};
@@ -614,6 +617,7 @@
clocks = < ACLK_RKVDEC>, < HCLK_RKVDEC>;
clock-names = "aclk", "iface";
#iommu-cells = <0>;
+ power-domains = < RK3328_PD_VIDEO>;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index db9d948c0b03..23d061ab6fa6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1263,6 +1263,7 @@
clock-names = "aclk", "iface";
#iommu-cells = <0>;
power-domains = < RK3399_PD_VCODEC>;
+ status = "disabled";
};
vdec_mmu: iommu@ff660480 {
@@ -1273,6 +1274,7 @@
clocks = < ACLK_VDU>, < HCLK_VDU>;
clock-names = "aclk", "iface";
#iommu-cells = <0>;
+ power-domains = < RK3399_PD_VDU>;
status = "disabled";
};
--
2.20.1
[PATCH v2 3/6] [TEST]: rockchip: mpp: support qptable
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 +--
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 3 +++
drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 19 +--
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.c
b/drivers/staging/rockchip-mpp/mpp_dev_common.c
index c43304c3e7b8..1291b642179e 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.c
@@ -1193,8 +1193,7 @@ static int rockchip_mpp_queue_init(void *priv, struct
vb2_queue *src_vq,
src_vq->io_modes = VB2_MMAP | VB2_DMABUF;
src_vq->drv_priv = session;
src_vq->mem_ops = _dma_contig_memops;
- src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES |
- DMA_ATTR_NO_KERNEL_MAPPING;
+ src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES;
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
src_vq->min_buffers_needed = 1;
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
index ce98aa15025e..00413936623e 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
@@ -147,6 +147,9 @@ static int rkvdpu_s_fmt_vid_out_mplane(struct file *filp,
void *priv,
if (sizes >= SZ_16M)
return -EINVAL;
+ /* For those slice header data */
+ pix_mp->plane_fmt[pix_mp->num_planes - 1].sizeimage += SZ_1M;
+
session->fmt_out = *pix_mp;
/* Copy the pixel format information from OUTPUT to CAPUTRE */
diff --git a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
index d32958c4cb20..c12d1a8ef2da 100644
--- a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
+++ b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
@@ -52,7 +52,7 @@ static const u8 intra_default_q_matrix[64] = {
static void mpeg2_dec_copy_qtable(u8 * qtable, const struct
v4l2_ctrl_mpeg2_quantization
*ctrl)
{
- int i, n;
+ int i;
if (!qtable || !ctrl)
return;
@@ -111,21 +111,22 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session,
void *regs,
struct vb2_v4l2_buffer *src_buf)
{
const struct v4l2_ctrl_mpeg2_slice_params *params;
- const struct v4l2_ctrl_mpeg2_quantization *quantization;
const struct v4l2_mpeg2_sequence *sequence;
const struct v4l2_mpeg2_picture *picture;
+ const struct v4l2_ctrl_mpeg2_quantization *quantization;
struct vdpu2_regs *p_regs = regs;
+ void *qtable = NULL;
+ size_t stream_len = 0;
params = rockchip_mpp_get_cur_ctrl(session,
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
- quantization = rockchip_mpp_get_cur_ctrl(session,
-
V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
-
if (!params)
return -EINVAL;
sequence = >sequence;
picture = >picture;
+ quantization = rockchip_mpp_get_cur_ctrl(session,
+ V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
init_hw_cfg(p_regs);
@@ -202,7 +203,13 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session, void
*regs,
p_regs->sw64.rlc_vlc_base =
vb2_dma_contig_plane_dma_addr(_buf->vb2_buf, 0);
p_regs->sw122.strm_start_bit = params->data_bit_offset;
- p_regs->sw51.stream_len = vb2_get_plane_payload(_buf->vb2_buf, 0);
+ stream_len = vb2_get_plane_payload(_buf->vb2_buf, 0);
+ p_regs->sw51.stream_len = stream_len;
+
+ qtable = vb2_plane_vaddr(_buf->vb2_buf, 0) + ALIGN(stream_len, 8);
+ mpeg2_dec_copy_qtable(qtable, quantization);
+p_regs->sw61.qtable_base = p_regs->sw64.rlc_vlc_base
+ + ALIGN(stream_len, 8);
return 0;
}
--
2.20.1
[PATCH v2 2/6] staging: video: rockchip: add v4l2 decoder
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 below. The slice header reconstruction is not acceptable, even I don't care about VP9 now, the reference picture set for HEVC is very complex. Signed-off-by: Randy Li Signed-off-by: Randy Li --- drivers/staging/rockchip-mpp/Kconfig | 34 + drivers/staging/rockchip-mpp/Makefile | 10 + drivers/staging/rockchip-mpp/mpp_debug.h | 87 ++ drivers/staging/rockchip-mpp/mpp_dev_common.c | 1368 + drivers/staging/rockchip-mpp/mpp_dev_common.h | 212 +++ drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 997 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 616 drivers/staging/rockchip-mpp/mpp_service.c| 197 +++ drivers/staging/rockchip-mpp/mpp_service.h| 38 + drivers/staging/rockchip-mpp/rkvdec/hal.h | 63 + drivers/staging/rockchip-mpp/rkvdec/hevc.c| 166 ++ drivers/staging/rockchip-mpp/rkvdec/regs.h| 608 drivers/staging/rockchip-mpp/vdpu2/hal.h | 52 + drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 270 drivers/staging/rockchip-mpp/vdpu2/regs.h | 699 + 15 files changed, 5417 insertions(+) create mode 100644 drivers/staging/rockchip-mpp/Kconfig create mode 100644 drivers/staging/rockchip-mpp/Makefile create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hevc.c create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h diff --git a/drivers/staging/rockchip-mpp/Kconfig b/drivers/staging/rockchip-mpp/Kconfig new file mode 100644 index ..75eaa6a2541a --- /dev/null +++ b/drivers/staging/rockchip-mpp/Kconfig @@ -0,0 +1,34 @@ +# SPDX-License-Identifier: GPL-2.0 +menu "ROCKCHIP_MPP" + depends on ARCH_ROCKCHIP + +config ROCKCHIP_MPP_SERVICE + tristate "mpp service scheduler" + default n + help + rockchip mpp service. + +config ROCKCHIP_MPP_DEVICE + tristate "mpp device framework" + depends on ROCKCHIP_MPP_SERVICE + select V4L2_MEM2MEM_DEV + select VIDEOBUF2_DMA_CONTIG + default n + help + rockchip mpp device framework. + +config ROCKCHIP_MPP_VDEC_DEVICE + tristate "video decoder device driver" + depends on ROCKCHIP_MPP_DEVICE + default n + help + rockchip mpp video decoder and hevc decoder. + +config ROCKCHIP_MPP_VDPU2_DEVICE + tristate "VPU decoder v2 device driver" + depends on ROCKCHIP_MPP_DEVICE + default n + help + rockchip mpp vpu decoder v2. + +endmenu diff --git a/drivers/staging/rockchip-mpp/Makefile b/drivers/staging/rockchip-mpp/Makefile new file mode 100644 index ..c35ea3a13461 --- /dev/null +++ b/drivers/staging/rockchip-mpp/Makefile @@ -0,0 +1,10 @@ +# SPDX-License-Identifier: GPL-2.0 +rk-mpp-service-objs := mpp_service.o +rk-mpp-device-objs := mpp_dev_common.o +rk-mpp-vdec-objs := mpp_dev_rkvdec.o rkvdec/hevc.o +rk-mpp-vdpu2-objs := mpp_dev_vdpu2.o vdpu2/mpeg2.o + +obj-$(CONFIG_ROCKCHIP_MPP_SERVICE) += rk-mpp-service.o +obj-$(CONFIG_ROCKCHIP_MPP_DEVICE) += rk-mpp-device.o +obj-$(CONFIG_ROCKCHIP_MPP_VDEC_DEVICE) += rk-mpp-vdec.o +obj-$(CONFIG_ROCKCHIP_MPP_VDPU2_DEVICE) += rk-mpp-vdpu2.o diff --git a/drivers/staging/rockchip-mpp/mpp_debug.h b/drivers/staging/rockchip-mpp/mpp_debug.h new file mode 100644 index ..bd6c0e594da3 --- /dev/null +++ b/drivers/staging/rockchip-mpp/mpp_debug.h @@ -0,0 +1,87 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Copyright (C) 2016 - 2017 Fuzhou Rockchip Electronics Co., Ltd + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more d
[PATCH v2 0/6] [WIP]: rockchip mpp for v4l2 video deocder
Although I really want to push those work after I added more codec supports, but I found it is more urge to do those in v4l2 core framework and userspace. I would use this driver to present the current problems, write down a summary here and I would reply to those threads later to push forward. 1. Slice construction is a bad idea. I think I have said my reason in the IRC and mail before, vp9 is always good example. And it would request the driver to update QP table/CABAC table every slice. I would make something to describe a buffer with some addtional meta data. But the current request API limit a buffer with associated with an request buffer, which prevent sharing some sequence data, but it still can solve some problems. 2. Advantage DMA memory control. I think I need to do some work at v4l2 core. 2.1 The DMA address of each planes. I have sent a mail before talked about why multiple planes is necessary for the rockchip platform. And it maybe required by the other platforms. 2.2 IOMMU resume The most effective way to restore the decoder from critical error is doing a restting by reset controller. Which would leading its slave IOMMU reset at the same time. Then none of those v4l2 buffers are mapping in the IOMMU. 3. H.264 and HEVC header I still think those structure have some not necessary fileds in dpb or reference part, which I don't think hardware decoder would care about that or can be predict from the other information. I would join to talk later. 4. The work flow of V4L2 I need a method to prepare the register set before the device acutally begin the transaction. Which is necessary for those high frame rate usecase. Also it is useful for those device would share some hardware resources with the other device and it can save more power. I think 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: rockchip: add video codec for rk3328 .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 32 + arch/arm64/boot/dts/rockchip/rk3328.dtsi | 116 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi |2 + drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/rockchip-mpp/Kconfig | 34 + drivers/staging/rockchip-mpp/Makefile | 10 + drivers/staging/rockchip-mpp/mpp_debug.h | 87 ++ drivers/staging/rockchip-mpp/mpp_dev_common.c | 1367 + drivers/staging/rockchip-mpp/mpp_dev_common.h | 212 +++ drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 997 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 619 drivers/staging/rockchip-mpp/mpp_service.c| 197 +++ drivers/staging/rockchip-mpp/mpp_service.h| 38 + drivers/staging/rockchip-mpp/rkvdec/hal.h | 63 + drivers/staging/rockchip-mpp/rkvdec/hevc.c| 166 ++ drivers/staging/rockchip-mpp/rkvdec/regs.h| 608 drivers/staging/rockchip-mpp/vdpu2/hal.h | 52 + drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 277 drivers/staging/rockchip-mpp/vdpu2/regs.h | 699 + 20 files changed, 5575 insertions(+), 4 deletions(-) create mode 100644 drivers/staging/rockchip-mpp/Kconfig create mode 100644 drivers/staging/rockchip-mpp/Makefile create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hevc.c create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h -- 2.20.1
[PATCH v2 4/6] staging: video: rockchip: add video codec
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/staging/Kconfig @@ -124,4 +124,6 @@ source "drivers/staging/axis-fifo/Kconfig" source "drivers/staging/erofs/Kconfig" +source "drivers/staging/rockchip-mpp/Kconfig" + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 57c6bce13ff4..fc3ed97a0eab 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -52,3 +52,4 @@ obj-$(CONFIG_SOC_MT7621) += mt7621-dts/ obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/ obj-$(CONFIG_XIL_AXIS_FIFO)+= axis-fifo/ obj-$(CONFIG_EROFS_FS) += erofs/ +obj-$(CONFIG_ROCKCHIP_MPP_SERVICE) += rockchip-mpp/ -- 2.20.1
Re: [PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
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
should probably still be considered staging for a short while.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
* Use timestamps instead of tags to reference frames,
* Applied Paul's suggestions to not require one frame worth of data per OUTPUT
buffer
One of the effects of requiring sub-frame units to be submitted per request is
that the stateless decoders are not exactly "stateless" anymore: if a frame is
made of several slices, then the decoder must keep track of the buffer in which
the current frame is being decoded between requests, and all the slices for the
current frame must be submitted before we can consider decoding the next one.
Also if we decide to force clients to submit one slice per request, then doesn't
some of the H.264 controls need to change? For instance, in the current v2
there is still a v4l2_ctrl_h264_decode_param::num_slices member. It is used in
Chromium to specify the number of slices given to the
V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS control, but is apparently ignored by the
No the rkvdec of rockchip need to know how many slices the current
picture has.
There are two mode for decoder, slice and frame mode. In the most of
case, it would work in frame mode and at the most of time, there would
be one slice for a picture. But when thing comes to the real time video
transmission, it can be various. It is hard to whether user want to
decode it in slice or frame, both of them having many use case.
And I saw there are some talking about a slice would be assigned with a
request, I wonder whether it is a good idea.
I know ayaka would be FOSDEM 2019, you can ask him about this.
Cedrus driver. Maxime, can you comment on this?
Documentation/media/uapi/v4l/dev-codec.rst| 5 +
.../media/uapi/v4l/dev-stateless-decoder.rst | 378 ++
2 files changed, 383 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst
diff --git a/Documentation/media/uapi/v4l/dev-codec.rst
b/Documentation/media/uapi/v4l/dev-codec.rst
index b5e017c17834..6ce38045d3c8 100644
--- a/Documentation/media/uapi/v4l/dev-codec.rst
+++ b/Documentation/media/uapi/v4l/dev-codec.rst
@@ -13,6 +13,11 @@
Codec Interface
***
+.. toctree::
+:maxdepth: 1
+
+dev-stateless-decoder
+
A V4L2 codec can compress, decompress, transform, or otherwise convert
video data from one format into another format, in memory. Typically
such devices are memory-to-memory devices (i.e. devices with the
diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
new file mode 100644
index ..148b1751dd20
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
@@ -0,0 +1,378 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _stateless_decoder:
+
+**
+Memory-to-memory Stateless Video Decoder Interface
+**
+
+A stateless decoder is a decoder that works without retaining any kind of state
+between processing frames. This means that each frame is decoded independently
+of any previous and future frames, and that the client is responsible for
+maintaining the decoding state and providing it to the decoder with each
+decoding request. This is in contrast to the stateful video decoder interface,
+where the hardware and driver maintain the decoding state and all the client
+has to do is to provide the raw encoded stream.
+
+This section describes how user-space ("the client") is expected to communicate
+with such decoders in order to successfully decode an encoded stream. Compared
+to stateful codecs, the decoder/client sequence is simpler, but the cost of
+this simplicity is extra complexity in the client which must maintain a
+consistent decoding state.
+
+Stateless decoders make use of the request API. A stateless decoder must thus
+expose the ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability on its ``OUTPUT``
queue
+when :c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS` are invoked.
+
+Querying capabilities
+=
+
+1. To enumerate the set of coded formats supported by the decoder, the client
+ calls :c:func:`VIDIOC_ENUM_FMT` on the ``OUTPUT`` queue.
+
+ * The driver must always return the full set of supported ``OUTPUT``
formats,
+ irrespective of the format currently set on the ``CAPTURE`` queue.
+
+ * Simultaneously, the driver must restrain the set of values returned by
+ codec-specific capability controls (such as H.264 profiles) to the set
+ actually supported by the hardware.
+
+2. To enumerate the set of supported raw
[PATCH v10 1/2] drm/fourcc: Add new P010, P016 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format.
P012 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.
V3: Added P012 and fixed cpp for P010.
V4: format definition refined per review.
V5: Format comment block for each new 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.
V8: reversed V7 changes except commit message and rebased.
v9: used the new properties to describe those 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/drivers/gpu/drm/drm_fourcc.c
index d90ee03a84c6..ba7e19d4336c 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -238,6 +238,15 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0b44260a5ee9..8dd1328bc8d6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -195,6 +195,27 @@ extern "C" {
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane 16 bits per channel */
+
/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
--
2.20.1
[PATCH v10 0/2] Add pixel format for 10 bits YUV video
As the requirement from: P010 fourcc format support - Was: Re: Kernel error "Unknown pixelformat 0x" occurs when I start capture video I don't know which device would support the P010, P012, P016 video pixel format, but Rockchip would support that NV12_10LE40 and a patch 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
[PATCH v10 2/2] drm/fourcc: add a 10bits fully packed variant of NV12
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 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index ba7e19d4336c..16d3be8278f1 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -247,6 +247,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2,
.char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2,
+ .char_per_block = { 5, 5, 0 }, .block_w = { 4, 2, 0 },
.block_h = { 1, 1, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
+ },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8dd1328bc8d6..4985fb19b4ce 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -194,6 +194,14 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * A fully packed 2 plane YCbCr
+ * Y1 0-9, Y2 10-19, Y3 20-29, Y4 20-39
+ *
+ * U1V1: 0-19, U2V2: 20-39
+ */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 2 plane YCbCr MSB aligned
--
2.20.1
Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls
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_HEVC_DPB_ENTRIES_NUM_MAX 16
+
+struct v4l2_hevc_dpb_entry {
+ __u32 buffer_tag;
+ __u8rps;
+ __u8field_pic;
+ __u16 pic_order_cnt[2];
+};
Please add a property for reference index, if that rps is not used for
this, some device would request that(not the rockchip one). And
Rockchip's VDPU1 and VDPU2 for AVC would request a similar property.
Adding another buffer_tag for referring the memory of the motion vectors
for each frames. Or a better method is add a meta data to echo picture
buffer, since the picture output is just the same as the original,
display won't care whether the motion vectors are written the button of
picture or somewhere else.
+
+struct v4l2_hevc_pred_weight_table {
+ __u8luma_log2_weight_denom;
+ __s8delta_chroma_log2_weight_denom;
+
+ __s8delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __s8luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __s8delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+ __s8chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+
+ __s8delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __s8luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __s8delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+ __s8chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+};
+
Those properties I think are not necessary are applying for the
Rockchip's device, may not work for the others.
+struct v4l2_ctrl_hevc_slice_params {
+ __u32 bit_size;
+ __u32 data_bit_offset;
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */
+ __u8nal_unit_type;
+ __u8nuh_temporal_id_plus1;
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
+ __u8slice_type;
+ __u8colour_plane_id;
+ __u16 slice_pic_order_cnt;
+ __u8slice_sao_luma_flag;
+ __u8slice_sao_chroma_flag;
+ __u8slice_temporal_mvp_enabled_flag;
+ __u8num_ref_idx_l0_active_minus1;
+ __u8num_ref_idx_l1_active_minus1;
Rockchip's decoder doesn't use this part.
+ __u8mvd_l1_zero_flag;
+ __u8cabac_init_flag;
+ __u8collocated_from_l0_flag;
+ __u8collocated_ref_idx;
+ __u8five_minus_max_num_merge_cand;
+ __u8use_integer_mv_flag;
+ __s8slice_qp_delta;
+ __s8slice_cb_qp_offset;
+ __s8slice_cr_qp_offset;
+ __s8slice_act_y_qp_offset;
+ __s8slice_act_cb_qp_offset;
+ __s8slice_act_cr_qp_offset;
+ __u8slice_deblocking_filter_disabled_flag;
+ __s8slice_beta_offset_div2;
+ __s8slice_tc_offset_div2;
+ __u8slice_loop_filter_across_slices_enabled_flag;
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture timing SEI message */
+ __u8pic_struct;
I think the decoder doesn't care about this, it is used for display.
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
+ struct v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __u8num_active_dpb_entries;
+ __u8ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __u8ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+
+ __u8num_rps_poc_st_curr_before;
+ __u8num_rps_poc_st_curr_after;
+ __u8num_rps_poc_lt_curr;
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: Weighted prediction parameter */
+ struct v4l2_hevc_pred_weight_table pred_weight_table;
+};
+
#endif
[PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399
It offers an example how a full features video codec
should be configured.
The original clocks assignment don't look good, if the clocks
lower than 300MHZ, most of decoing tasks would suffer from
timeout problem, 500MHZ is also a little high for RK3399
running in a stable state.
Signed-off-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/rk3399-sapphire.dtsi
index 946d3589575a..c3db878bae45 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -632,6 +632,35 @@
dr_mode = "host";
};
+ {
+ status = "okay";
+};
+
+_srv {
+ status = "okay";
+};
+
+_mmu {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_service {
+ status = "okay";
+};
+
+_mmu {
+ status = "okay";
+
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b22b2e40422b..5fa3247e7bf0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1242,16 +1242,39 @@
status = "disabled";
};
- vpu: video-codec@ff65 {
- compatible = "rockchip,rk3399-vpu";
- reg = <0x0 0xff65 0x0 0x800>;
- interrupts = ,
-;
- interrupt-names = "vepu", "vdpu";
+ vpu_service: vpu-srv {
+ compatible = "rockchip,mpp-service";
+ status = "disabled";
+ };
+
+ vepu: vpu-encoder@ff65 {
+ compatible = "rockchip,vpu-encoder-v2";
+ reg = <0x0 0xff65 0x0 0x400>;
+ interrupts = ;
+ interrupt-names = "irq_enc";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
- clock-names = "aclk", "hclk";
+ clock-names = "aclk_vcodec", "hclk_vcodec";
+ resets = < SRST_H_VCODEC>, < SRST_A_VCODEC>;
+ reset-names = "video_h", "video_a";
iommus = <_mmu>;
power-domains = < RK3399_PD_VCODEC>;
+ rockchip,srv = <_service>;
+ status = "disabled";
+ };
+
+ vdpu: vpu-decoder@ff650400 {
+ compatible = "rockchip,vpu-decoder-v2";
+ reg = <0x0 0xff650400 0x0 0x400>;
+ interrupts = ;
+ interrupt-names = "irq_dec";
+ iommus = <_mmu>;
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk_vcodec", "hclk_vcodec";
+ resets = < SRST_H_VCODEC>, < SRST_A_VCODEC>;
+ reset-names = "video_h", "video_a";
+ power-domains = < RK3399_PD_VCODEC>;
+ rockchip,srv = <_service>;
+ status = "disabled";
};
vpu_mmu: iommu@ff650800 {
@@ -1261,11 +1284,42 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ assigned-clocks = < ACLK_VCODEC_PRE>;
+ assigned-clock-parents = < PLL_GPLL>;
#iommu-cells = <0>;
power-domains = < RK3399_PD_VCODEC>;
status = "disabled";
};
+ rkvdec_srv: rkvdec-srv {
+ compatible = "rockchip,mpp-service";
+ status = "disabled";
+ };
+
+ rkvdec: video-decoder@ff66 {
+ compatible = "rockchip,video-decoder-v1";
+ reg = <0x0 0xff66 0x0 0x400>;
+ interrupts = ;
+ interrupt-names = "irq_dec";
+ clocks = < ACLK_VDU>, < HCLK_VDU>,
+< SCLK_VDU_CA>, < SCLK_VDU_CORE>;
+ clock-names = "aclk_vcodec", "hclk_vcodec",
+ "clk_cabac", "clk_core";
+ assigned-clocks = < ACLK_VDU_PRE>, < SCLK_VDU_CA>,
+ < SCLK_VDU_CORE>;
+ assigned-clock-parents = < PLL_NPLL>, < PLL_NPLL>,
+
[PATCH 1/4] staging: video: rockchip: video codec for vendor API
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/mpp_dev_common.h | 219 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 856 +++ drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c | 615 +++ drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 577 +++ drivers/staging/rockchip-mpp/mpp_dev_vepu1.c | 481 + drivers/staging/rockchip-mpp/mpp_dev_vepu2.c | 478 + drivers/staging/rockchip-mpp/mpp_iommu_dma.c | 292 ++ drivers/staging/rockchip-mpp/mpp_iommu_dma.h | 42 + drivers/staging/rockchip-mpp/mpp_service.c| 197 drivers/staging/rockchip-mpp/mpp_service.h| 38 + include/uapi/video/rk_vpu_service.h | 101 ++ 15 files changed, 5022 insertions(+) create mode 100644 drivers/staging/rockchip-mpp/Kconfig create mode 100644 drivers/staging/rockchip-mpp/Makefile create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vepu1.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vepu2.c create mode 100644 drivers/staging/rockchip-mpp/mpp_iommu_dma.c create mode 100644 drivers/staging/rockchip-mpp/mpp_iommu_dma.h create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h create mode 100644 include/uapi/video/rk_vpu_service.h diff --git a/drivers/staging/rockchip-mpp/Kconfig b/drivers/staging/rockchip-mpp/Kconfig new file mode 100644 index ..691ddc3bcd14 --- /dev/null +++ b/drivers/staging/rockchip-mpp/Kconfig @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0 +menu "ROCKCHIP_MPP" + depends on ARCH_ROCKCHIP + +config ROCKCHIP_MPP_SERVICE + tristate "mpp service scheduler" + default n + help + rockchip mpp service. + +config ROCKCHIP_MPP_DEVICE + tristate "mpp device framework" + depends on ROCKCHIP_MPP_SERVICE + default n + help + rockchip mpp device framework. + +config ROCKCHIP_MPP_VDEC_DEVICE + tristate "video decoder device driver" + depends on ROCKCHIP_MPP_DEVICE + default n + help + rockchip mpp video decoder and hevc decoder. + +config ROCKCHIP_MPP_VDPU1_DEVICE + tristate "VPU decoder v1 device driver" + depends on ROCKCHIP_MPP_DEVICE + default n + help + rockchip mpp vpu decoder v1. + +config ROCKCHIP_MPP_VEPU1_DEVICE + tristate "VPU encoder v1 device driver" + depends on ROCKCHIP_MPP_DEVICE + default n + help + rockchip mpp vpu encoder v1. + +config ROCKCHIP_MPP_VDPU2_DEVICE + tristate "VPU decoder v2 device driver" + depends on ROCKCHIP_MPP_DEVICE + default n + help + rockchip mpp vpu decoder v2. + +config ROCKCHIP_MPP_VEPU2_DEVICE + tristate "VPU encoder v2 device driver" + depends on ROCKCHIP_MPP_DEVICE + default n + help + rockchip mpp vpu encoder v2. +endmenu diff --git a/drivers/staging/rockchip-mpp/Makefile b/drivers/staging/rockchip-mpp/Makefile new file mode 100644 index ..06a9c58c92cb --- /dev/null +++ b/drivers/staging/rockchip-mpp/Makefile @@ -0,0 +1,16 @@ +# SPDX-License-Identifier: GPL-2.0 +rk-mpp-service-objs := mpp_service.o +rk-mpp-device-objs := mpp_dev_common.o mpp_iommu_dma.o +rk-mpp-vdec-objs := mpp_dev_rkvdec.o +rk-mpp-vdpu1-objs := mpp_dev_vdpu1.o +rk-mpp-vdpu2-objs := mpp_dev_vdpu2.o +rk-mpp-vepu1-objs := mpp_dev_vepu1.o +rk-mpp-vepu2-objs := mpp_dev_vepu2.o + +obj-$(CONFIG_ROCKCHIP_MPP_SERVICE) += rk-mpp-service.o +obj-$(CONFIG_ROCKCHIP_MPP_DEVICE) += rk-mpp-device.o +obj-$(CONFIG_ROCKCHIP_MPP_VDEC_DEVICE) += rk-mpp-vdec.o +obj-$(CONFIG_ROCKCHIP_MPP_VDPU1_DEVICE) += rk-mpp-vdpu1.o +obj-$(CONFIG_ROCKCHIP_MPP_VEPU1_DEVICE) += rk-mpp-vepu1.o +obj-$(CONFIG_ROCKCHIP_MPP_VDPU2_DEVICE) += rk-mpp-vdpu2.o +obj-$(CONFIG_ROCKCHIP_MPP_VEPU2_DEVICE) += rk-mpp-vepu2.o diff --git a/drivers/staging/rockchip-mpp/mpp_debug.h b/drivers/staging/rockchip-mpp/mpp_debug.h new file mode 100644 index ..bd6c0e594da3 --- /dev/null +++ b/drivers/staging/rockchip-mpp/mpp_debug.h @@ -0,0 +1,87 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Copyright (C) 2016 - 2017 Fuzhou Rockchip Electronics Co., Ltd + * + * This software is licensed under the terms of the GNU General Public + * Licens
[PATCH 3/4] staging: video: rockchip: add video codec
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 @@ -122,4 +122,6 @@ source "drivers/staging/axis-fifo/Kconfig" source "drivers/staging/erofs/Kconfig" +source "drivers/staging/rockchip-mpp/Kconfig" + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 5868631e8f1b..22499c68c21e 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -51,3 +51,4 @@ obj-$(CONFIG_SOC_MT7621) += mt7621-dts/ obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/ obj-$(CONFIG_XIL_AXIS_FIFO)+= axis-fifo/ obj-$(CONFIG_EROFS_FS) += erofs/ +obj-$(CONFIG_ROCKCHIP_MPP_SERVICE) += rockchip-mpp/ -- 2.20.1
[PATCH 2/4] staging: video: rockchip: fixup for upstream
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/rockchip-mpp/mpp_dev_rkvdec.c | 7 +++
drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c | 5 ++---
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 5 ++---
drivers/staging/rockchip-mpp/mpp_dev_vepu1.c | 5 ++---
drivers/staging/rockchip-mpp/mpp_dev_vepu2.c | 5 ++---
7 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.c
b/drivers/staging/rockchip-mpp/mpp_dev_common.c
index 159aa5d244ce..9a257c254d4d 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.c
@@ -937,18 +937,18 @@ EXPORT_SYMBOL(mpp_dev_read);
void mpp_debug_time_record(struct mpp_task *task)
{
if (unlikely(debug & DEBUG_TIMING) && task)
- do_gettimeofday(>start);
+ getboottime64(>start);
}
EXPORT_SYMBOL(mpp_debug_time_record);
void mpp_debug_time_diff(struct mpp_task *task)
{
- struct timeval end;
+ struct timespec64 end;
- do_gettimeofday();
- mpp_debug(DEBUG_TIMING, "time: %ld us\n",
- (end.tv_sec - task->start.tv_sec) * 100 +
- (end.tv_usec - task->start.tv_usec));
+ getboottime64();
+ mpp_debug(DEBUG_TIMING, "time: %lld ms\n",
+ (end.tv_sec - task->start.tv_sec) * 1000 +
+ (end.tv_nsec - task->start.tv_nsec) / 100);
}
EXPORT_SYMBOL(mpp_debug_time_diff);
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.h
b/drivers/staging/rockchip-mpp/mpp_dev_common.h
index 8a7dc7444dc3..76d53ec2c452 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.h
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.h
@@ -124,7 +124,7 @@ struct mpp_task {
struct work_struct work;
/* record context running start time */
- struct timeval start;
+ struct timespec64 start;
};
/*
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
b/drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
index a3da27cfc10e..44d76eba901f 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
@@ -19,10 +19,10 @@
#include
#include
#include
-#include
#include
#include
#include
+#include
#include "mpp_debug.h"
#include "mpp_dev_common.h"
@@ -230,8 +230,7 @@ static int fill_scaling_list_pps(struct rkvdec_task *task,
int fd, int offset,
return -ENOENT;
}
- ret = dma_buf_begin_cpu_access(dmabuf, 0, dmabuf->size,
- DMA_FROM_DEVICE);
+ ret = dma_buf_begin_cpu_access(dmabuf, DMA_FROM_DEVICE);
if (ret) {
dev_err(dev, "can't access the pps buffer\n");
goto done;
@@ -277,7 +276,7 @@ static int fill_scaling_list_pps(struct rkvdec_task *task,
int fd, int offset,
done:
dma_buf_vunmap(dmabuf, vaddr);
- dma_buf_end_cpu_access(dmabuf, 0, dmabuf->size, DMA_FROM_DEVICE);
+ dma_buf_end_cpu_access(dmabuf, DMA_FROM_DEVICE);
dma_buf_put(dmabuf);
return ret;
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c
index 4371a1a6080b..63ffd79bfe83 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c
@@ -460,9 +460,8 @@ static int rockchip_mpp_rkvdpu_assign_reset(struct
rockchip_rkvdpu_dev *dec_dev)
{
struct rockchip_mpp_dev *mpp_dev = _dev->mpp_dev;
- /* TODO: use devm_reset_control_get_share() instead */
- dec_dev->rst_a = devm_reset_control_get(mpp_dev->dev, "video_a");
- dec_dev->rst_h = devm_reset_control_get(mpp_dev->dev, "video_h");
+ dec_dev->rst_a = devm_reset_control_get_shared(mpp_dev->dev, "video_a");
+ dec_dev->rst_h = devm_reset_control_get_shared(mpp_dev->dev, "video_h");
if (IS_ERR_OR_NULL(dec_dev->rst_a)) {
mpp_err("No aclk reset resource define\n");
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
index b131790f72a3..5789c8940543 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
@@ -428,9 +428,8 @@ static int rockchip_mpp_rkvdpu_assign_reset(struct
rockchip_rkvdpu_dev *dec_dev)
{
struct rockchip_mpp_dev *mpp_dev = _dev->mpp_dev;
- /* TODO: use devm_reset_control_get_share() instead */
- dec_dev->rst_a = devm_reset_control_get(mpp_dev->dev, "video_a");
- dec_dev->rst_h = devm_rese
[PATCH 0/4] Rockchip: the vendor video codec for reference
Those patches are not for merging, I won't dream on it. As I said in previous email, this driver is used for checking the status of the other drivers. I have checked this driver would memory dump, its output looks well. The reason I didn't use the video output is VOP driver doesn't work well. Also I want to offer a reference for those people who want to develop the V4L2 request API driver for Rockchip and you can use this driver to comparing the result as well. I should said either the one for sunxi nor chromium have not reached the vendor production level. I want to point out the obvious problem of the current V4L2 driver, I think that is the one I developed years ago and refresh it in the last year, then it is merged now. That driver won't aware the parallel problem between the devices. The video codec in Rockchip is very complex, the decoder and encoder are NOT paired in some platforms. Also a decoder or encoder can share some resource with the other decoder or encoder, requesting a mux in the GRF device. We call those devices sharing resource a combo, they may or may not having a individual IOMMU for each of its child devices. Also any of those devies allowing support less codecs than its full state. The RK3328 is a good example of that, - | Video decoder for H264, VP8, JPEG, MPEG-4 Part 2 | Video decoder for AVS+ | | Video decoder for H265, H265, VP9 | | Video encoder for H265, - | Video encoder for H264, JPEG - that is why I rewrote the device tree files in these patches, the current device tree is not suitable for the other platforms. Besides, the V4L2 driver don't support the error correction and tolerance or status recovery. That is more about the parser in the userspace but a common parser won't be able to do that, different video codec vendor would request a different method, also V4L2 request API is not suitable to feedback status. Anyway, the current developing for decoder is at lease acceptable for those simple situations. But I think encoder would become a big issue, lucky, it seems that nobody care about encoder. If you have ever looked the video encoder for chromium, you would feel disgusted, it is not Google's fault, just not suitable for V4L2. I don't want to talk much about encoder here, basially the encoder is much simpler than decoder requesting less dynamic settings, but those dynamic settings request a more real time feedback or related. I don't see much advantage the V4L2 brings, only the compatibility left. The previous vendor driver would have DMA buffer problem but it is solved in this one. Ndufresne told me about buffer fencing, but I don't think it is useful only complication. That is why I didn't develop the V4L2 for a long time. I would 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 for rk3399 .../boot/dts/rockchip/rk3399-sapphire.dtsi| 29 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 68 +- drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + 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/mpp_dev_common.h | 219 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 855 +++ drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c | 614 +++ drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 576 +++ drivers/staging/rockchip-mpp/mpp_dev_vepu1.c | 480 + drivers/staging/rockchip-mpp/mpp_dev_vepu2.c | 477 + drivers/staging/rockchip-mpp/mpp_iommu_dma.c | 292 ++ drivers/staging/rockchip-mpp/mpp_iommu_dma.h | 42 + drivers/staging/rockchip-mpp/mpp_service.c| 197 drivers/staging/rockchip-mpp/mpp_service.h| 38 + include/uapi/video/rk_vpu_service.h | 101 ++ 19 files changed, 5110 insertions(+), 7 deletions(-) create mode 100644 drivers/staging/rockchip-mpp/Kconfig create mode 100644 drivers/staging/rockchip-mpp/Makefile create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vepu1.c
[PATCH 2/3] arm64: dts: rockchip: add power domain to iommu rk3399
IOMMU device won't work without power unless PMU
can't turn it off.
Signed-off-by: Randy Li
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6cc1c9fa4ea6..b22b2e40422b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1263,6 +1263,7 @@
clock-names = "aclk", "iface";
#iommu-cells = <0>;
power-domains = < RK3399_PD_VCODEC>;
+ status = "disabled";
};
vdec_mmu: iommu@ff660480 {
@@ -1273,6 +1274,7 @@
clocks = < ACLK_VDU>, < HCLK_VDU>;
clock-names = "aclk", "iface";
#iommu-cells = <0>;
+ power-domains = < RK3399_PD_VDU>;
status = "disabled";
};
--
2.20.1
[PATCH 1/3] clk: rockchip: add video clk parents for rk3399
Video codec won't work properly with a clock too low nor
too high. We need to export them, allowing the device
tree to assign a suitable clocks for them.
Signed-off-by: Randy Li
---
drivers/clk/rockchip/clk-rk3399.c | 5 +++--
include/dt-bindings/clock/rk3399-cru.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index 5a628148f3f0..fe6cebcb26b6 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -740,7 +740,8 @@ static struct rockchip_clk_branch rk3399_clk_branches[]
__initdata = {
RK3399_CLKGATE_CON(15), 6, GFLAGS),
/* vcodec */
- COMPOSITE(0, "aclk_vcodec_pre", mux_pll_src_cpll_gpll_npll_ppll_p, 0,
+ COMPOSITE(ACLK_VCODEC_PRE, "aclk_vcodec_pre",
+ mux_pll_src_cpll_gpll_npll_ppll_p, 0,
RK3399_CLKSEL_CON(7), 6, 2, MFLAGS, 0, 5, DFLAGS,
RK3399_CLKGATE_CON(4), 0, GFLAGS),
COMPOSITE_NOMUX(0, "hclk_vcodec_pre", "aclk_vcodec_pre", 0,
@@ -764,7 +765,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[]
__initdata = {
RK3399_CLKSEL_CON(9), 14, 2, MFLAGS, 8, 5, DFLAGS,
RK3399_CLKGATE_CON(4), 5, GFLAGS),
- COMPOSITE(0, "aclk_vdu_pre", mux_pll_src_cpll_gpll_npll_ppll_p, 0,
+ COMPOSITE(ACLK_VDU_PRE, "aclk_vdu_pre",
mux_pll_src_cpll_gpll_npll_ppll_p, 0,
RK3399_CLKSEL_CON(8), 6, 2, MFLAGS, 0, 5, DFLAGS,
RK3399_CLKGATE_CON(4), 2, GFLAGS),
COMPOSITE_NOMUX(0, "hclk_vdu_pre", "aclk_vdu_pre", 0,
diff --git a/include/dt-bindings/clock/rk3399-cru.h
b/include/dt-bindings/clock/rk3399-cru.h
index 22cb1dfa9004..dd13554aaf76 100644
--- a/include/dt-bindings/clock/rk3399-cru.h
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -219,6 +219,8 @@
#define ACLK_GIC_PRE 262
#define ACLK_VOP0_PRE 263
#define ACLK_VOP1_PRE 264
+#define ACLK_VCODEC_PRE265
+#define ACLK_VDU_PRE 266
/* pclk gates */
#define PCLK_PERIHP320
--
2.20.1
[PATCH 0/3] The basic patches for rockchip video codec
I will post a driver for video codec using the vendor userspace interface. It is not used for merging but checking the work status of the other devices and pre-patches need to be merged. Without the following modification, video codec can't work properly. I check the status of the upstream kernel for rockchip, network, eMMC, USB and VOP work much worse and slow than the vendor kernel. I think the video codec driver would be a good example to verify the other drivers. Randy Li (3): clk: rockchip: add video clk parents for rk3399 arm64: dts: rockchip: add power domain to iommu rk3399 soc: rockchip: power-domain: export idle request arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++ drivers/clk/rockchip/clk-rk3399.c| 5 +++-- drivers/soc/rockchip/pm_domains.c| 23 +++ include/dt-bindings/clock/rk3399-cru.h | 2 ++ include/soc/rockchip/pm_domains.h| 18 ++ 5 files changed, 48 insertions(+), 2 deletions(-) create mode 100644 include/soc/rockchip/pm_domains.h -- 2.20.1
[PATCH 3/3] soc: rockchip: power-domain: export idle request
We need to put the power status of HEVC IP into IDLE unless
we can't reset that IP or the SoC would crash down.
rockchip_pmu_idle_request(dev, true)---> enter idle
rockchip_pmu_idle_request(dev, false)---> exit idle
Signed-off-by: Caesar Wang
Signed-off-by: Jeffy Chen
Signed-off-by: Randy Li
---
drivers/soc/rockchip/pm_domains.c | 23 +++
include/soc/rockchip/pm_domains.h | 18 ++
2 files changed, 41 insertions(+)
create mode 100644 include/soc/rockchip/pm_domains.h
diff --git a/drivers/soc/rockchip/pm_domains.c
b/drivers/soc/rockchip/pm_domains.c
index 847c7c482b26..3e2e252cb64b 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -199,6 +199,29 @@ static int rockchip_pmu_set_idle_request(struct
rockchip_pm_domain *pd,
return 0;
}
+int rockchip_pmu_idle_request(struct device *dev, bool idle)
+{
+ struct generic_pm_domain *genpd;
+ struct rockchip_pm_domain *pd;
+ int ret;
+
+ if (IS_ERR_OR_NULL(dev))
+ return -EINVAL;
+
+ if (IS_ERR_OR_NULL(dev->pm_domain))
+ return -EINVAL;
+
+ genpd = pd_to_genpd(dev->pm_domain);
+ pd = to_rockchip_pd(genpd);
+
+ mutex_lock(>pmu->mutex);
+ ret = rockchip_pmu_set_idle_request(pd, idle);
+ mutex_unlock(>pmu->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(rockchip_pmu_idle_request);
+
static int rockchip_pmu_save_qos(struct rockchip_pm_domain *pd)
{
int i;
diff --git a/include/soc/rockchip/pm_domains.h
b/include/soc/rockchip/pm_domains.h
new file mode 100644
index ..690db6118636
--- /dev/null
+++ b/include/soc/rockchip/pm_domains.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __SOC_ROCKCHIP_PM_DOMAINS_H
+#define __SOC_ROCKCHIP_PM_DOMAINS_H
+
+#include
+
+struct device;
+
+#ifdef CONFIG_ROCKCHIP_PM_DOMAINS
+int rockchip_pmu_idle_request(struct device *dev, bool idle);
+#else
+static inline int rockchip_pmu_idle_request(struct device *dev, bool idle)
+{
+ return -ENOTSUPP;
+}
+#endif
+
+#endif
--
2.20.1
[PATCH v2 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
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/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.4
[PATCH v2 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
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/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.4
[PATCH v2] ARM64: dts: rockchip: add some pins to rk3399
Those pins would be used by many boards.
Signed-off-by: Randy Li
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 87 +++-
1 file changed, 73 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e0040b648f43..f32d1a049550 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1936,19 +1936,49 @@
drive-strength = <12>;
};
+ pcfg_pull_none_13ma: pcfg-pull-none-13ma {
+ bias-disable;
+ drive-strength = <13>;
+ };
+
+ pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+ bias-disable;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_none_20ma: pcfg-pull-none-20ma {
+ bias-disable;
+ drive-strength = <20>;
+ };
+
+ pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
};
+ pcfg_pull_up_18ma: pcfg-pull-up-18ma {
+ bias-pull-up;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_up_20ma: pcfg-pull-up-20ma {
+ bias-pull-up;
+ drive-strength = <20>;
+ };
+
pcfg_pull_down_4ma: pcfg-pull-down-4ma {
bias-pull-down;
drive-strength = <4>;
};
- pcfg_pull_up_2ma: pcfg-pull-up-2ma {
- bias-pull-up;
- drive-strength = <2>;
+ pcfg_pull_down_8ma: pcfg-pull-down-8ma {
+ bias-pull-down;
+ drive-strength = <8>;
};
pcfg_pull_down_12ma: pcfg-pull-down-12ma {
@@ -1956,9 +1986,22 @@
drive-strength = <12>;
};
- pcfg_pull_none_13ma: pcfg-pull-none-13ma {
- bias-disable;
- drive-strength = <13>;
+ pcfg_pull_down_18ma: pcfg-pull-down-18ma {
+ bias-pull-down;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_down_20ma: pcfg-pull-down-20ma {
+ bias-pull-down;
+ drive-strength = <20>;
+ };
+
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
};
clock {
@@ -2481,45 +2524,61 @@
pwm0 {
pwm0_pin: pwm0-pin {
rockchip,pins =
- <4 18 RK_FUNC_1 _pull_none>;
+ <4 RK_PC2 RK_FUNC_1 _pull_none>;
+ };
+
+ pwm0_pin_pull_down: pwm0-pin-pull-down {
+ rockchip,pins =
+ <4 RK_PC2 RK_FUNC_1 _pull_down>;
};
vop0_pwm_pin: vop0-pwm-pin {
rockchip,pins =
- <4 18 RK_FUNC_2 _pull_none>;
+ <4 RK_PC2 RK_FUNC_2 _pull_none>;
+ };
+
+ vop1_pwm_pin: vop1-pwm-pin {
+ rockchip,pins =
+ <4 RK_PC2 RK_FUNC_3 _pull_none>;
};
+
};
pwm1 {
pwm1_pin: pwm1-pin {
rockchip,pins =
- <4 22 RK_FUNC_1 _pull_none>;
+ <4 RK_PC6 RK_FUNC_1 _pull_none>;
};
- vop1_pwm_pin: vop1-pwm-pin {
+ pwm1_pin_pull_down: pwm1-pin-pull-down {
rockchip,pins =
- <4 18 RK_FUNC_3 _pull_none>;
+ <4 RK_PC6 RK_FUNC_1 _pull_down>;
};
};
pwm2 {
pwm2_pin: pwm2-pin {
rockchip,pins =
- <1 19 RK_FUNC_1 _pull_none
[PATCH v2] ARM64: dts: rockchip: add some pins to rk3399
Those pins would be used by many boards.
Signed-off-by: Randy Li
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 87 +++-
1 file changed, 73 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e0040b648f43..f32d1a049550 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1936,19 +1936,49 @@
drive-strength = <12>;
};
+ pcfg_pull_none_13ma: pcfg-pull-none-13ma {
+ bias-disable;
+ drive-strength = <13>;
+ };
+
+ pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+ bias-disable;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_none_20ma: pcfg-pull-none-20ma {
+ bias-disable;
+ drive-strength = <20>;
+ };
+
+ pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
};
+ pcfg_pull_up_18ma: pcfg-pull-up-18ma {
+ bias-pull-up;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_up_20ma: pcfg-pull-up-20ma {
+ bias-pull-up;
+ drive-strength = <20>;
+ };
+
pcfg_pull_down_4ma: pcfg-pull-down-4ma {
bias-pull-down;
drive-strength = <4>;
};
- pcfg_pull_up_2ma: pcfg-pull-up-2ma {
- bias-pull-up;
- drive-strength = <2>;
+ pcfg_pull_down_8ma: pcfg-pull-down-8ma {
+ bias-pull-down;
+ drive-strength = <8>;
};
pcfg_pull_down_12ma: pcfg-pull-down-12ma {
@@ -1956,9 +1986,22 @@
drive-strength = <12>;
};
- pcfg_pull_none_13ma: pcfg-pull-none-13ma {
- bias-disable;
- drive-strength = <13>;
+ pcfg_pull_down_18ma: pcfg-pull-down-18ma {
+ bias-pull-down;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_down_20ma: pcfg-pull-down-20ma {
+ bias-pull-down;
+ drive-strength = <20>;
+ };
+
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
};
clock {
@@ -2481,45 +2524,61 @@
pwm0 {
pwm0_pin: pwm0-pin {
rockchip,pins =
- <4 18 RK_FUNC_1 _pull_none>;
+ <4 RK_PC2 RK_FUNC_1 _pull_none>;
+ };
+
+ pwm0_pin_pull_down: pwm0-pin-pull-down {
+ rockchip,pins =
+ <4 RK_PC2 RK_FUNC_1 _pull_down>;
};
vop0_pwm_pin: vop0-pwm-pin {
rockchip,pins =
- <4 18 RK_FUNC_2 _pull_none>;
+ <4 RK_PC2 RK_FUNC_2 _pull_none>;
+ };
+
+ vop1_pwm_pin: vop1-pwm-pin {
+ rockchip,pins =
+ <4 RK_PC2 RK_FUNC_3 _pull_none>;
};
+
};
pwm1 {
pwm1_pin: pwm1-pin {
rockchip,pins =
- <4 22 RK_FUNC_1 _pull_none>;
+ <4 RK_PC6 RK_FUNC_1 _pull_none>;
};
- vop1_pwm_pin: vop1-pwm-pin {
+ pwm1_pin_pull_down: pwm1-pin-pull-down {
rockchip,pins =
- <4 18 RK_FUNC_3 _pull_none>;
+ <4 RK_PC6 RK_FUNC_1 _pull_down>;
};
};
pwm2 {
pwm2_pin: pwm2-pin {
rockchip,pins =
- <1 19 RK_FUNC_1 _pull_none
[PATCH] ARM64: dts: rockchip: add some pins to rk3399
Those pins would be used by many boards.
Signed-off-by: Randy Li
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 97 +++-
1 file changed, 83 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e0040b648f43..9fa629857929 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -160,7 +160,7 @@
};
};
- display-subsystem {
+ display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <_out>, <_out>;
};
@@ -1936,19 +1936,49 @@
drive-strength = <12>;
};
+ pcfg_pull_none_13ma: pcfg-pull-none-13ma {
+ bias-disable;
+ drive-strength = <13>;
+ };
+
+ pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+ bias-disable;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_none_20ma: pcfg-pull-none-20ma {
+ bias-disable;
+ drive-strength = <20>;
+ };
+
+ pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
};
+ pcfg_pull_up_18ma: pcfg-pull-up-18ma {
+ bias-pull-up;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_up_20ma: pcfg-pull-up-20ma {
+ bias-pull-up;
+ drive-strength = <20>;
+ };
+
pcfg_pull_down_4ma: pcfg-pull-down-4ma {
bias-pull-down;
drive-strength = <4>;
};
- pcfg_pull_up_2ma: pcfg-pull-up-2ma {
- bias-pull-up;
- drive-strength = <2>;
+ pcfg_pull_down_8ma: pcfg-pull-down-8ma {
+ bias-pull-down;
+ drive-strength = <8>;
};
pcfg_pull_down_12ma: pcfg-pull-down-12ma {
@@ -1956,9 +1986,22 @@
drive-strength = <12>;
};
- pcfg_pull_none_13ma: pcfg-pull-none-13ma {
- bias-disable;
- drive-strength = <13>;
+ pcfg_pull_down_18ma: pcfg-pull-down-18ma {
+ bias-pull-down;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_down_20ma: pcfg-pull-down-20ma {
+ bias-pull-down;
+ drive-strength = <18>;
+ };
+
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
};
clock {
@@ -2484,10 +2527,21 @@
<4 18 RK_FUNC_1 _pull_none>;
};
+ pwm0_pin_pull_down: pwm0-pin-pull-down {
+ rockchip,pins =
+ <4 18 RK_FUNC_1 _pull_down>;
+ };
+
vop0_pwm_pin: vop0-pwm-pin {
rockchip,pins =
<4 18 RK_FUNC_2 _pull_none>;
};
+
+ vop1_pwm_pin: vop1-pwm-pin {
+ rockchip,pins =
+ <4 18 RK_FUNC_3 _pull_none>;
+ };
+
};
pwm1 {
@@ -2496,9 +2550,9 @@
<4 22 RK_FUNC_1 _pull_none>;
};
- vop1_pwm_pin: vop1-pwm-pin {
+ pwm1_pin_pull_down: pwm1-pin-pull-down {
rockchip,pins =
- <4 18 RK_FUNC_3 _pull_none>;
+ <4 22 RK_FUNC_1 _pull_down>;
};
};
@@ -2507,6 +2561,11 @@
rockchip,pins =
<1 19 RK_FUNC_1 _pull_none>;
};
+
+ pwm2_pin_pull_down: pwm2-pin-pull-down {
+ rockchip,pins =
+ <1 19 RK_FUNC_1 _pull_
[PATCH] ARM64: dts: rockchip: add some pins to rk3399
Those pins would be used by many boards.
Signed-off-by: Randy Li
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 97 +++-
1 file changed, 83 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e0040b648f43..9fa629857929 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -160,7 +160,7 @@
};
};
- display-subsystem {
+ display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <_out>, <_out>;
};
@@ -1936,19 +1936,49 @@
drive-strength = <12>;
};
+ pcfg_pull_none_13ma: pcfg-pull-none-13ma {
+ bias-disable;
+ drive-strength = <13>;
+ };
+
+ pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+ bias-disable;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_none_20ma: pcfg-pull-none-20ma {
+ bias-disable;
+ drive-strength = <20>;
+ };
+
+ pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
};
+ pcfg_pull_up_18ma: pcfg-pull-up-18ma {
+ bias-pull-up;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_up_20ma: pcfg-pull-up-20ma {
+ bias-pull-up;
+ drive-strength = <20>;
+ };
+
pcfg_pull_down_4ma: pcfg-pull-down-4ma {
bias-pull-down;
drive-strength = <4>;
};
- pcfg_pull_up_2ma: pcfg-pull-up-2ma {
- bias-pull-up;
- drive-strength = <2>;
+ pcfg_pull_down_8ma: pcfg-pull-down-8ma {
+ bias-pull-down;
+ drive-strength = <8>;
};
pcfg_pull_down_12ma: pcfg-pull-down-12ma {
@@ -1956,9 +1986,22 @@
drive-strength = <12>;
};
- pcfg_pull_none_13ma: pcfg-pull-none-13ma {
- bias-disable;
- drive-strength = <13>;
+ pcfg_pull_down_18ma: pcfg-pull-down-18ma {
+ bias-pull-down;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_down_20ma: pcfg-pull-down-20ma {
+ bias-pull-down;
+ drive-strength = <18>;
+ };
+
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
};
clock {
@@ -2484,10 +2527,21 @@
<4 18 RK_FUNC_1 _pull_none>;
};
+ pwm0_pin_pull_down: pwm0-pin-pull-down {
+ rockchip,pins =
+ <4 18 RK_FUNC_1 _pull_down>;
+ };
+
vop0_pwm_pin: vop0-pwm-pin {
rockchip,pins =
<4 18 RK_FUNC_2 _pull_none>;
};
+
+ vop1_pwm_pin: vop1-pwm-pin {
+ rockchip,pins =
+ <4 18 RK_FUNC_3 _pull_none>;
+ };
+
};
pwm1 {
@@ -2496,9 +2550,9 @@
<4 22 RK_FUNC_1 _pull_none>;
};
- vop1_pwm_pin: vop1-pwm-pin {
+ pwm1_pin_pull_down: pwm1-pin-pull-down {
rockchip,pins =
- <4 18 RK_FUNC_3 _pull_none>;
+ <4 22 RK_FUNC_1 _pull_down>;
};
};
@@ -2507,6 +2561,11 @@
rockchip,pins =
<1 19 RK_FUNC_1 _pull_none>;
};
+
+ pwm2_pin_pull_down: pwm2-pin-pull-down {
+ rockchip,pins =
+ <1 19 RK_FUNC_1 _pull_
Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
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.
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
Hm, the cpp value might give problems because it rounds down, not sure how we
should handle that? Set to zero?
It is default behavior that using the filed "cpp" to calculate the
pixel in many drivers. I would suggest use a new filed called bits per
pixel (bpp) instead of the old cpp.
The one used in the Gstreamer is more complex:
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-GstVideoAlignment.html#GstVideoFormatInfo
As the struct drm_format_info only a kernel internal data structure, it
doesn't need to update the user-space interface like libdrm.
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
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.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
Hm, the cpp value might give problems because it rounds down, not sure how we
should handle that? Set to zero?
It is default behavior that using the filed "cpp" to calculate the
pixel in many drivers. I would suggest use a new filed called bits per
pixel (bpp) instead of the old cpp.
The one used in the Gstreamer is more complex:
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-GstVideoAlignment.html#GstVideoFormatInfo
As the struct drm_format_info only a kernel internal data structure, it
doesn't need to update the user-space interface like libdrm.
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
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 <ay...@soulik.info>
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.3
[PATCH 2/2] drm/rockchip: Support 10 bits yuv format in vop
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 <ay...@soulik.info>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..6a54b20501ac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV12_10LE40:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,6 +250,17 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV12_10LE40:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool is_yuv_10bit(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV12_10LE40:
return true;
default:
return false;
@@ -711,6 +723,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
@@ -728,6 +741,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ is_10_bits = is_yuv_10bit(fb->format->format);
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -742,7 +757,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (fb->format->cpp[0] * 5 / 4);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -753,6 +772,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -761,7 +781,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (bpp * 5 / 4) / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084acdd0019a..d9ec993f420a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -131,6 +131,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08023d3ecb76..5393886ddd95 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,7 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV12_10LE40,
};
static const uint32_t formats_win_lite[] = {
@@ -215,6 +216,7 @@ static const struct vop_win_phy rk3288_win01_data = {
.nformats = ARRAY_SIZE(formats_win_full),
[PATCH 0/2] Add support for a YUV 10bits pixel format
This pixel format is current used in the rockchip platform. I think any model higher than rk322x would support this pixel format. Xilinx may support it but I am not sure. More than a year ago, I post the patch Add pixel formats for 10/16 bits YUV video to the mail list, it has been update to version 8, but they are not merged yet. So I decide to submit these independent patches, I hope that they would be reviewed and merged in a short time. I have added a patch to Gstreamer and it is merged now. Any future information can be found on the bugzilla of the Gstreamer: https://bugzilla.gnome.org/show_bug.cgi?id=795462 I have verified this patch on the rk3288, with the following command: gst-launch-1.0 filesrc location=conv_3840_2160.nv12_10le40 ! \ rawvideoparse format=81 width=3840 height=2160 ! imagefreeze ! kmssink Also you can find video sample video on above page, but you may 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 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++ include/uapi/drm/drm_fourcc.h | 3 +++ 5 files changed, 32 insertions(+), 2 deletions(-) -- 2.14.3
[PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
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/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.3
[PATCH 2/2] drm/rockchip: Support 10 bits yuv format in vop
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/rockchip/rockchip_drm_vop.c | 27 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..6a54b20501ac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV12_10LE40:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,6 +250,17 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV12_10LE40:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool is_yuv_10bit(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV12_10LE40:
return true;
default:
return false;
@@ -711,6 +723,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
@@ -728,6 +741,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ is_10_bits = is_yuv_10bit(fb->format->format);
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -742,7 +757,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (fb->format->cpp[0] * 5 / 4);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -753,6 +772,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -761,7 +781,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (bpp * 5 / 4) / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084acdd0019a..d9ec993f420a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -131,6 +131,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08023d3ecb76..5393886ddd95 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,7 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV12_10LE40,
};
static const uint32_t formats_win_lite[] = {
@@ -215,6 +216,7 @@ static const struct vop_win_phy rk3288_win01_data = {
.nformats = ARRAY_SIZE(formats_win_full),
.enable = VOP_RE
[PATCH 0/2] Add support for a YUV 10bits pixel format
This pixel format is current used in the rockchip platform. I think any model higher than rk322x would support this pixel format. Xilinx may support it but I am not sure. More than a year ago, I post the patch Add pixel formats for 10/16 bits YUV video to the mail list, it has been update to version 8, but they are not merged yet. So I decide to submit these independent patches, I hope that they would be reviewed and merged in a short time. I have added a patch to Gstreamer and it is merged now. Any future information can be found on the bugzilla of the Gstreamer: https://bugzilla.gnome.org/show_bug.cgi?id=795462 I have verified this patch on the rk3288, with the following command: gst-launch-1.0 filesrc location=conv_3840_2160.nv12_10le40 ! \ rawvideoparse format=81 width=3840 height=2160 ! imagefreeze ! kmssink Also you can find video sample video on above page, but you may 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 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++ include/uapi/drm/drm_fourcc.h | 3 +++ 5 files changed, 32 insertions(+), 2 deletions(-) -- 2.14.3
Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU
On 01/22/2018 12:09 PM, JeffyChen wrote: Hi Randy, On 01/22/2018 10:15 AM, JeffyChen wrote: Hi Randy, On 01/22/2018 09:18 AM, Randy Li wrote: Also the power domain driver could manage the clocks as well, I would suggest to use pm_runtime_*. actually the clocks required by pm domain may not be the same as what we want to control here, there might be some clocks only be needed when accessing mmu registers. but i'm not very sure about that, will confirm it with Simon Xue. confirmed with Simon, there might be some iommus don't have a pd, and We use the pd to control the NIU node(not on upstream), without a pd or fake pd, none of the platform would work. the CONFIG_PM could be disabled.I am hard to believe a modern platform can work without that. so it might be better to control clocks in iommu driver itself.I won't insist how the version of the iommu patch on the upstream, I just post an idea here. The version for kernel 4.4 is under internal review, the implementation has been modified many times. I would suggest the managing clocks in pd is a more easy way and don't need to spare those thing in two places. ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- Randy Li
Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU
On 01/22/2018 12:09 PM, JeffyChen wrote: Hi Randy, On 01/22/2018 10:15 AM, JeffyChen wrote: Hi Randy, On 01/22/2018 09:18 AM, Randy Li wrote: Also the power domain driver could manage the clocks as well, I would suggest to use pm_runtime_*. actually the clocks required by pm domain may not be the same as what we want to control here, there might be some clocks only be needed when accessing mmu registers. but i'm not very sure about that, will confirm it with Simon Xue. confirmed with Simon, there might be some iommus don't have a pd, and We use the pd to control the NIU node(not on upstream), without a pd or fake pd, none of the platform would work. the CONFIG_PM could be disabled.I am hard to believe a modern platform can work without that. so it might be better to control clocks in iommu driver itself.I won't insist how the version of the iommu patch on the upstream, I just post an idea here. The version for kernel 4.4 is under internal review, the implementation has been modified many times. I would suggest the managing clocks in pd is a more easy way and don't need to spare those thing in two places. ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- Randy Li
Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU
On 01/18/2018 10:25 PM, JeffyChen wrote: Hi Robin, On 01/18/2018 08:27 PM, Robin Murphy wrote: Is it worth using the clk_bulk_*() APIs for this? At a glance, most of the code being added here appears to duplicate what those functions already do (but I'm no clk API expert, for sure). right, i think it's doable, the clk_bulk APIs are very helpful. i think we didn't use that is because this patch were wrote for the chromeos 4.4 kernel, which doesn't have clk_bulk yet:) will do it in the next version, thanks. Also the power domain driver could manage the clocks as well, I would suggest to use pm_runtime_*. Robin. ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- Randy Li
Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU
On 01/18/2018 10:25 PM, JeffyChen wrote: Hi Robin, On 01/18/2018 08:27 PM, Robin Murphy wrote: Is it worth using the clk_bulk_*() APIs for this? At a glance, most of the code being added here appears to duplicate what those functions already do (but I'm no clk API expert, for sure). right, i think it's doable, the clk_bulk APIs are very helpful. i think we didn't use that is because this patch were wrote for the chromeos 4.4 kernel, which doesn't have clk_bulk yet:) will do it in the next version, thanks. Also the power domain driver could manage the clocks as well, I would suggest to use pm_runtime_*. Robin. ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- Randy Li
Re: [PATCH 1/5] [media] rockchip/rga: v4l2 m2m support
On 06/27/2017 11:49 PM, Nicolas Dufresne wrote: Le mardi 27 juin 2017 à 23:11 +0800, Jacob Chen a écrit : Hi Nicolas. 2017-06-26 23:49 GMT+08:00 Nicolas Dufresne <nico...@ndufresne.ca>: Le lundi 26 juin 2017 à 22:51 +0800, Jacob Chen a écrit : Rockchip RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D graphics operations, such as point/line drawing, image scaling, rotation, BitBLT, alpha blending and image blur/sharpness. The drvier is mostly based on s5p-g2d v4l2 m2m driver. And supports various operations from the rendering pipeline. - copy - fast solid color fill - rotation - flip - alpha blending The code in rga-hw.c is used to configure regs accroding to operations. The code in rga-buf.c is used to create private mmu table for RGA. The tables is stored in a list, and be removed when buffer is cleanup. Signed-off-by: Jacob Chen <jacob-c...@iotwrt.com> --- drivers/media/platform/Kconfig| 11 + drivers/media/platform/Makefile | 2 + drivers/media/platform/rockchip-rga/Makefile | 3 + drivers/media/platform/rockchip-rga/rga-buf.c | 176 + drivers/media/platform/rockchip-rga/rga-hw.c | 456 drivers/media/platform/rockchip-rga/rga-hw.h | 434 drivers/media/platform/rockchip-rga/rga.c | 979 ++ drivers/media/platform/rockchip-rga/rga.h | 133 8 files changed, 2194 insertions(+) create mode 100644 drivers/media/platform/rockchip-rga/Makefile create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h create mode 100644 drivers/media/platform/rockchip-rga/rga.c create mode 100644 drivers/media/platform/rockchip-rga/rga.h Could be nice to generalize. We could setup a control and fill the values base on porter duff operations, then drivers can implement a subset. Right now, there is no generic way for userspace to know if a driver is just doing copies with some transformations, or if it can actually do alpha blending hence used for composting streams. Note that I haven't looked at all possibilities, Freescale IMX.6 seems to have a similar driver, which has been wrapped in GStreamer with this proposed elements: https://bugzilla.gnome.org/show_bug.cgi?id=772766 Yeah, i also want it use a generic api. "porter duff operations" looks good, i will look at it. +#define V4L2_CID_RGA_ALHPA_REG0 (V4L2_CID_USER_BASE | 0x1002) +#define V4L2_CID_RGA_ALHPA_REG1 (V4L2_CID_USER_BASE | 0x1003) It's not obvious why there is two CID, and how this differ from existing V4L2_CID_ALPHA (the global alpha control). They are used to calculate factors for below formulas. dst alpha = Factor1 * src alpha + Factor2 * dst alpha dst color = Factor3 * src color + Factor4 * dst color I have no idea how to generalize it, and there is no upstream application need it, so i just simply exposed the reg. In my memory, it is is used for convert AYUV to ARGB. Then maybe it's better to just not expose it in the public API in the initial patch (nothing forces you to enable everything). The idea is that it can be added later as needed, taking the time to figure-out a new API or to figure-out how this matches anything that exist. + +/* Operation values */ +#define OP_COPY 0 +#define OP_SOLID_FILL 1 +#define OP_ALPHA_BLEND 2 + +struct rga_frame *rga_get_frame(struct rga_ctx *ctx, enum v4l2_buf_type type); + +/* RGA Buffers Manage Part */ +extern const struct vb2_ops rga_qops; +void *rga_buf_find_page(struct vb2_buffer *vb); +void rga_buf_clean(struct rga_ctx *ctx); + +/* RGA Hardware Part */ +void rga_write(struct rockchip_rga *rga, u32 reg, u32 value); +u32 rga_read(struct rockchip_rga *rga, u32 reg); +void rga_mod(struct rockchip_rga *rga, u32 reg, u32 val, u32 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
Re: [PATCH 1/5] [media] rockchip/rga: v4l2 m2m support
On 06/27/2017 11:49 PM, Nicolas Dufresne wrote: Le mardi 27 juin 2017 à 23:11 +0800, Jacob Chen a écrit : Hi Nicolas. 2017-06-26 23:49 GMT+08:00 Nicolas Dufresne : Le lundi 26 juin 2017 à 22:51 +0800, Jacob Chen a écrit : Rockchip RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D graphics operations, such as point/line drawing, image scaling, rotation, BitBLT, alpha blending and image blur/sharpness. The drvier is mostly based on s5p-g2d v4l2 m2m driver. And supports various operations from the rendering pipeline. - copy - fast solid color fill - rotation - flip - alpha blending The code in rga-hw.c is used to configure regs accroding to operations. The code in rga-buf.c is used to create private mmu table for RGA. The tables is stored in a list, and be removed when buffer is cleanup. Signed-off-by: Jacob Chen --- drivers/media/platform/Kconfig| 11 + drivers/media/platform/Makefile | 2 + drivers/media/platform/rockchip-rga/Makefile | 3 + drivers/media/platform/rockchip-rga/rga-buf.c | 176 + drivers/media/platform/rockchip-rga/rga-hw.c | 456 drivers/media/platform/rockchip-rga/rga-hw.h | 434 drivers/media/platform/rockchip-rga/rga.c | 979 ++ drivers/media/platform/rockchip-rga/rga.h | 133 8 files changed, 2194 insertions(+) create mode 100644 drivers/media/platform/rockchip-rga/Makefile create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h create mode 100644 drivers/media/platform/rockchip-rga/rga.c create mode 100644 drivers/media/platform/rockchip-rga/rga.h Could be nice to generalize. We could setup a control and fill the values base on porter duff operations, then drivers can implement a subset. Right now, there is no generic way for userspace to know if a driver is just doing copies with some transformations, or if it can actually do alpha blending hence used for composting streams. Note that I haven't looked at all possibilities, Freescale IMX.6 seems to have a similar driver, which has been wrapped in GStreamer with this proposed elements: https://bugzilla.gnome.org/show_bug.cgi?id=772766 Yeah, i also want it use a generic api. "porter duff operations" looks good, i will look at it. +#define V4L2_CID_RGA_ALHPA_REG0 (V4L2_CID_USER_BASE | 0x1002) +#define V4L2_CID_RGA_ALHPA_REG1 (V4L2_CID_USER_BASE | 0x1003) It's not obvious why there is two CID, and how this differ from existing V4L2_CID_ALPHA (the global alpha control). They are used to calculate factors for below formulas. dst alpha = Factor1 * src alpha + Factor2 * dst alpha dst color = Factor3 * src color + Factor4 * dst color I have no idea how to generalize it, and there is no upstream application need it, so i just simply exposed the reg. In my memory, it is is used for convert AYUV to ARGB. Then maybe it's better to just not expose it in the public API in the initial patch (nothing forces you to enable everything). The idea is that it can be added later as needed, taking the time to figure-out a new API or to figure-out how this matches anything that exist. + +/* Operation values */ +#define OP_COPY 0 +#define OP_SOLID_FILL 1 +#define OP_ALPHA_BLEND 2 + +struct rga_frame *rga_get_frame(struct rga_ctx *ctx, enum v4l2_buf_type type); + +/* RGA Buffers Manage Part */ +extern const struct vb2_ops rga_qops; +void *rga_buf_find_page(struct vb2_buffer *vb); +void rga_buf_clean(struct rga_ctx *ctx); + +/* RGA Hardware Part */ +void rga_write(struct rockchip_rga *rga, u32 reg, u32 value); +u32 rga_read(struct rockchip_rga *rga, u32 reg); +void rga_mod(struct rockchip_rga *rga, u32 reg, u32 val, u32 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
[PATCH v2] ARM: dts: rockchip: add adc button for Firefly
The only adc button connected to adc input is recovery button.
Signed-off-by: Randy Li <ay...@soulik.info>
---
arch/arm/boot/dts/rk3288-firefly-reload.dts | 17 +
arch/arm/boot/dts/rk3288-firefly.dtsi | 13 +
2 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts
b/arch/arm/boot/dts/rk3288-firefly-reload.dts
index d0b3204a..b11a282 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
@@ -48,6 +48,19 @@
model = "Firefly-RK3288-reload";
compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -246,6 +259,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
bus-width = <4>;
cap-mmc-highspeed;
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 10793ac..b4b31a1 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -49,6 +49,19 @@
reg = <0 0x8000>;
};
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
dovdd_1v8: dovdd-1v8-regulator {
compatible = "regulator-fixed";
regulator-name = "dovdd_1v8";
--
2.9.4
[PATCH v2] ARM: dts: rockchip: add adc button for Firefly
The only adc button connected to adc input is recovery button.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/rk3288-firefly-reload.dts | 17 +
arch/arm/boot/dts/rk3288-firefly.dtsi | 13 +
2 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts
b/arch/arm/boot/dts/rk3288-firefly-reload.dts
index d0b3204a..b11a282 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
@@ -48,6 +48,19 @@
model = "Firefly-RK3288-reload";
compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -246,6 +259,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
bus-width = <4>;
cap-mmc-highspeed;
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 10793ac..b4b31a1 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -49,6 +49,19 @@
reg = <0 0x8000>;
};
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
dovdd_1v8: dovdd-1v8-regulator {
compatible = "regulator-fixed";
regulator-name = "dovdd_1v8";
--
2.9.4
[PATCH] clk: rockchip: rk3288: prefer vdpu for vcodec clock source
The RK3288 CRU system clock solution would suggest use
the vdpu clock source for the VPU(aclk_vpu and hclk_vpu).
Reading the registers of VPU(both VEPU and VDPU) would become all high
when the vepu is used as the clock source. It may be a bug in the SoC,
not sure whether it is fixed at RK3288W.
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/clk/rockchip/clk-rk3288.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 68ba7d4..886b249 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -198,7 +198,7 @@ PNAME(mux_hsadcout_p) = { "hsadc_src", "ext_hsadc" };
PNAME(mux_edp_24m_p) = { "ext_edp_24m", "xin24m" };
PNAME(mux_tspout_p)= { "cpll", "gpll", "npll", "xin27m" };
-PNAME(mux_aclk_vcodec_pre_p) = { "aclk_vepu", "aclk_vdpu" };
+PNAME(mux_aclk_vcodec_pre_p) = { "aclk_vdpu", "aclk_vepu" };
PNAME(mux_usbphy480m_p)= { "sclk_otgphy1_480m",
"sclk_otgphy2_480m",
"sclk_otgphy0_480m" };
PNAME(mux_hsicphy480m_p) = { "cpll", "gpll", "usbphy480m_src" };
--
2.9.3
[PATCH] clk: rockchip: rk3288: prefer vdpu for vcodec clock source
The RK3288 CRU system clock solution would suggest use
the vdpu clock source for the VPU(aclk_vpu and hclk_vpu).
Reading the registers of VPU(both VEPU and VDPU) would become all high
when the vepu is used as the clock source. It may be a bug in the SoC,
not sure whether it is fixed at RK3288W.
Signed-off-by: Randy Li
---
drivers/clk/rockchip/clk-rk3288.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 68ba7d4..886b249 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -198,7 +198,7 @@ PNAME(mux_hsadcout_p) = { "hsadc_src", "ext_hsadc" };
PNAME(mux_edp_24m_p) = { "ext_edp_24m", "xin24m" };
PNAME(mux_tspout_p)= { "cpll", "gpll", "npll", "xin27m" };
-PNAME(mux_aclk_vcodec_pre_p) = { "aclk_vepu", "aclk_vdpu" };
+PNAME(mux_aclk_vcodec_pre_p) = { "aclk_vdpu", "aclk_vepu" };
PNAME(mux_usbphy480m_p)= { "sclk_otgphy1_480m",
"sclk_otgphy2_480m",
"sclk_otgphy0_480m" };
PNAME(mux_hsicphy480m_p) = { "cpll", "gpll", "usbphy480m_src" };
--
2.9.3
Re: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
On 05/09/2017 03:40 PM, Guillaume Tucker wrote: On 09/05/17 02:16, Randy Li wrote: On 05/09/2017 12:27 AM, Heiko Stübner wrote: Am Mittwoch, 3. Mai 2017, 10:56:24 CEST schrieb Guillaume Tucker: The ARM Mali Midgard GPU kernel driver is only available out-of-tree and is not going to be merged in its current form. However, it would be useful to have its device tree bindings merged. In particular, this would enable distributions to create working driver packages (dkms...) without having to patch the kernel. The bindings for the earlier Mali Utgard GPU family have already been merged, so this is essentially the same scenario but for newer GPUs (Mali-T604 ~ Mali-T880). This series of patches first imports the bindings from the latest driver release with some clean-up then adds a gpu node for the rk3288 SoC. This was successfully tested on Radxa Rock2 Square, Firefly, Veyron Minnie and Jerry boards using Mali kernel driver r16p0 and r12p0 user-space binary. I won't suggest such combine. We meet some problems at mali 400 serial. I would suggest the kernel version would match the user library. Well, I can test it again with r12p0 kernel driver (out-of-tree) if you want. The user-space driver checks the version of the kernel driver and gives up if it's not compatible. With Midgard, there's a range of versions that maintain kernel/userspace compatibility unlike Utgard and older Midgard releases where they had to exactly match. Again, if there was a mismatch then the user-space would fail to initialise and report an error. Anyway, could you verify the mali userspace library r13p0? Rockchip would use this version to offer the support of X11, wayland and gbm. Also please notice there is rk3288w, the hardware version becomes r1p0. Sounds like a new SoC? Does rk3288w affect rk3288 in any way? It is not a new SoC, just a new version of rk3288. It fixes a various of the chip bug of the rk3288. Unless it's a special case, it seems to me that any new SoC with a Midgard GPU would need an extra vendor compatible string in the binding documentation and maybe a separate gpu dt node. The actual devicetree parts are all Rockchip-specific, so I guess I'll just pick up the whole series, including the binding doc, after the merge window if nobody complains before that :-) Thanks! Guillaume -- Randy Li
Re: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
On 05/09/2017 03:40 PM, Guillaume Tucker wrote: On 09/05/17 02:16, Randy Li wrote: On 05/09/2017 12:27 AM, Heiko Stübner wrote: Am Mittwoch, 3. Mai 2017, 10:56:24 CEST schrieb Guillaume Tucker: The ARM Mali Midgard GPU kernel driver is only available out-of-tree and is not going to be merged in its current form. However, it would be useful to have its device tree bindings merged. In particular, this would enable distributions to create working driver packages (dkms...) without having to patch the kernel. The bindings for the earlier Mali Utgard GPU family have already been merged, so this is essentially the same scenario but for newer GPUs (Mali-T604 ~ Mali-T880). This series of patches first imports the bindings from the latest driver release with some clean-up then adds a gpu node for the rk3288 SoC. This was successfully tested on Radxa Rock2 Square, Firefly, Veyron Minnie and Jerry boards using Mali kernel driver r16p0 and r12p0 user-space binary. I won't suggest such combine. We meet some problems at mali 400 serial. I would suggest the kernel version would match the user library. Well, I can test it again with r12p0 kernel driver (out-of-tree) if you want. The user-space driver checks the version of the kernel driver and gives up if it's not compatible. With Midgard, there's a range of versions that maintain kernel/userspace compatibility unlike Utgard and older Midgard releases where they had to exactly match. Again, if there was a mismatch then the user-space would fail to initialise and report an error. Anyway, could you verify the mali userspace library r13p0? Rockchip would use this version to offer the support of X11, wayland and gbm. Also please notice there is rk3288w, the hardware version becomes r1p0. Sounds like a new SoC? Does rk3288w affect rk3288 in any way? It is not a new SoC, just a new version of rk3288. It fixes a various of the chip bug of the rk3288. Unless it's a special case, it seems to me that any new SoC with a Midgard GPU would need an extra vendor compatible string in the binding documentation and maybe a separate gpu dt node. The actual devicetree parts are all Rockchip-specific, so I guess I'll just pick up the whole series, including the binding doc, after the merge window if nobody complains before that :-) Thanks! Guillaume -- Randy Li
Re: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
On 05/09/2017 12:27 AM, Heiko Stübner wrote: Am Mittwoch, 3. Mai 2017, 10:56:24 CEST schrieb Guillaume Tucker: The ARM Mali Midgard GPU kernel driver is only available out-of-tree and is not going to be merged in its current form. However, it would be useful to have its device tree bindings merged. In particular, this would enable distributions to create working driver packages (dkms...) without having to patch the kernel. The bindings for the earlier Mali Utgard GPU family have already been merged, so this is essentially the same scenario but for newer GPUs (Mali-T604 ~ Mali-T880). This series of patches first imports the bindings from the latest driver release with some clean-up then adds a gpu node for the rk3288 SoC. This was successfully tested on Radxa Rock2 Square, Firefly, Veyron Minnie and Jerry boards using Mali kernel driver r16p0 and r12p0 user-space binary. I won't suggest such combine. We meet some problems at mali 400 serial. I would suggest the kernel version would match the user library. Also please notice there is rk3288w, the hardware version becomes r1p0. The actual devicetree parts are all Rockchip-specific, so I guess I'll just pick up the whole series, including the binding doc, after the merge window if nobody complains before that :-) Heiko ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- Randy Li
Re: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
On 05/09/2017 12:27 AM, Heiko Stübner wrote: Am Mittwoch, 3. Mai 2017, 10:56:24 CEST schrieb Guillaume Tucker: The ARM Mali Midgard GPU kernel driver is only available out-of-tree and is not going to be merged in its current form. However, it would be useful to have its device tree bindings merged. In particular, this would enable distributions to create working driver packages (dkms...) without having to patch the kernel. The bindings for the earlier Mali Utgard GPU family have already been merged, so this is essentially the same scenario but for newer GPUs (Mali-T604 ~ Mali-T880). This series of patches first imports the bindings from the latest driver release with some clean-up then adds a gpu node for the rk3288 SoC. This was successfully tested on Radxa Rock2 Square, Firefly, Veyron Minnie and Jerry boards using Mali kernel driver r16p0 and r12p0 user-space binary. I won't suggest such combine. We meet some problems at mali 400 serial. I would suggest the kernel version would match the user library. Also please notice there is rk3288w, the hardware version becomes r1p0. The actual devicetree parts are all Rockchip-specific, so I guess I'll just pick up the whole series, including the binding doc, after the merge window if nobody complains before that :-) Heiko ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- Randy Li
[PATCH] soc: rockchip: power-domain: export idle request
We need to put the power status of HEVC/RKVDEC IP into IDLE
unless we can't reset that IP or the SoC would crash down.
rockchip_pmu_idle_request(dev, true)---> enter idle
rockchip_pmu_idle_request(dev, false)---> exit idle
Only the video codec drivers of rockchip platform would
request this patch currently.
I am not sure whether it is necessary to add a new function
at generic power domain. I want someone give me some advises
here.
Signed-off-by: Caesar Wang <w...@rock-chips.com>
Signed-off-by: Jeffy Chen <jeffy.c...@rock-chips.com>
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/soc/rockchip/pm_domains.c | 24
include/linux/rockchip_pmu.h | 15 +++
2 files changed, 39 insertions(+)
create mode 100644 include/linux/rockchip_pmu.h
diff --git a/drivers/soc/rockchip/pm_domains.c
b/drivers/soc/rockchip/pm_domains.c
index 796c46a..c1bff1c 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -179,6 +180,29 @@ static int rockchip_pmu_set_idle_request(struct
rockchip_pm_domain *pd,
return 0;
}
+int rockchip_pmu_idle_request(struct device *dev, bool idle)
+{
+ struct generic_pm_domain *genpd;
+ struct rockchip_pm_domain *pd;
+ int ret;
+
+ if (IS_ERR_OR_NULL(dev))
+ return -EINVAL;
+
+ if (IS_ERR_OR_NULL(dev->pm_domain))
+ return -EINVAL;
+
+ genpd = pd_to_genpd(dev->pm_domain);
+ pd = to_rockchip_pd(genpd);
+
+ mutex_lock(>pmu->mutex);
+ ret = rockchip_pmu_set_idle_request(pd, idle);
+ mutex_unlock(>pmu->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(rockchip_pmu_idle_request);
+
static int rockchip_pmu_save_qos(struct rockchip_pm_domain *pd)
{
int i;
diff --git a/include/linux/rockchip_pmu.h b/include/linux/rockchip_pmu.h
new file mode 100644
index 000..720b331
--- /dev/null
+++ b/include/linux/rockchip_pmu.h
@@ -0,0 +1,15 @@
+/*
+ * pm_domain.h - Definitions and headers related to device power domains.
+ *
+ * Copyright (C) 2017 Randy Li <ay...@soulik.info>.
+ *
+ * This file is released under the GPLv2.
+ */
+
+#ifndef _LINUX_ROCKCHIP_PM_H
+#define _LINUX_ROCKCHIP_PM_H
+#include
+
+int rockchip_pmu_idle_request(struct device *dev, bool idle);
+
+#endif /* _LINUX_ROCKCHIP_PM_H */
--
2.9.3
[PATCH] soc: rockchip: power-domain: export idle request
We need to put the power status of HEVC/RKVDEC IP into IDLE
unless we can't reset that IP or the SoC would crash down.
rockchip_pmu_idle_request(dev, true)---> enter idle
rockchip_pmu_idle_request(dev, false)---> exit idle
Only the video codec drivers of rockchip platform would
request this patch currently.
I am not sure whether it is necessary to add a new function
at generic power domain. I want someone give me some advises
here.
Signed-off-by: Caesar Wang
Signed-off-by: Jeffy Chen
Signed-off-by: Randy Li
---
drivers/soc/rockchip/pm_domains.c | 24
include/linux/rockchip_pmu.h | 15 +++
2 files changed, 39 insertions(+)
create mode 100644 include/linux/rockchip_pmu.h
diff --git a/drivers/soc/rockchip/pm_domains.c
b/drivers/soc/rockchip/pm_domains.c
index 796c46a..c1bff1c 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -179,6 +180,29 @@ static int rockchip_pmu_set_idle_request(struct
rockchip_pm_domain *pd,
return 0;
}
+int rockchip_pmu_idle_request(struct device *dev, bool idle)
+{
+ struct generic_pm_domain *genpd;
+ struct rockchip_pm_domain *pd;
+ int ret;
+
+ if (IS_ERR_OR_NULL(dev))
+ return -EINVAL;
+
+ if (IS_ERR_OR_NULL(dev->pm_domain))
+ return -EINVAL;
+
+ genpd = pd_to_genpd(dev->pm_domain);
+ pd = to_rockchip_pd(genpd);
+
+ mutex_lock(>pmu->mutex);
+ ret = rockchip_pmu_set_idle_request(pd, idle);
+ mutex_unlock(>pmu->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(rockchip_pmu_idle_request);
+
static int rockchip_pmu_save_qos(struct rockchip_pm_domain *pd)
{
int i;
diff --git a/include/linux/rockchip_pmu.h b/include/linux/rockchip_pmu.h
new file mode 100644
index 000..720b331
--- /dev/null
+++ b/include/linux/rockchip_pmu.h
@@ -0,0 +1,15 @@
+/*
+ * pm_domain.h - Definitions and headers related to device power domains.
+ *
+ * Copyright (C) 2017 Randy Li .
+ *
+ * This file is released under the GPLv2.
+ */
+
+#ifndef _LINUX_ROCKCHIP_PM_H
+#define _LINUX_ROCKCHIP_PM_H
+#include
+
+int rockchip_pmu_idle_request(struct device *dev, bool idle);
+
+#endif /* _LINUX_ROCKCHIP_PM_H */
--
2.9.3
[PATCH v2] ARM: dts: rockchip: add eDP panel support for Firefly
This patch adds the supporting to the eDP panel sold by
the T-CHIP for the Firefly RK3288. I assign the VOP lite
for the eDP panel and VOP big to HDMI, as the HDMI supports
4K resolution. With a different VOP device, eDP panel
and HDMI could display a different contents.
The InvenSense MPU6050 sensor at the botton of the panel
is also enabled.
The Firefly RK3288 Reload use a different GPIO pin to enable
the power of the eDP panel.
Signed-off-by: Randy Li <ay...@soulik.info>
---
arch/arm/boot/dts/rk3288-firefly.dtsi | 112 ++
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 436878b..db22316 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -62,6 +62,62 @@
};
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <
+ 3 4 5 6 7
+ 8 9 10 11 12 13 14 15
+16 17 18 19 20 21 22 23
+24 25 26 27 28 29 30 31
+32 33 34 35 36 37 38 39
+40 41 42 43 44 45 46 47
+48 49 50 51 52 53 54 55
+56 57 58 59 60 61 62 63
+64 65 66 67 68 69 70 71
+72 73 74 75 76 77 78 79
+80 81 82 83 84 85 86 87
+88 89 90 91 92 93 94 95
+96 97 98 99 100 101 102 103
+ 104 105 106 107 108 109 110 111
+ 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127
+ 128 129 130 131 132 133 134 135
+ 136 137 138 139 140 141 142 143
+ 144 145 146 147 148 149 150 151
+ 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167
+ 168 169 170 171 172 173 174 175
+ 176 177 178 179 180 181 182 183
+ 184 185 186 187 188 189 190 191
+ 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207
+ 208 209 210 211 212 213 214 215
+ 216 217 218 219 220 221 222 223
+ 224 225 226 227 228 229 230 231
+ 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247
+ 248 249 250 251 252 253 254 255>;
+ default-brightness-level = <180>;
+ pwms = < 0 25000 0>;
+ pwm-names = "backlight";
+ power-supply = <_sys>;
+ };
+
+ panel: panel {
+ compatible ="lg,lp079qx1-sp0v";
+ power-supply = <_sys>;
+ backlight = <>;
+ enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ panel_in: port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+ };
+
dovdd_1v8: dovdd-1v8-regulator {
compatible = "regulator-fixed";
regulator-name = "dovdd_1v8";
@@ -203,6 +259,32 @@
cpu0-supply = <_cpu>;
};
+ {
+ vcc-supply = <_10>;
+ vccio-supply = <_18>;
+ status = "okay";
+
+ ports {
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <_in_edp>;
+ };
+ };
+ };
+};
+
+_in {
+ /delete-node/ endpoint@0;
+};
+
+_phy {
+ status = "okay";
+};
+
{
bus-width = <8>;
cap-mmc-highspeed;
@@ -240,8 +322,14 @@
{
ddc-i2c-bus = <>;
status = "okay";
+
+};
+
+_in {
+ /delete-node/ endpoint@1;
};
+
{
clock-frequency = <40>;
status = "okay";
@@ -385,6 +473,22 @@
{
status = "okay";
+
+ mpu6050@68 {
+ compatible = "invensense,mpu6050";
+ reg = <0x68>;
+ interrupt-parent = <>;
+ interrupts = ;
+ mount-matrix = "0",
+ &quo
[PATCH v2] ARM: dts: rockchip: add eDP panel support for Firefly
This patch adds the supporting to the eDP panel sold by
the T-CHIP for the Firefly RK3288. I assign the VOP lite
for the eDP panel and VOP big to HDMI, as the HDMI supports
4K resolution. With a different VOP device, eDP panel
and HDMI could display a different contents.
The InvenSense MPU6050 sensor at the botton of the panel
is also enabled.
The Firefly RK3288 Reload use a different GPIO pin to enable
the power of the eDP panel.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/rk3288-firefly.dtsi | 112 ++
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 436878b..db22316 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -62,6 +62,62 @@
};
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <
+ 3 4 5 6 7
+ 8 9 10 11 12 13 14 15
+16 17 18 19 20 21 22 23
+24 25 26 27 28 29 30 31
+32 33 34 35 36 37 38 39
+40 41 42 43 44 45 46 47
+48 49 50 51 52 53 54 55
+56 57 58 59 60 61 62 63
+64 65 66 67 68 69 70 71
+72 73 74 75 76 77 78 79
+80 81 82 83 84 85 86 87
+88 89 90 91 92 93 94 95
+96 97 98 99 100 101 102 103
+ 104 105 106 107 108 109 110 111
+ 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127
+ 128 129 130 131 132 133 134 135
+ 136 137 138 139 140 141 142 143
+ 144 145 146 147 148 149 150 151
+ 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167
+ 168 169 170 171 172 173 174 175
+ 176 177 178 179 180 181 182 183
+ 184 185 186 187 188 189 190 191
+ 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207
+ 208 209 210 211 212 213 214 215
+ 216 217 218 219 220 221 222 223
+ 224 225 226 227 228 229 230 231
+ 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247
+ 248 249 250 251 252 253 254 255>;
+ default-brightness-level = <180>;
+ pwms = < 0 25000 0>;
+ pwm-names = "backlight";
+ power-supply = <_sys>;
+ };
+
+ panel: panel {
+ compatible ="lg,lp079qx1-sp0v";
+ power-supply = <_sys>;
+ backlight = <>;
+ enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ panel_in: port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+ };
+
dovdd_1v8: dovdd-1v8-regulator {
compatible = "regulator-fixed";
regulator-name = "dovdd_1v8";
@@ -203,6 +259,32 @@
cpu0-supply = <_cpu>;
};
+ {
+ vcc-supply = <_10>;
+ vccio-supply = <_18>;
+ status = "okay";
+
+ ports {
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <_in_edp>;
+ };
+ };
+ };
+};
+
+_in {
+ /delete-node/ endpoint@0;
+};
+
+_phy {
+ status = "okay";
+};
+
{
bus-width = <8>;
cap-mmc-highspeed;
@@ -240,8 +322,14 @@
{
ddc-i2c-bus = <>;
status = "okay";
+
+};
+
+_in {
+ /delete-node/ endpoint@1;
};
+
{
clock-frequency = <40>;
status = "okay";
@@ -385,6 +473,22 @@
{
status = "okay";
+
+ mpu6050@68 {
+ compatible = "invensense,mpu6050";
+ reg = <0x68>;
+ interrupt-parent = <>;
+ interrupts = ;
+ mount-matrix = "0",
+ "1&qu
[PATCH] ARM: dts: rockchip: add adc button for Firefly
The only adc button connected to adc input is recovery button.
Signed-off-by: Randy Li <ay...@soulik.info>
---
arch/arm/boot/dts/rk3288-firefly-reload.dts | 17 +
arch/arm/boot/dts/rk3288-firefly.dtsi | 13 +
2 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts
b/arch/arm/boot/dts/rk3288-firefly-reload.dts
index d0b3204a..ed1baa8 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
@@ -48,6 +48,19 @@
model = "Firefly-RK3288-reload";
compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -246,6 +259,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
bus-width = <4>;
cap-mmc-highspeed;
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 10793ac..63b8b2d 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -49,6 +49,19 @@
reg = <0 0x8000>;
};
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
dovdd_1v8: dovdd-1v8-regulator {
compatible = "regulator-fixed";
regulator-name = "dovdd_1v8";
--
2.9.3
[PATCH] ARM: dts: rockchip: add adc button for Firefly
The only adc button connected to adc input is recovery button.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/rk3288-firefly-reload.dts | 17 +
arch/arm/boot/dts/rk3288-firefly.dtsi | 13 +
2 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts
b/arch/arm/boot/dts/rk3288-firefly-reload.dts
index d0b3204a..ed1baa8 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
@@ -48,6 +48,19 @@
model = "Firefly-RK3288-reload";
compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -246,6 +259,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
bus-width = <4>;
cap-mmc-highspeed;
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 10793ac..63b8b2d 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -49,6 +49,19 @@
reg = <0 0x8000>;
};
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
dovdd_1v8: dovdd-1v8-regulator {
compatible = "regulator-fixed";
regulator-name = "dovdd_1v8";
--
2.9.3
[PATCH 1/2] ARM: dts: rockchip: add eDP panel support for Firefly
This patch adds the supporting to the eDP panel sold by
the T-CHIP for the Firefly RK3288.
The InvenSense MPU6050 sensor at the botton of the panel
is also enabled.
The Firefly RK3288 Reload use a different GPIO pin to enable
the power of the eDP panel.
Signed-off-by: Randy Li <ay...@soulik.info>
---
arch/arm/boot/dts/rk3288-firefly.dtsi | 92 +++
1 file changed, 92 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 436878b..786cfb7 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -62,6 +62,62 @@
};
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <
+ 3 4 5 6 7
+ 8 9 10 11 12 13 14 15
+16 17 18 19 20 21 22 23
+24 25 26 27 28 29 30 31
+32 33 34 35 36 37 38 39
+40 41 42 43 44 45 46 47
+48 49 50 51 52 53 54 55
+56 57 58 59 60 61 62 63
+64 65 66 67 68 69 70 71
+72 73 74 75 76 77 78 79
+80 81 82 83 84 85 86 87
+88 89 90 91 92 93 94 95
+96 97 98 99 100 101 102 103
+ 104 105 106 107 108 109 110 111
+ 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127
+ 128 129 130 131 132 133 134 135
+ 136 137 138 139 140 141 142 143
+ 144 145 146 147 148 149 150 151
+ 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167
+ 168 169 170 171 172 173 174 175
+ 176 177 178 179 180 181 182 183
+ 184 185 186 187 188 189 190 191
+ 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207
+ 208 209 210 211 212 213 214 215
+ 216 217 218 219 220 221 222 223
+ 224 225 226 227 228 229 230 231
+ 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247
+ 248 249 250 251 252 253 254 255>;
+ default-brightness-level = <180>;
+ pwms = < 0 25000 0>;
+ pwm-names = "backlight";
+ power-supply = <_sys>;
+ };
+
+ panel: panel {
+ compatible ="lg,lp079qx1-sp0v";
+ power-supply = <_sys>;
+ backlight = <>;
+ enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ panel_in: port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+ };
+
dovdd_1v8: dovdd-1v8-regulator {
compatible = "regulator-fixed";
regulator-name = "dovdd_1v8";
@@ -203,6 +259,26 @@
cpu0-supply = <_cpu>;
};
+ {
+ vcc-supply = <_lcd>;
+ vccio-supply = <_18>;
+ ports {
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <_in_edp>;
+ };
+ };
+ };
+};
+
+_phy {
+ status = "okay";
+};
+
{
bus-width = <8>;
cap-mmc-highspeed;
@@ -385,6 +461,22 @@
{
status = "okay";
+
+ mpu6050@68 {
+ compatible = "invensense,mpu6050";
+ reg = <0x68>;
+ interrupt-parent = <>;
+ interrupts = ;
+ mount-matrix = "0",
+ "1",
+ "0",
+ "-1",
+ "0",
+ "0",
+ "0",
+ "0",
+ "-1";
+ };
};
{
--
2.9.3
[PATCH 1/2] ARM: dts: rockchip: add eDP panel support for Firefly
This patch adds the supporting to the eDP panel sold by
the T-CHIP for the Firefly RK3288.
The InvenSense MPU6050 sensor at the botton of the panel
is also enabled.
The Firefly RK3288 Reload use a different GPIO pin to enable
the power of the eDP panel.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/rk3288-firefly.dtsi | 92 +++
1 file changed, 92 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 436878b..786cfb7 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -62,6 +62,62 @@
};
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <
+ 3 4 5 6 7
+ 8 9 10 11 12 13 14 15
+16 17 18 19 20 21 22 23
+24 25 26 27 28 29 30 31
+32 33 34 35 36 37 38 39
+40 41 42 43 44 45 46 47
+48 49 50 51 52 53 54 55
+56 57 58 59 60 61 62 63
+64 65 66 67 68 69 70 71
+72 73 74 75 76 77 78 79
+80 81 82 83 84 85 86 87
+88 89 90 91 92 93 94 95
+96 97 98 99 100 101 102 103
+ 104 105 106 107 108 109 110 111
+ 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127
+ 128 129 130 131 132 133 134 135
+ 136 137 138 139 140 141 142 143
+ 144 145 146 147 148 149 150 151
+ 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167
+ 168 169 170 171 172 173 174 175
+ 176 177 178 179 180 181 182 183
+ 184 185 186 187 188 189 190 191
+ 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207
+ 208 209 210 211 212 213 214 215
+ 216 217 218 219 220 221 222 223
+ 224 225 226 227 228 229 230 231
+ 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247
+ 248 249 250 251 252 253 254 255>;
+ default-brightness-level = <180>;
+ pwms = < 0 25000 0>;
+ pwm-names = "backlight";
+ power-supply = <_sys>;
+ };
+
+ panel: panel {
+ compatible ="lg,lp079qx1-sp0v";
+ power-supply = <_sys>;
+ backlight = <>;
+ enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ panel_in: port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+ };
+
dovdd_1v8: dovdd-1v8-regulator {
compatible = "regulator-fixed";
regulator-name = "dovdd_1v8";
@@ -203,6 +259,26 @@
cpu0-supply = <_cpu>;
};
+ {
+ vcc-supply = <_lcd>;
+ vccio-supply = <_18>;
+ ports {
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <_in_edp>;
+ };
+ };
+ };
+};
+
+_phy {
+ status = "okay";
+};
+
{
bus-width = <8>;
cap-mmc-highspeed;
@@ -385,6 +461,22 @@
{
status = "okay";
+
+ mpu6050@68 {
+ compatible = "invensense,mpu6050";
+ reg = <0x68>;
+ interrupt-parent = <>;
+ interrupts = ;
+ mount-matrix = "0",
+ "1",
+ "0",
+ "-1",
+ "0",
+ "0",
+ "0",
+ "0",
+ "-1";
+ };
};
{
--
2.9.3
[PATCH 2/2] ARM: dts: rockchip: enable eDP panel at Firefly Release
Signed-off-by: Randy Li <ay...@soulik.info>
---
arch/arm/boot/dts/rk3288-firefly.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dts
b/arch/arm/boot/dts/rk3288-firefly.dts
index 14271be..b3964c8 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dts
+++ b/arch/arm/boot/dts/rk3288-firefly.dts
@@ -48,10 +48,22 @@
compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
};
+ {
+ status = "okay";
+};
+
+_phy {
+ status = "okay";
+};
+
{
gpios = < RK_PA0 GPIO_ACTIVE_LOW>;
};
+ {
+ status = "okay";
+};
+
{
act8846 {
pmic_vsel: pmic-vsel {
@@ -69,3 +81,19 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+_mmu {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_mmu {
+ status = "okay";
+};
--
2.9.3
[PATCH 2/2] ARM: dts: rockchip: enable eDP panel at Firefly Release
Signed-off-by: Randy Li
---
arch/arm/boot/dts/rk3288-firefly.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dts
b/arch/arm/boot/dts/rk3288-firefly.dts
index 14271be..b3964c8 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dts
+++ b/arch/arm/boot/dts/rk3288-firefly.dts
@@ -48,10 +48,22 @@
compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
};
+ {
+ status = "okay";
+};
+
+_phy {
+ status = "okay";
+};
+
{
gpios = < RK_PA0 GPIO_ACTIVE_LOW>;
};
+ {
+ status = "okay";
+};
+
{
act8846 {
pmic_vsel: pmic-vsel {
@@ -69,3 +81,19 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+_mmu {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_mmu {
+ status = "okay";
+};
--
2.9.3
[PATCH 0/2] the supporting for eDP panel of Firefly
After the IRQ deadlock issue is solved, I can finally offer the supporting of the eDP panel sold by the T-CHIP Firefly. I don't think it is necessary to enable two vop for a eDP panel, even the vop lite is enough for the resolution of this panel. I have verified those patch with the kmssink from Gstreamer. but I still got a few warnings message, those message comes from booting time. [ 10.623207] rockchip-drm display-subsystem: fb0: frame buffer device [ 10.633680] rockchip-dp ff97.dp: AUX CH command reply failed! [ 10.646828] rockchip-dp ff97.dp: AUX CH command reply failed! [ 10.647440] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0 [ 10.663870] rockchip-dp ff97.dp: Rx Max Link Rate is abnormal :11 ! [ 10.673188] rockchip-dp ff97.dp: Link Training Clock Recovery success [ 10.682980] rockchip-dp ff97.dp: Link Training success! [ 10.794103] rockchip-dp ff97.dp: Timeout of video streamclk ok [ 10.801090] rockchip-dp ff97.dp: unable to config video [ 11.330781] EXT4-fs (mmcblk0p7): re-mounted. Opts: data=ordered You may need the following patch to make PWM backlight work, or merge it into the bootloader. ARM: rockchip: rk3288: Switch to use the proper PWM IP Randy Li (2): ARM: dts: rockchip: add eDP panel support for Firefly ARM: dts: rockchip: enable eDP panel at Firefly Release arch/arm/boot/dts/rk3288-firefly.dts | 28 +++ arch/arm/boot/dts/rk3288-firefly.dtsi | 92 +++ 2 files changed, 120 insertions(+) -- 2.9.3
[PATCH 0/2] the supporting for eDP panel of Firefly
After the IRQ deadlock issue is solved, I can finally offer the supporting of the eDP panel sold by the T-CHIP Firefly. I don't think it is necessary to enable two vop for a eDP panel, even the vop lite is enough for the resolution of this panel. I have verified those patch with the kmssink from Gstreamer. but I still got a few warnings message, those message comes from booting time. [ 10.623207] rockchip-drm display-subsystem: fb0: frame buffer device [ 10.633680] rockchip-dp ff97.dp: AUX CH command reply failed! [ 10.646828] rockchip-dp ff97.dp: AUX CH command reply failed! [ 10.647440] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0 [ 10.663870] rockchip-dp ff97.dp: Rx Max Link Rate is abnormal :11 ! [ 10.673188] rockchip-dp ff97.dp: Link Training Clock Recovery success [ 10.682980] rockchip-dp ff97.dp: Link Training success! [ 10.794103] rockchip-dp ff97.dp: Timeout of video streamclk ok [ 10.801090] rockchip-dp ff97.dp: unable to config video [ 11.330781] EXT4-fs (mmcblk0p7): re-mounted. Opts: data=ordered You may need the following patch to make PWM backlight work, or merge it into the bootloader. ARM: rockchip: rk3288: Switch to use the proper PWM IP Randy Li (2): ARM: dts: rockchip: add eDP panel support for Firefly ARM: dts: rockchip: enable eDP panel at Firefly Release arch/arm/boot/dts/rk3288-firefly.dts | 28 +++ arch/arm/boot/dts/rk3288-firefly.dtsi | 92 +++ 2 files changed, 120 insertions(+) -- 2.9.3
[PATCH v2] drm/rockchip: analogix_dp: add supports for regulators in edp IP
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 is used for eDP phy, and the eDP_AVDD_1V0 are used
both for eDP phy and controller.
Change-Id: I4e8a34609d5b292d7da77385ff15bebbf258090c
Signed-off-by: Randy Li <ay...@soulik.info>
Signed-off-by: Randy Li <randy...@rock-chips.com>
---
.../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/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 47665a1..0dbbfb3 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -34,6 +34,10 @@ Optional property for different chips:
- clock-names: from common clock binding:
Required elements: "grf"
+- vcc-supply: Regulator for eDP_AVDD_1V0.
+
+- vccio-supply: Regulator for eDP_AVDD_1V8.
+
For the below properties, please refer to Analogix DP binding document:
* Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
- phys (required)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d8fa7a9..2dad625 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,8 @@ struct rockchip_dp_device {
struct clk *grfclk;
struct regmap*grf;
struct reset_control *rst;
+ struct regulator *vcc_supply;
+ struct regulator *vccio_supply;
struct work_struct psr_work;
spinlock_t psr_lock;
@@ -146,6 +149,24 @@ static int rockchip_dp_poweron(struct
analogix_dp_plat_data *plat_data)
cancel_work_sync(>psr_work);
+ if (!IS_ERR(dp->vcc_supply)) {
+ ret = regulator_enable(dp->vcc_supply);
+ if (ret) {
+ dev_err(dp->dev,
+ "failed to enable vcc regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
+ if (!IS_ERR(dp->vccio_supply)) {
+ ret = regulator_enable(dp->vccio_supply);
+ if (ret) {
+ dev_err(dp->dev,
+ "failed to enable vccio regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
dev_err(dp->dev, "failed to enable pclk %d\n", ret);
@@ -168,6 +189,11 @@ static int rockchip_dp_powerdown(struct
analogix_dp_plat_data *plat_data)
clk_disable_unprepare(dp->pclk);
+ if (!IS_ERR(dp->vccio_supply))
+ regulator_disable(dp->vccio_supply);
+ if (!IS_ERR(dp->vcc_supply))
+ regulator_disable(dp->vcc_supply);
+
return 0;
}
@@ -323,6 +349,32 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
return PTR_ERR(dp->rst);
}
+ dp->vcc_supply = devm_regulator_get_optional(dev, "vcc");
+ dp->vccio_supply = devm_regulator_get_optional(dev, "vccio");
+
+ if (IS_ERR(dp->vcc_supply)) {
+ dev_err(dev, "failed to get vcc regulator: %ld\n",
+ PTR_ERR(dp->vcc_supply));
+ } else {
+ ret = regulator_enable(dp->vcc_supply);
+ if (ret) {
+ dev_err(dev,
+ "failed to enable vcc regulator: %d\n", ret);
+ return ret;
+ }
+ }
+ if (IS_ERR(dp->vccio_supply)) {
+ dev_err(dev, "failed to get vccio regulator: %ld\n",
+ PTR_ERR(dp->vccio_supply));
+ } else {
+ ret = regulator_enable(dp->vccio_supply);
+ if (ret) {
+ dev_err(dev,
+ "failed to enable vccio regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
dev_err(dp->dev, "failed to enable pclk %d\n", ret);
--
2.9.3
[PATCH v2] drm/rockchip: analogix_dp: add supports for regulators in edp IP
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 is used for eDP phy, and the eDP_AVDD_1V0 are used
both for eDP phy and controller.
Change-Id: 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/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 47665a1..0dbbfb3 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -34,6 +34,10 @@ Optional property for different chips:
- clock-names: from common clock binding:
Required elements: "grf"
+- vcc-supply: Regulator for eDP_AVDD_1V0.
+
+- vccio-supply: Regulator for eDP_AVDD_1V8.
+
For the below properties, please refer to Analogix DP binding document:
* Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
- phys (required)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d8fa7a9..2dad625 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,8 @@ struct rockchip_dp_device {
struct clk *grfclk;
struct regmap*grf;
struct reset_control *rst;
+ struct regulator *vcc_supply;
+ struct regulator *vccio_supply;
struct work_struct psr_work;
spinlock_t psr_lock;
@@ -146,6 +149,24 @@ static int rockchip_dp_poweron(struct
analogix_dp_plat_data *plat_data)
cancel_work_sync(>psr_work);
+ if (!IS_ERR(dp->vcc_supply)) {
+ ret = regulator_enable(dp->vcc_supply);
+ if (ret) {
+ dev_err(dp->dev,
+ "failed to enable vcc regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
+ if (!IS_ERR(dp->vccio_supply)) {
+ ret = regulator_enable(dp->vccio_supply);
+ if (ret) {
+ dev_err(dp->dev,
+ "failed to enable vccio regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
dev_err(dp->dev, "failed to enable pclk %d\n", ret);
@@ -168,6 +189,11 @@ static int rockchip_dp_powerdown(struct
analogix_dp_plat_data *plat_data)
clk_disable_unprepare(dp->pclk);
+ if (!IS_ERR(dp->vccio_supply))
+ regulator_disable(dp->vccio_supply);
+ if (!IS_ERR(dp->vcc_supply))
+ regulator_disable(dp->vcc_supply);
+
return 0;
}
@@ -323,6 +349,32 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
return PTR_ERR(dp->rst);
}
+ dp->vcc_supply = devm_regulator_get_optional(dev, "vcc");
+ dp->vccio_supply = devm_regulator_get_optional(dev, "vccio");
+
+ if (IS_ERR(dp->vcc_supply)) {
+ dev_err(dev, "failed to get vcc regulator: %ld\n",
+ PTR_ERR(dp->vcc_supply));
+ } else {
+ ret = regulator_enable(dp->vcc_supply);
+ if (ret) {
+ dev_err(dev,
+ "failed to enable vcc regulator: %d\n", ret);
+ return ret;
+ }
+ }
+ if (IS_ERR(dp->vccio_supply)) {
+ dev_err(dev, "failed to get vccio regulator: %ld\n",
+ PTR_ERR(dp->vccio_supply));
+ } else {
+ ret = regulator_enable(dp->vccio_supply);
+ if (ret) {
+ dev_err(dev,
+ "failed to enable vccio regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
dev_err(dp->dev, "failed to enable pclk %d\n", ret);
--
2.9.3
[PATCH] ARM: dts: rockchip: add missing grf phandle for rk3288
The PWM devices need to access the grf to switch the PWM IP. And tsadc uses it to shutdown the system. Signed-off-by: Randy Li <ay...@soulik.info> --- arch/arm/boot/dts/rk3288.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index 26b8886..c1d3b1f 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -546,6 +546,7 @@ pinctrl-2 = <_gpio>; #thermal-sensor-cells = <1>; rockchip,hw-tshut-temp = <95000>; + rockchip,grf = <>; status = "disabled"; }; @@ -654,6 +655,7 @@ pinctrl-0 = <_pin>; clocks = < PCLK_PWM>; clock-names = "pwm"; + rockchip,grf = <>; status = "disabled"; }; @@ -665,6 +667,7 @@ pinctrl-0 = <_pin>; clocks = < PCLK_PWM>; clock-names = "pwm"; + rockchip,grf = <>; status = "disabled"; }; @@ -676,6 +679,7 @@ pinctrl-0 = <_pin>; clocks = < PCLK_PWM>; clock-names = "pwm"; + rockchip,grf = <>; status = "disabled"; }; @@ -687,6 +691,7 @@ pinctrl-0 = <_pin>; clocks = < PCLK_PWM>; clock-names = "pwm"; + rockchip,grf = <>; status = "disabled"; }; -- 2.9.3
[PATCH] ARM: dts: rockchip: add missing grf phandle for rk3288
The PWM devices need to access the grf to switch the PWM IP. And tsadc uses it to shutdown the system. Signed-off-by: Randy Li --- arch/arm/boot/dts/rk3288.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index 26b8886..c1d3b1f 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -546,6 +546,7 @@ pinctrl-2 = <_gpio>; #thermal-sensor-cells = <1>; rockchip,hw-tshut-temp = <95000>; + rockchip,grf = <>; status = "disabled"; }; @@ -654,6 +655,7 @@ pinctrl-0 = <_pin>; clocks = < PCLK_PWM>; clock-names = "pwm"; + rockchip,grf = <>; status = "disabled"; }; @@ -665,6 +667,7 @@ pinctrl-0 = <_pin>; clocks = < PCLK_PWM>; clock-names = "pwm"; + rockchip,grf = <>; status = "disabled"; }; @@ -676,6 +679,7 @@ pinctrl-0 = <_pin>; clocks = < PCLK_PWM>; clock-names = "pwm"; + rockchip,grf = <>; status = "disabled"; }; @@ -687,6 +691,7 @@ pinctrl-0 = <_pin>; clocks = < PCLK_PWM>; clock-names = "pwm"; + rockchip,grf = <>; status = "disabled"; }; -- 2.9.3
[PATCH v6 3/3] drm/rockchip: Support 10 bits yuv format in vop
The rockchip use a special pixel format for those yuv pixel
format with 10 bits color depth.
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
include/uapi/drm/drm_fourcc.h | 11 ++
5 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index c9ccdf8..250fd29 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -230,6 +230,7 @@ void rockchip_drm_mode_config_init(struct drm_device *dev)
*/
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
+ dev->mode_config.allow_fb_modifiers = true;
dev->mode_config.funcs = _drm_mode_config_funcs;
dev->mode_config.helper_private = _mode_config_helpers;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..45da270 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_P010:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,12 +250,28 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_P010:
return true;
default:
return false;
}
}
+static bool is_support_fb(struct drm_framebuffer *fb)
+{
+ switch (fb->format->format) {
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV24:
+ return true;
+ case DRM_FORMAT_P010:
+ if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+ return true;
+ default:
+ return false;
+ }
+
+}
static bool is_alpha_support(uint32_t format)
{
switch (format) {
@@ -680,7 +697,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
* Src.x1 can be odd when do clip, but yuv plane start point
* need align with 2 pixel.
*/
- if (is_yuv_support(fb->format->format) && ((state->src.x1 >> 16) % 2))
+ if (is_support_fb(fb) && ((state->src.x1 >> 16) % 2))
return -EINVAL;
return 0;
@@ -723,6 +740,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int format;
/*
@@ -739,6 +757,9 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+ is_10_bits = true;
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -753,7 +774,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * 10 / 8;
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -764,6 +788,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, fb->pitches[0] >> 2);
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -772,7 +797,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * 10 / 8 / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
[PATCH v6 3/3] drm/rockchip: Support 10 bits yuv format in vop
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/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
include/uapi/drm/drm_fourcc.h | 11 ++
5 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index c9ccdf8..250fd29 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -230,6 +230,7 @@ void rockchip_drm_mode_config_init(struct drm_device *dev)
*/
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
+ dev->mode_config.allow_fb_modifiers = true;
dev->mode_config.funcs = _drm_mode_config_funcs;
dev->mode_config.helper_private = _mode_config_helpers;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..45da270 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_P010:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,12 +250,28 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_P010:
return true;
default:
return false;
}
}
+static bool is_support_fb(struct drm_framebuffer *fb)
+{
+ switch (fb->format->format) {
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV24:
+ return true;
+ case DRM_FORMAT_P010:
+ if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+ return true;
+ default:
+ return false;
+ }
+
+}
static bool is_alpha_support(uint32_t format)
{
switch (format) {
@@ -680,7 +697,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
* Src.x1 can be odd when do clip, but yuv plane start point
* need align with 2 pixel.
*/
- if (is_yuv_support(fb->format->format) && ((state->src.x1 >> 16) % 2))
+ if (is_support_fb(fb) && ((state->src.x1 >> 16) % 2))
return -EINVAL;
return 0;
@@ -723,6 +740,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int format;
/*
@@ -739,6 +757,9 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+ is_10_bits = true;
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -753,7 +774,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * 10 / 8;
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -764,6 +788,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, fb->pitches[0] >> 2);
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -772,7 +797,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * 10 / 8 / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src
[PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format.
Also a variant of V4L2_PIX_FMT_P010M pixel format is added.
The V4L2_PIX_FMT_P010CM is a compat variant of 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 <ay...@soulik.info>
---
Documentation/media/uapi/v4l/pixfmt-p010.rst | 126
Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++
Documentation/media/uapi/v4l/pixfmt-p016.rst | 125
Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
Documentation/media/uapi/v4l/yuv-formats.rst | 4 +
include/uapi/linux/videodev2.h| 5 +
6 files changed, 529 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..59ed118
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,126 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 16 bits per pixel, but only 10 bits are used with the
+rest 6 bits set to zero. For ``V4L2_PIX_FMT_P010``, a combined CbCr plane
+immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Byte Order.**
+Each cell is two bytes.
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+* - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+* - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+* - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+* - start + 16:
+ - Cb\ :sub:`00`
+ - Cr\ :sub:`00`
+ - Cb\ :sub:`01`
+ - Cr\ :sub:`01`
+* - start + 20:
+ - Cb\ :sub:`10`
+ - Cr\ :sub:`10`
+ - Cb\ :sub:`11`
+ - Cr\ :sub:`11`
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+* - 2
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 3
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 000..6697d15
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,135 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***
+V4L2_PIX_FMT_P010M ('PM10')
+***
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminanc
[PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format.
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.
V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new 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 <dan...@fooishbar.org>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Randy Li <ay...@soulik.info>
Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com>
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@ extern "C" {
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4
[PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format.
Also a variant of V4L2_PIX_FMT_P010M pixel format is added.
The V4L2_PIX_FMT_P010CM is a compat variant of 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
Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++
Documentation/media/uapi/v4l/pixfmt-p016.rst | 125
Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
Documentation/media/uapi/v4l/yuv-formats.rst | 4 +
include/uapi/linux/videodev2.h| 5 +
6 files changed, 529 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..59ed118
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,126 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 16 bits per pixel, but only 10 bits are used with the
+rest 6 bits set to zero. For ``V4L2_PIX_FMT_P010``, a combined CbCr plane
+immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Byte Order.**
+Each cell is two bytes.
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+* - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+* - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+* - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+* - start + 16:
+ - Cb\ :sub:`00`
+ - Cr\ :sub:`00`
+ - Cb\ :sub:`01`
+ - Cr\ :sub:`01`
+* - start + 20:
+ - Cb\ :sub:`10`
+ - Cr\ :sub:`10`
+ - Cb\ :sub:`11`
+ - Cr\ :sub:`11`
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+* - 2
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 3
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 000..6697d15
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,135 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***
+V4L2_PIX_FMT_P010M ('PM10')
+***
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminance data
+occupies the first plane
[PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format.
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.
V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new 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/drm_fourcc.h | 21 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@ extern "C" {
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4
[PATCH v6 0/3] Add pixel format for 10 bits YUV video
Thanks to Clint's work, this version just correct some wrong info in the comment. I also offer a driver sample here, but it have been verified with the 10 bits properly. I lacks of the userspace tool. And I am not sure whether it is a properly way to support the pixel format used in rockchip, 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 10/16-bits per channel YUV pixel formats drm/rockchip: Support 10 bits yuv format in vop Documentation/media/uapi/v4l/pixfmt-p010.rst | 126 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++ Documentation/media/uapi/v4l/pixfmt-p016.rst | 125 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 + Documentation/media/uapi/v4l/yuv-formats.rst | 4 + drivers/gpu/drm/drm_fourcc.c | 3 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + include/uapi/drm/drm_fourcc.h | 32 ++ include/uapi/linux/videodev2.h| 5 + 12 files changed, 599 insertions(+), 3 deletions(-) create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst -- 2.7.4
[PATCH v6 0/3] Add pixel format for 10 bits YUV video
Thanks to Clint's work, this version just correct some wrong info in the comment. I also offer a driver sample here, but it have been verified with the 10 bits properly. I lacks of the userspace tool. And I am not sure whether it is a properly way to support the pixel format used in rockchip, 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 10/16-bits per channel YUV pixel formats drm/rockchip: Support 10 bits yuv format in vop Documentation/media/uapi/v4l/pixfmt-p010.rst | 126 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++ Documentation/media/uapi/v4l/pixfmt-p016.rst | 125 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 + Documentation/media/uapi/v4l/yuv-formats.rst | 4 + drivers/gpu/drm/drm_fourcc.c | 3 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + include/uapi/drm/drm_fourcc.h | 32 ++ include/uapi/linux/videodev2.h| 5 + 12 files changed, 599 insertions(+), 3 deletions(-) create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst -- 2.7.4
Re: drm: rockchip: CONFIG_DRM_FBDEV_EMULATION will crash the HDMI down sometimes
-[ end trace 92447684af807ac2 ]--- [ 11.481977] vop active 1, state 1 [ 11.481985] [ cut here ] [ 11.482021] WARNING: CPU: 3 PID: 167 at /home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/rockchip/rockchip_drm_ vop.c:1023 vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm] [ 11.482030] Modules linked in: rockchip_vop_reg dw_hdmi_rockchip dw_hdmi rockchipdrm drm_kms_helper mali_kbase cfbfillrect sysc opyarea rk_crypto gpio_ir_recv cfbimgblt panel_simple sysfillrect rc_core sysimgblt nvmem_rockchip_efuse fb_sys_fops cfbcopyarea d rm des_generic dwc2 pwm_rockchip phy_rockchip_usb udc_core fb pwm_bl backlight [ 11.482119] CPU: 3 PID: 167 Comm: kworker/3:2 Tainted: GW 4.10.0-rc3-next-20170111+ #149 [ 11.482122] Hardware name: Rockchip (Device Tree) [ 11.482200] Workqueue: events output_poll_execute [drm_kms_helper] [ 11.482227] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 11.482242] [] (show_stack) from [] (dump_stack+0x8c/0xa0) [ 11.482259] [] (dump_stack) from [] (__warn+0xf8/0x110) [ 11.482275] [] (__warn) from [] (warn_slowpath_null+0x30/0x38) [ 11.482308] [] (warn_slowpath_null) from [] (vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm]) [ 11.482416] [] (vop_crtc_atomic_flush [rockchipdrm]) from [] (drm_atomic_helper_commit_planes+0x1d0/0x2b8 [ drm_kms_helper]) [ 11.482522] [] (drm_atomic_helper_commit_planes [drm_kms_helper]) from [] (rockchip_atomic_commit_tail+0x44 /0x68 [rockchipdrm]) [ 11.482623] [] (rockchip_atomic_commit_tail [rockchipdrm]) from [] (commit_tail+0x50/0xb8 [drm_kms_helper]) [ 11.482779] [] (commit_tail [drm_kms_helper]) from [] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper] ) [ 11.483024] [] (drm_atomic_helper_commit [drm_kms_helper]) from [] (drm_atomic_commit+0x5c/0x68 [drm]) [ 11.483270] [] (drm_atomic_commit [drm]) from [] (restore_fbdev_mode+0x160/0x300 [drm_kms_helper]) [ 11.483422] [] (restore_fbdev_mode [drm_kms_helper]) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4 0/0x84 [drm_kms_helper]) [ 11.483569] [] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [] (drm_fb_helper_set_par+ 0x40/0x70 [drm_kms_helper]) [ 11.483715] [] (drm_fb_helper_set_par [drm_kms_helper]) from [] (drm_fb_helper_hotplug_event+0xb4/0xbc [drm _kms_helper]) [ 11.483821] [] (drm_fb_helper_hotplug_event [drm_kms_helper]) from [] (rockchip_drm_output_poll_changed+0x2 4/0x28 [rockchipdrm]) Thanks. On 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 as I meet a big problem in there. [..] [ 34.464856] ---[ end trace 95ed2c3f167607d5 ]--- -- Randy Li
Re: drm: rockchip: CONFIG_DRM_FBDEV_EMULATION will crash the HDMI down sometimes
-[ end trace 92447684af807ac2 ]--- [ 11.481977] vop active 1, state 1 [ 11.481985] [ cut here ] [ 11.482021] WARNING: CPU: 3 PID: 167 at /home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/rockchip/rockchip_drm_ vop.c:1023 vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm] [ 11.482030] Modules linked in: rockchip_vop_reg dw_hdmi_rockchip dw_hdmi rockchipdrm drm_kms_helper mali_kbase cfbfillrect sysc opyarea rk_crypto gpio_ir_recv cfbimgblt panel_simple sysfillrect rc_core sysimgblt nvmem_rockchip_efuse fb_sys_fops cfbcopyarea d rm des_generic dwc2 pwm_rockchip phy_rockchip_usb udc_core fb pwm_bl backlight [ 11.482119] CPU: 3 PID: 167 Comm: kworker/3:2 Tainted: GW 4.10.0-rc3-next-20170111+ #149 [ 11.482122] Hardware name: Rockchip (Device Tree) [ 11.482200] Workqueue: events output_poll_execute [drm_kms_helper] [ 11.482227] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 11.482242] [] (show_stack) from [] (dump_stack+0x8c/0xa0) [ 11.482259] [] (dump_stack) from [] (__warn+0xf8/0x110) [ 11.482275] [] (__warn) from [] (warn_slowpath_null+0x30/0x38) [ 11.482308] [] (warn_slowpath_null) from [] (vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm]) [ 11.482416] [] (vop_crtc_atomic_flush [rockchipdrm]) from [] (drm_atomic_helper_commit_planes+0x1d0/0x2b8 [ drm_kms_helper]) [ 11.482522] [] (drm_atomic_helper_commit_planes [drm_kms_helper]) from [] (rockchip_atomic_commit_tail+0x44 /0x68 [rockchipdrm]) [ 11.482623] [] (rockchip_atomic_commit_tail [rockchipdrm]) from [] (commit_tail+0x50/0xb8 [drm_kms_helper]) [ 11.482779] [] (commit_tail [drm_kms_helper]) from [] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper] ) [ 11.483024] [] (drm_atomic_helper_commit [drm_kms_helper]) from [] (drm_atomic_commit+0x5c/0x68 [drm]) [ 11.483270] [] (drm_atomic_commit [drm]) from [] (restore_fbdev_mode+0x160/0x300 [drm_kms_helper]) [ 11.483422] [] (restore_fbdev_mode [drm_kms_helper]) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4 0/0x84 [drm_kms_helper]) [ 11.483569] [] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [] (drm_fb_helper_set_par+ 0x40/0x70 [drm_kms_helper]) [ 11.483715] [] (drm_fb_helper_set_par [drm_kms_helper]) from [] (drm_fb_helper_hotplug_event+0xb4/0xbc [drm _kms_helper]) [ 11.483821] [] (drm_fb_helper_hotplug_event [drm_kms_helper]) from [] (rockchip_drm_output_poll_changed+0x2 4/0x28 [rockchipdrm]) Thanks. On 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 as I meet a big problem in there. [..] [ 34.464856] ---[ end trace 95ed2c3f167607d5 ]--- -- Randy Li
drm: rockchip: CONFIG_DRM_FBDEV_EMULATION will crash the HDMI down sometimes
[drm_kms_helper]) from [] (drm_atomic_helper_wait _for_vblanks+0x24/0x28 [drm_kms_helper]) [ 34.321176] [] (drm_atomic_helper_wait_for_vblanks [drm_kms_helper]) from [] (rockchip_atomic_commit_tail+0 x58/0x68 [rockchipdrm]) [ 34.334725] [] (rockchip_atomic_commit_tail [rockchipdrm]) from [] (commit_tail+0x50/0xb8 [drm_kms_helper]) [ 34.346330] [] (commit_tail [drm_kms_helper]) from [] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper] ) [ 34.358117] [] (drm_atomic_helper_commit [drm_kms_helper]) from [] (drm_atomic_commit+0x5c/0x68 [drm]) [ 34.369386] [] (drm_atomic_commit [drm]) from [] (restore_fbdev_mode+0x160/0x300 [drm_kms_helper]) [ 34.380209] [] (restore_fbdev_mode [drm_kms_helper]) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4 0/0x84 [drm_kms_helper]) [ 34.393845] [] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [] (rockchip_drm_lastclose +0x1c/0x20 [rockchipdrm]) [ 34.407664] [] (rockchip_drm_lastclose [rockchipdrm]) from [] (drm_lastclose+0x48/0xd8 [drm]) [ 34.418237] [] (drm_lastclose [drm]) from [] (drm_release+0x2c4/0x36c [drm]) [ 34.427179] [] (drm_release [drm]) from [] (__fput+0x9c/0x1e8) [ 34.434754] [] (__fput) from [] (fput+0x18/0x1c) [ 34.441458] [] (fput) from [] (task_work_run+0xcc/0xf0) [ 34.448769] [] (task_work_run) from [] (do_work_pending+0xd0/0xd4) [ 34.456688] [] (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 recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
drm: rockchip: CONFIG_DRM_FBDEV_EMULATION will crash the HDMI down sometimes
[drm_kms_helper]) from [] (drm_atomic_helper_wait _for_vblanks+0x24/0x28 [drm_kms_helper]) [ 34.321176] [] (drm_atomic_helper_wait_for_vblanks [drm_kms_helper]) from [] (rockchip_atomic_commit_tail+0 x58/0x68 [rockchipdrm]) [ 34.334725] [] (rockchip_atomic_commit_tail [rockchipdrm]) from [] (commit_tail+0x50/0xb8 [drm_kms_helper]) [ 34.346330] [] (commit_tail [drm_kms_helper]) from [] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper] ) [ 34.358117] [] (drm_atomic_helper_commit [drm_kms_helper]) from [] (drm_atomic_commit+0x5c/0x68 [drm]) [ 34.369386] [] (drm_atomic_commit [drm]) from [] (restore_fbdev_mode+0x160/0x300 [drm_kms_helper]) [ 34.380209] [] (restore_fbdev_mode [drm_kms_helper]) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4 0/0x84 [drm_kms_helper]) [ 34.393845] [] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [] (rockchip_drm_lastclose +0x1c/0x20 [rockchipdrm]) [ 34.407664] [] (rockchip_drm_lastclose [rockchipdrm]) from [] (drm_lastclose+0x48/0xd8 [drm]) [ 34.418237] [] (drm_lastclose [drm]) from [] (drm_release+0x2c4/0x36c [drm]) [ 34.427179] [] (drm_release [drm]) from [] (__fput+0x9c/0x1e8) [ 34.434754] [] (__fput) from [] (fput+0x18/0x1c) [ 34.441458] [] (fput) from [] (task_work_run+0xcc/0xf0) [ 34.448769] [] (task_work_run) from [] (do_work_pending+0xd0/0xd4) [ 34.456688] [] (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 recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
[PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those 10 bits format for
profile_10 HEVC/AVC video.
Signed-off-by: Randy Li <ay...@soulik.info>
v4l2
---
Documentation/media/uapi/v4l/pixfmt-p010.rst | 86
Documentation/media/uapi/v4l/pixfmt-p010m.rst | 94 ++
Documentation/media/uapi/v4l/pixfmt-p016.rst | 126
Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++
include/uapi/linux/videodev2.h| 4 +
5 files changed, 446 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..82b300c
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,86 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 10 bits per pixel. For ``V4L2_PIX_FMT_P010``, a
+combined CbCr plane immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+* - 2
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 3
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 000..80194a1
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,94 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***
+V4L2_PIX_FMT_P010 ('P010')
+***
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminance data
+occupies the first plane. The Y plane has one byte per pixel. In the
+second plane there is a chrominance data with alternating chroma
+samples. The CbCr plane is the same width, in bytes, as the Y plane (and
+of the image), but is half as tall in pixels. Each CbCr pair belongs to
+four pixels. For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to
+Y'\ :sub:`00`, Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+
+``V4L2_PIX_FMT_P010M`` is intended to be used only in drivers and
+applications that support the multi-planar API, described in
+:ref:`planar-apis`.
+
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Color Sample Location..**
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+
[PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip'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 | 126
Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++
include/uapi/linux/videodev2.h| 4 +
5 files changed, 446 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..82b300c
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,86 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 10 bits per pixel. For ``V4L2_PIX_FMT_P010``, a
+combined CbCr plane immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+* - 2
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 3
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 000..80194a1
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,94 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***
+V4L2_PIX_FMT_P010 ('P010')
+***
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminance data
+occupies the first plane. The Y plane has one byte per pixel. In the
+second plane there is a chrominance data with alternating chroma
+samples. The CbCr plane is the same width, in bytes, as the Y plane (and
+of the image), but is half as tall in pixels. Each CbCr pair belongs to
+four pixels. For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to
+Y'\ :sub:`00`, Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+
+``V4L2_PIX_FMT_P010M`` is intended to be used only in drivers and
+applications that support the multi-planar API, described in
+:ref:`planar-apis`.
+
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Color Sample Location..**
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
[PATCH v2 0/2] Add pixel formats for 10/16 bits YUV video
Those pixel formats mainly comes from Gstreamer and ffmpeg. Currently, the VOP(video output mixer) found on RK3288 and future support those 10 bits pixel formats are input. Also the decoder on RK3288 could use them as output. The fourcc is not enough to store the endian information for those 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 pixel formats Documentation/media/uapi/v4l/pixfmt-p010.rst | 86 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 94 ++ Documentation/media/uapi/v4l/pixfmt-p016.rst | 126 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++ drivers/gpu/drm/drm_fourcc.c | 3 + include/uapi/drm/drm_fourcc.h | 2 + include/uapi/linux/videodev2.h| 4 + 7 files changed, 451 insertions(+) create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst -- 2.7.4
[PATCH v2 0/2] Add pixel formats for 10/16 bits YUV video
Those pixel formats mainly comes from Gstreamer and ffmpeg. Currently, the VOP(video output mixer) found on RK3288 and future support those 10 bits pixel formats are input. Also the decoder on RK3288 could use them as output. The fourcc is not enough to store the endian information for those 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 pixel formats Documentation/media/uapi/v4l/pixfmt-p010.rst | 86 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 94 ++ Documentation/media/uapi/v4l/pixfmt-p016.rst | 126 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++ drivers/gpu/drm/drm_fourcc.c | 3 + include/uapi/drm/drm_fourcc.h | 2 + include/uapi/linux/videodev2.h| 4 + 7 files changed, 451 insertions(+) create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst -- 2.7.4
[PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format
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 <ay...@soulik.info>
drm
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..23c8e99 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ /* FIXME a pixel in Y for P010 is 10 bits */
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..ecc2e05e5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,8 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane 16 bits per channel */
/*
* 3 plane YCbCr
--
2.7.4
[PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format
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
drm
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..23c8e99 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ /* FIXME a pixel in Y for P010 is 10 bits */
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..ecc2e05e5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,8 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane 16 bits per channel */
/*
* 3 plane YCbCr
--
2.7.4
Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal
On 01/03/2017 09:02 AM, Caesar Wang wrote:
在 2017年01月03日 07:57, Randy Li 写道:
On 01/02/2017 09:16 PM, Caesar Wang wrote:
在 2016年12月31日 00:11, ayaka 写道:
BTW, Caesar have you ever met this at RK3288 at booting time?
[8.430582] thermal thermal_zone1: critical temperature
reached(125 C),shutting down
[8.439038] thermal thermal_zone2: critical temperature
reached(125 C),shutting down
[8.456344] thermal thermal_zone1: critical temperature
reached(125 C),shutting down
[8.465298] thermal thermal_zone2: critical temperature
reached(125 C),shutting down
125C? the thermal zone isn't the upstream kernel, what's the kernel
version?
They have been merged into the linux-next.
Really?
I saw the 90 degree is the critical temperature on rk3288 dts .
Yes I do.
kernel$ vi arch/arm/boot/dts/rk3288.dtsi
cpu_crit: cpu_crit {
temperature = <9>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "critical";
};
Anyway, look like, the TSHUT issue. Do you have the below patches
for your linux kernel?
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380446.html
No, could you resubmit those patches ?
These patches had merged for upstream.
Sorry, it is my fault, I mistake that commit. Those patches are merged
in next-20161224. I would bring a board for you later.
-Caesar
--
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 unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===
Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal
On 01/03/2017 09:02 AM, Caesar Wang wrote:
在 2017年01月03日 07:57, Randy Li 写道:
On 01/02/2017 09:16 PM, Caesar Wang wrote:
在 2016年12月31日 00:11, ayaka 写道:
BTW, Caesar have you ever met this at RK3288 at booting time?
[8.430582] thermal thermal_zone1: critical temperature
reached(125 C),shutting down
[8.439038] thermal thermal_zone2: critical temperature
reached(125 C),shutting down
[8.456344] thermal thermal_zone1: critical temperature
reached(125 C),shutting down
[8.465298] thermal thermal_zone2: critical temperature
reached(125 C),shutting down
125C? the thermal zone isn't the upstream kernel, what's the kernel
version?
They have been merged into the linux-next.
Really?
I saw the 90 degree is the critical temperature on rk3288 dts .
Yes I do.
kernel$ vi arch/arm/boot/dts/rk3288.dtsi
cpu_crit: cpu_crit {
temperature = <9>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "critical";
};
Anyway, look like, the TSHUT issue. Do you have the below patches
for your linux kernel?
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380446.html
No, could you resubmit those patches ?
These patches had merged for upstream.
Sorry, it is my fault, I mistake that commit. Those patches are merged
in next-20161224. I would bring a board for you later.
-Caesar
--
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 unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===
Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal
On 01/02/2017 09:16 PM, Caesar Wang wrote: 在 2016年12月31日 00:11, ayaka 写道: BTW, Caesar have you ever met this at RK3288 at booting time? [8.430582] thermal thermal_zone1: critical temperature reached(125 C),shutting down [8.439038] thermal thermal_zone2: critical temperature reached(125 C),shutting down [8.456344] thermal thermal_zone1: critical temperature reached(125 C),shutting down [8.465298] thermal thermal_zone2: critical temperature reached(125 C),shutting down 125C? the thermal zone isn't the upstream kernel, what's the kernel version? They have been merged into the linux-next. Anyway, look like, the TSHUT issue. Do you have the below patches for your linux kernel? http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380446.html No, could you resubmit those patches ? -Caesar On 12/12/2016 07:05 PM, Caesar Wang wrote: There are five patches posted for upstream. 89267b5 thermal: rockchip: improve conversion error messages a0b5649 thermal: rockchip: don't pass table structs by value bceed92 thermal: rockchip: fixes invalid temperature case 30be6d0 thermal: rockchip: optimize the conversion table 35636e9 thermal: rockchip: handle the set_trips without the trip points. -- History version: V1: https://lkml.org/lkml/2016/11/22/250 V2: https://lkml.org/lkml/2016/11/23/348 V3: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1281432.html --- Brain posted the below patches for upstream. 89267b5 thermal: rockchip: improve conversion error messages a0b5649 thermal: rockchip: don't pass table structs by value That make sense to improve efficiency Caesar post the below patches for upstream. bceed92 thermal: rockchip: fixes invalid temperature case 30be6d0 thermal: rockchip: optimize the conversion table 35636e9 thermal: rockchip: handle the set_trips without the trip points. That will fixes some issues in special cases. -- Anyway, this series patches should can improve the rockchip thermal driver. Changes in v4: - As Eduardo and Brian commnets on https://patchwork.kernel.org/patch/9449301 - Print a better name. - As Eduardo commented on https://patchwork.kernel.org/patch/9449313/ - remove the Brain's review for previous version, since the new version update something. Changes in v3: - fix trivial thing for error message nd return value. - change the commit. - Fixes something as Brian comments on Changes in v2: - As Brian commnets that restructure this to pass error codes back to the upper layers. - Improve the commit message. - improve the commit as Brian commnets on https://patchwork.kernel.org/patch/9440985 - Fixes something as Brian comments on https://patchwork.kernel.org/patch/9440989. Changes in v1: - The original Brian posted on https://patchwork.kernel.org/patch/9437686 Note: it'd probably be even nicer to know which sensor this was, but we've kinda abstracted that one away by this point... - The original Brian posted on https://patchwork.kernel.org/patch/9437687 Brian Norris (2): thermal: rockchip: improve conversion error messages thermal: rockchip: don't pass table structs by value Caesar Wang (3): thermal: rockchip: fixes invalid temperature case thermal: rockchip: optimize the conversion table thermal: rockchip: handle set_trips without the trip points drivers/thermal/rockchip_thermal.c | 153 - 1 file changed, 100 insertions(+), 53 deletions(-) ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal
On 01/02/2017 09:16 PM, Caesar Wang wrote: 在 2016年12月31日 00:11, ayaka 写道: BTW, Caesar have you ever met this at RK3288 at booting time? [8.430582] thermal thermal_zone1: critical temperature reached(125 C),shutting down [8.439038] thermal thermal_zone2: critical temperature reached(125 C),shutting down [8.456344] thermal thermal_zone1: critical temperature reached(125 C),shutting down [8.465298] thermal thermal_zone2: critical temperature reached(125 C),shutting down 125C? the thermal zone isn't the upstream kernel, what's the kernel version? They have been merged into the linux-next. Anyway, look like, the TSHUT issue. Do you have the below patches for your linux kernel? http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380446.html No, could you resubmit those patches ? -Caesar On 12/12/2016 07:05 PM, Caesar Wang wrote: There are five patches posted for upstream. 89267b5 thermal: rockchip: improve conversion error messages a0b5649 thermal: rockchip: don't pass table structs by value bceed92 thermal: rockchip: fixes invalid temperature case 30be6d0 thermal: rockchip: optimize the conversion table 35636e9 thermal: rockchip: handle the set_trips without the trip points. -- History version: V1: https://lkml.org/lkml/2016/11/22/250 V2: https://lkml.org/lkml/2016/11/23/348 V3: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1281432.html --- Brain posted the below patches for upstream. 89267b5 thermal: rockchip: improve conversion error messages a0b5649 thermal: rockchip: don't pass table structs by value That make sense to improve efficiency Caesar post the below patches for upstream. bceed92 thermal: rockchip: fixes invalid temperature case 30be6d0 thermal: rockchip: optimize the conversion table 35636e9 thermal: rockchip: handle the set_trips without the trip points. That will fixes some issues in special cases. -- Anyway, this series patches should can improve the rockchip thermal driver. Changes in v4: - As Eduardo and Brian commnets on https://patchwork.kernel.org/patch/9449301 - Print a better name. - As Eduardo commented on https://patchwork.kernel.org/patch/9449313/ - remove the Brain's review for previous version, since the new version update something. Changes in v3: - fix trivial thing for error message nd return value. - change the commit. - Fixes something as Brian comments on Changes in v2: - As Brian commnets that restructure this to pass error codes back to the upper layers. - Improve the commit message. - improve the commit as Brian commnets on https://patchwork.kernel.org/patch/9440985 - Fixes something as Brian comments on https://patchwork.kernel.org/patch/9440989. Changes in v1: - The original Brian posted on https://patchwork.kernel.org/patch/9437686 Note: it'd probably be even nicer to know which sensor this was, but we've kinda abstracted that one away by this point... - The original Brian posted on https://patchwork.kernel.org/patch/9437687 Brian Norris (2): thermal: rockchip: improve conversion error messages thermal: rockchip: don't pass table structs by value Caesar Wang (3): thermal: rockchip: fixes invalid temperature case thermal: rockchip: optimize the conversion table thermal: rockchip: handle set_trips without the trip points drivers/thermal/rockchip_thermal.c | 153 - 1 file changed, 100 insertions(+), 53 deletions(-) ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[PATCH 0/2] Add pixel format for 10 bits YUV video
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 channel YUV pixel formats include/uapi/drm/drm_fourcc.h | 1 + include/uapi/linux/videodev2.h | 2 ++ 2 files changed, 3 insertions(+) -- 2.7.4
[PATCH 0/2] Add pixel format for 10 bits YUV video
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 channel YUV pixel formats include/uapi/drm/drm_fourcc.h | 1 + include/uapi/linux/videodev2.h | 2 ++ 2 files changed, 3 insertions(+) -- 2.7.4
[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC video.
Signed-off-by: Randy Li <ay...@soulik.info>
---
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/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
4:2:2 */
#define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
4:4:4 */
#define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb
4:4:4 */
+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr
4:2:0, 10 bits per channel */
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb
4:2:2 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 64x32 macroblocks */
#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr
4:2:0, 10 bits per channel */
/* three planes - Y Cb, Cr */
#define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV 4:1:0
*/
--
2.7.4
[PATCH 1/2] drm_fourcc: Add new P010 video format
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 <ay...@soulik.info>
---
include/uapi/drm/drm_fourcc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..d2721da 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,7 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
/*
* 3 plane YCbCr
--
2.7.4
[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/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/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
4:2:2 */
#define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
4:4:4 */
#define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb
4:4:4 */
+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr
4:2:0, 10 bits per channel */
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb
4:2:2 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 64x32 macroblocks */
#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr
4:2:0, 10 bits per channel */
/* three planes - Y Cb, Cr */
#define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV 4:1:0
*/
--
2.7.4
[PATCH 1/2] drm_fourcc: Add new P010 video format
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/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..d2721da 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,7 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
/*
* 3 plane YCbCr
--
2.7.4
Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
On 12/30/2016 10:35 AM, Jaehoon Chung wrote: On 12/30/2016 12:07 AM, ayaka wrote: On 12/29/2016 10:04 PM, Jaehoon Chung wrote: Hi, On 12/29/2016 09:55 PM, ayaka wrote: [5.849733] rk_gmac-dwmac ff29.ethernet (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer [5.944512] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [5.958249] mmc1: new ultra high speed DDR50 SDIO card at address 0001 [6.294548] dwmmc_rockchip ff0f.dwmmc: Successfully tuned phase to 177 [6.301591] mmc2: new HS200 MMC card at address 0001 [6.306758] mmc_host mmc0: Bus speed (slot 0) = 30Hz (slot req 30Hz, actual 30HZ div = 0) [6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB [6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1 4.00 MiB [6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2 4.00 MiB [6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3 4.00 MiB [6.344295] mmcblk2: p1 p2 p3 p4 p5 p6 p7 [6.469892] mmc_host mmc0: Bus speed (slot 0) = 20Hz (slot req 20Hz, actual 20HZ div = 0) [6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 10Hz, actual 93750HZ div = 1) [6.917883] libphy: stmmac: probed [6.921319] rk_gmac-dwmac ff29.ethernet eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [6.930476] rk_gmac-dwmac ff29.ethernet eth0: PHY ID 001cc915 at 2 IRQ POLL (stmmac-0:02) [6.939757] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [6.946937] rtc-hym8563 0-0051: no valid clock/calendar values available [6.953694] rtc-hym8563 0-0051: hctosys: unable to read the hardware clock [6.961262] vcc_sd: disabling [6.964275] dovdd_1v8: disabling [6.967527] dvdd_1v2: disabling [6.971006] vdd10_lcd: disabling [6.974701] vcc18_lcd: disabling [6.978467] ttyS2 - failed to request DMA [7.101883] mmc_host mmc0: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual 40HZ div = 0) [7.253874] mmc_host mmc0: Bus speed (slot 0) = 30Hz (slot req 30Hz, actual 30HZ div = 0) [7.405883] mmc_host mmc0: Bus speed (slot 0) = 20Hz (slot req 20Hz, actual 20HZ div = 0) [7.557885] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 10Hz, actual 93750HZ div = 1) [8.037872] mmc_host mmc0: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual 40HZ div = 0) [8.189877] mmc_host mmc0: Bus speed (slot 0) = 30Hz (slot req 30Hz, actual 30HZ div = 0) [8.341881] mmc_host mmc0: Bus speed (slot 0) = 20Hz (slot req 20Hz, actual 20HZ div = 0) [8.493884] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 10Hz, actual 93750HZ div = 1) [8.973871] mmc_host mmc0: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual 40HZ div = 0) [9.125876] mmc_host mmc0: Bus speed (slot 0) = 30Hz (slot req 30Hz, actual 30HZ div = 0) [9.277884] mmc_host mmc0: Bus speed (slot 0) = 20Hz (slot req 20Hz, actual 20HZ div = 0) [9.429882] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 10Hz, actual 93750HZ div = 1) looping here If I revert that patch, there are still lots of Bus speed messages, but finally would enter into system. Plz..Don't put the comment on the top. Which kernel did you use? Add linux-next specific files for 20161224 mmc0 is what card? Is it polling for detecting card? (It seems the SD-card..right?) Yes, but the Firefly release won't show that, just stop at "ttyS2 - failed to request DMA". I check both the firefly reload and firefly release, they both have a cd line for them, so it won't be poll mode. Those logs should be polled for detecting mmc0 card..Hmm..I sent the patch for disabling log message when polling. If this log is displayed, then my patch might be some wrong.. :( Best Regards, Jaehoon Chung [snip] -- 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 unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
On 12/30/2016 10:35 AM, Jaehoon Chung wrote: On 12/30/2016 12:07 AM, ayaka wrote: On 12/29/2016 10:04 PM, Jaehoon Chung wrote: Hi, On 12/29/2016 09:55 PM, ayaka wrote: [5.849733] rk_gmac-dwmac ff29.ethernet (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer [5.944512] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [5.958249] mmc1: new ultra high speed DDR50 SDIO card at address 0001 [6.294548] dwmmc_rockchip ff0f.dwmmc: Successfully tuned phase to 177 [6.301591] mmc2: new HS200 MMC card at address 0001 [6.306758] mmc_host mmc0: Bus speed (slot 0) = 30Hz (slot req 30Hz, actual 30HZ div = 0) [6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB [6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1 4.00 MiB [6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2 4.00 MiB [6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3 4.00 MiB [6.344295] mmcblk2: p1 p2 p3 p4 p5 p6 p7 [6.469892] mmc_host mmc0: Bus speed (slot 0) = 20Hz (slot req 20Hz, actual 20HZ div = 0) [6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 10Hz, actual 93750HZ div = 1) [6.917883] libphy: stmmac: probed [6.921319] rk_gmac-dwmac ff29.ethernet eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [6.930476] rk_gmac-dwmac ff29.ethernet eth0: PHY ID 001cc915 at 2 IRQ POLL (stmmac-0:02) [6.939757] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [6.946937] rtc-hym8563 0-0051: no valid clock/calendar values available [6.953694] rtc-hym8563 0-0051: hctosys: unable to read the hardware clock [6.961262] vcc_sd: disabling [6.964275] dovdd_1v8: disabling [6.967527] dvdd_1v2: disabling [6.971006] vdd10_lcd: disabling [6.974701] vcc18_lcd: disabling [6.978467] ttyS2 - failed to request DMA [7.101883] mmc_host mmc0: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual 40HZ div = 0) [7.253874] mmc_host mmc0: Bus speed (slot 0) = 30Hz (slot req 30Hz, actual 30HZ div = 0) [7.405883] mmc_host mmc0: Bus speed (slot 0) = 20Hz (slot req 20Hz, actual 20HZ div = 0) [7.557885] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 10Hz, actual 93750HZ div = 1) [8.037872] mmc_host mmc0: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual 40HZ div = 0) [8.189877] mmc_host mmc0: Bus speed (slot 0) = 30Hz (slot req 30Hz, actual 30HZ div = 0) [8.341881] mmc_host mmc0: Bus speed (slot 0) = 20Hz (slot req 20Hz, actual 20HZ div = 0) [8.493884] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 10Hz, actual 93750HZ div = 1) [8.973871] mmc_host mmc0: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual 40HZ div = 0) [9.125876] mmc_host mmc0: Bus speed (slot 0) = 30Hz (slot req 30Hz, actual 30HZ div = 0) [9.277884] mmc_host mmc0: Bus speed (slot 0) = 20Hz (slot req 20Hz, actual 20HZ div = 0) [9.429882] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 10Hz, actual 93750HZ div = 1) looping here If I revert that patch, there are still lots of Bus speed messages, but finally would enter into system. Plz..Don't put the comment on the top. Which kernel did you use? Add linux-next specific files for 20161224 mmc0 is what card? Is it polling for detecting card? (It seems the SD-card..right?) Yes, but the Firefly release won't show that, just stop at "ttyS2 - failed to request DMA". I check both the firefly reload and firefly release, they both have a cd line for them, so it won't be poll mode. Those logs should be polled for detecting mmc0 card..Hmm..I sent the patch for disabling log message when polling. If this log is displayed, then my patch might be some wrong.. :( Best Regards, Jaehoon Chung [snip] -- 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 unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
On 12/29/2016 03:25 PM, Shawn Lin wrote:
On 2016/12/29 15:13, Jaehoon Chung wrote:
On 12/29/2016 12:02 PM, Jaehoon Chung wrote:
Hi Randy,
On 12/29/2016 12:34 AM, Randy Li wrote:
This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
It is reported that making RK3288 can't boot from eMMC/MMC.
Could you explain in more detail?
As you mentioned, this patch is making that RK3288 can't boot..then why?
Good way should be that finds the main reason and fixes it.
Not just revert.
To Shawn,
Could you check this? If you have rk3288..
If it's not working fine, it needs to revert this patch until finding
the problem.
Hrmm.as that patchset was tested based on rk3288 and rk3368, so I
need to know which board Randy are using now and could you share some
Sorry, XZY has asked me about this in the morning and I answer him that
I would give a feedback at home, so I didn't notice this mail.
The board is Firefly reload. but the reporter told me that Firefly
release also have the same problem.
log?
I will have a look at it.
Best Regards,
Jaehoon Chung
Best Regards,
Jaehoon Chung
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/mmc/host/dw_mmc-rockchip.c | 41
+++---
1 file changed, 3 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index 9a46e46..3189234 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include "dw_mmc.h"
@@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct
platform_device *pdev)
{
const struct dw_mci_drv_data *drv_data;
const struct of_device_id *match;
-int ret;
if (!pdev->dev.of_node)
return -ENODEV;
@@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct
platform_device *pdev)
match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
drv_data = match->data;
-pm_runtime_get_noresume(>dev);
-pm_runtime_set_active(>dev);
-pm_runtime_enable(>dev);
-pm_runtime_set_autosuspend_delay(>dev, 50);
-pm_runtime_use_autosuspend(>dev);
-
-ret = dw_mci_pltfm_register(pdev, drv_data);
-if (ret) {
-pm_runtime_disable(>dev);
-pm_runtime_set_suspended(>dev);
-pm_runtime_put_noidle(>dev);
-return ret;
-}
-
-pm_runtime_put_autosuspend(>dev);
-
-return 0;
+return dw_mci_pltfm_register(pdev, drv_data);
}
-static int dw_mci_rockchip_remove(struct platform_device *pdev)
-{
-pm_runtime_get_sync(>dev);
-pm_runtime_disable(>dev);
-pm_runtime_put_noidle(>dev);
-
-return dw_mci_pltfm_remove(pdev);
-}
-
-static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
-SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
-pm_runtime_force_resume)
-SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
- dw_mci_runtime_resume,
- NULL)
-};
-
static struct platform_driver dw_mci_rockchip_pltfm_driver = {
.probe= dw_mci_rockchip_probe,
-.remove= dw_mci_rockchip_remove,
+.remove= dw_mci_pltfm_remove,
.driver= {
.name= "dwmmc_rockchip",
.of_match_table= dw_mci_rockchip_match,
-.pm= _mci_rockchip_dev_pm_ops,
+.pm= _mci_pltfm_pmops,
},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
--
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 unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===
Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
On 12/29/2016 03:25 PM, Shawn Lin wrote:
On 2016/12/29 15:13, Jaehoon Chung wrote:
On 12/29/2016 12:02 PM, Jaehoon Chung wrote:
Hi Randy,
On 12/29/2016 12:34 AM, Randy Li wrote:
This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
It is reported that making RK3288 can't boot from eMMC/MMC.
Could you explain in more detail?
As you mentioned, this patch is making that RK3288 can't boot..then why?
Good way should be that finds the main reason and fixes it.
Not just revert.
To Shawn,
Could you check this? If you have rk3288..
If it's not working fine, it needs to revert this patch until finding
the problem.
Hrmm.as that patchset was tested based on rk3288 and rk3368, so I
need to know which board Randy are using now and could you share some
Sorry, XZY has asked me about this in the morning and I answer him that
I would give a feedback at home, so I didn't notice this mail.
The board is Firefly reload. but the reporter told me that Firefly
release also have the same problem.
log?
I will have a look at it.
Best Regards,
Jaehoon Chung
Best Regards,
Jaehoon Chung
Signed-off-by: Randy Li
---
drivers/mmc/host/dw_mmc-rockchip.c | 41
+++---
1 file changed, 3 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index 9a46e46..3189234 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include "dw_mmc.h"
@@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct
platform_device *pdev)
{
const struct dw_mci_drv_data *drv_data;
const struct of_device_id *match;
-int ret;
if (!pdev->dev.of_node)
return -ENODEV;
@@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct
platform_device *pdev)
match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
drv_data = match->data;
-pm_runtime_get_noresume(>dev);
-pm_runtime_set_active(>dev);
-pm_runtime_enable(>dev);
-pm_runtime_set_autosuspend_delay(>dev, 50);
-pm_runtime_use_autosuspend(>dev);
-
-ret = dw_mci_pltfm_register(pdev, drv_data);
-if (ret) {
-pm_runtime_disable(>dev);
-pm_runtime_set_suspended(>dev);
-pm_runtime_put_noidle(>dev);
-return ret;
-}
-
-pm_runtime_put_autosuspend(>dev);
-
-return 0;
+return dw_mci_pltfm_register(pdev, drv_data);
}
-static int dw_mci_rockchip_remove(struct platform_device *pdev)
-{
-pm_runtime_get_sync(>dev);
-pm_runtime_disable(>dev);
-pm_runtime_put_noidle(>dev);
-
-return dw_mci_pltfm_remove(pdev);
-}
-
-static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
-SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
-pm_runtime_force_resume)
-SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
- dw_mci_runtime_resume,
- NULL)
-};
-
static struct platform_driver dw_mci_rockchip_pltfm_driver = {
.probe= dw_mci_rockchip_probe,
-.remove= dw_mci_rockchip_remove,
+.remove= dw_mci_pltfm_remove,
.driver= {
.name= "dwmmc_rockchip",
.of_match_table= dw_mci_rockchip_match,
-.pm= _mci_rockchip_dev_pm_ops,
+.pm= _mci_pltfm_pmops,
},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
--
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 unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===
[PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
It is reported that making RK3288 can't boot from eMMC/MMC.
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/mmc/host/dw_mmc-rockchip.c | 41 +++---
1 file changed, 3 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index 9a46e46..3189234 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include "dw_mmc.h"
@@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct platform_device
*pdev)
{
const struct dw_mci_drv_data *drv_data;
const struct of_device_id *match;
- int ret;
if (!pdev->dev.of_node)
return -ENODEV;
@@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct platform_device
*pdev)
match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
drv_data = match->data;
- pm_runtime_get_noresume(>dev);
- pm_runtime_set_active(>dev);
- pm_runtime_enable(>dev);
- pm_runtime_set_autosuspend_delay(>dev, 50);
- pm_runtime_use_autosuspend(>dev);
-
- ret = dw_mci_pltfm_register(pdev, drv_data);
- if (ret) {
- pm_runtime_disable(>dev);
- pm_runtime_set_suspended(>dev);
- pm_runtime_put_noidle(>dev);
- return ret;
- }
-
- pm_runtime_put_autosuspend(>dev);
-
- return 0;
+ return dw_mci_pltfm_register(pdev, drv_data);
}
-static int dw_mci_rockchip_remove(struct platform_device *pdev)
-{
- pm_runtime_get_sync(>dev);
- pm_runtime_disable(>dev);
- pm_runtime_put_noidle(>dev);
-
- return dw_mci_pltfm_remove(pdev);
-}
-
-static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
- SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
- dw_mci_runtime_resume,
- NULL)
-};
-
static struct platform_driver dw_mci_rockchip_pltfm_driver = {
.probe = dw_mci_rockchip_probe,
- .remove = dw_mci_rockchip_remove,
+ .remove = dw_mci_pltfm_remove,
.driver = {
.name = "dwmmc_rockchip",
.of_match_table = dw_mci_rockchip_match,
- .pm = _mci_rockchip_dev_pm_ops,
+ .pm = _mci_pltfm_pmops,
},
};
--
2.7.4
[PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
It is reported that making RK3288 can't boot from eMMC/MMC.
Signed-off-by: Randy Li
---
drivers/mmc/host/dw_mmc-rockchip.c | 41 +++---
1 file changed, 3 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index 9a46e46..3189234 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include "dw_mmc.h"
@@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct platform_device
*pdev)
{
const struct dw_mci_drv_data *drv_data;
const struct of_device_id *match;
- int ret;
if (!pdev->dev.of_node)
return -ENODEV;
@@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct platform_device
*pdev)
match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
drv_data = match->data;
- pm_runtime_get_noresume(>dev);
- pm_runtime_set_active(>dev);
- pm_runtime_enable(>dev);
- pm_runtime_set_autosuspend_delay(>dev, 50);
- pm_runtime_use_autosuspend(>dev);
-
- ret = dw_mci_pltfm_register(pdev, drv_data);
- if (ret) {
- pm_runtime_disable(>dev);
- pm_runtime_set_suspended(>dev);
- pm_runtime_put_noidle(>dev);
- return ret;
- }
-
- pm_runtime_put_autosuspend(>dev);
-
- return 0;
+ return dw_mci_pltfm_register(pdev, drv_data);
}
-static int dw_mci_rockchip_remove(struct platform_device *pdev)
-{
- pm_runtime_get_sync(>dev);
- pm_runtime_disable(>dev);
- pm_runtime_put_noidle(>dev);
-
- return dw_mci_pltfm_remove(pdev);
-}
-
-static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
- SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
- dw_mci_runtime_resume,
- NULL)
-};
-
static struct platform_driver dw_mci_rockchip_pltfm_driver = {
.probe = dw_mci_rockchip_probe,
- .remove = dw_mci_rockchip_remove,
+ .remove = dw_mci_pltfm_remove,
.driver = {
.name = "dwmmc_rockchip",
.of_match_table = dw_mci_rockchip_match,
- .pm = _mci_rockchip_dev_pm_ops,
+ .pm = _mci_pltfm_pmops,
},
};
--
2.7.4
[PATCH v10 0/2] the fixup for the USB HOST1 at rk3288 platform
changelog: v10 minior fixup v9 use a work_queue to reset usb phy to prevent access mutex lock at interrupter runtime. v8 minior fixup v7 add the forgot dummy phy_reset() for the generic phy is disabled. v7 Some minor fixup v6 Send the last two patches v5 A few modification at style, add the missing doc in the last commit. v4 1. Adding the reset callback in struct phy_ops. 2. Moving the reset into phy rockchip usb. 3. Trying to call a reset when dwc2 wakeup in rk3288. v3 Rebased from previous commit v2 Rebased from previous commit v1 orignal from google Randy Li (2): usb: dwc2: assert phy reset when waking up in rk3288 platform ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset arch/arm/boot/dts/rk3288.dtsi | 4 drivers/usb/dwc2/core.h | 1 + drivers/usb/dwc2/core_intr.c | 11 +++ drivers/usb/dwc2/platform.c | 9 + 4 files changed, 25 insertions(+) -- 2.7.4
[PATCH v10 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform
On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).
We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.
We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset. The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).
It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.
Signed-off-by: Randy Li <ay...@soulik.info>
Acked-by: John Youn <johny...@synopsys.com>
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/core_intr.c | 11 +++
drivers/usb/dwc2/platform.c | 9 +
3 files changed, 21 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e..0cd5896 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -919,6 +919,7 @@ struct dwc2_hsotg {
unsigned int ll_hw_enabled:1;
struct phy *phy;
+ struct work_struct phy_rst_work;
struct usb_phy *uphy;
struct dwc2_hsotg_plat *plat;
struct regulator_bulk_data
supplies[ARRAY_SIZE(dwc2_hsotg_supply_names)];
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 5b228ba..bf1c029 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg
*hsotg)
static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
{
int ret;
+ struct device_node *np = hsotg->dev->of_node;
/* Clear interrupt */
dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
@@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct
dwc2_hsotg *hsotg)
/* Restart the Phy Clock */
pcgcctl &= ~PCGCTL_STOPPCLK;
dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
+
+ /*
+* It is a quirk in Rockchip RK3288, causing by
+* a hardware bug. This will propagate out and
+* eventually we'll re-enumerate the device.
+* Not great but the best we can do.
+*/
+ if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
+ schedule_work(>phy_rst_work);
+
mod_timer(>wkp_timer,
jiffies + msecs_to_jiffies(71));
} else {
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 4fc8c60..8ef278e 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -207,6 +207,14 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
return ret;
}
+/* Only used to reset usb phy at interrupter runtime */
+static void dwc2_reset_phy_work(struct work_struct *data)
+{
+ struct dwc2_hsotg *hsotg = container_of(data, struct dwc2_hsotg,
+ phy_rst_work);
+ phy_reset(hsotg->phy);
+}
+
static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
{
int i, ret;
@@ -251,6 +259,7 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
return ret;
}
}
+ INIT_WORK(>phy_rst_work, dwc2_reset_phy_work);
if (!hsotg->phy) {
hsotg->uphy = devm_usb_get_phy(hsotg->dev, USB_PHY_TYPE_USB2);
--
2.7.4
