Re: [PATCH 0/4] WIP: rockchip mpp for v4l2 video decoder

[Ayaka]

Sent from my iPad

> On Jan 31, 2019, at 10:03 PM, Ezequiel Garcia  wrote:
> 
> Hey Ayaka!
> 
>> On Thu, 2019-01-31 at 11:13 +0800, ayaka wrote:
>> From: Randy 'ayaka' Li 
>> 
>> Hello
>>  Those patches are based on the previous vendor driver I post before,
>> but it can apply without the previous one.
>>  I really want to make it work before FOSDEM and I didn't. And upcoming
>> the lunar new year holiday would last two week.
>> 
>>  I have verified the v4l2 part but I meet a problem with power or
>> clock, it would be a complex problem, I would handle to solve it after I
>> am back. But I just tell my design on this kind dirver.
>> 
> 
> This the branch I'm about to submit:
> 
> http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/vpu-mpeg-2-almost-ready-for-upstream
> 
> And it has no power issues. Perhaps you can take a look inside,
> you might be just missing a few pm_ statements? Perhaps a devicetree thing?
> 
I don’t think it is a complex problem, just I waste too time on v4l2 part
All the current clock frequency at rk3328 is too low for H.264 decoding you may 
find my previous mail.
>> A few questions I think you may ask I would like to answer it here.
>> 
> 
> I have another question: is this patchset meant to support for mpeg-2
> decoding only? I can't find any other codec code.
> 
I have not. I would like to move my work on userspace interface later, as I 
said in IRC.
MPEG-2 is just a simple codec I choose for demo(userspace and some not normal 
picture coded like fileds) and if there is a codec parser there, I can solve it 
easily.
Adding support to new codec is not complex in this driver once the interface 
problem is solved. I just copy the public rockchip mpp userspace library into 
it. It is the other advantage use the register structure.
But I do like people to merge the final version I submit, I would prove it why 
later.
> Thanks,
> Ezequiel
> 
>> 1. Why it is based on the previous vendor driver ?
>> The vendor driver I post to mail list is a clean version which having a
>> efficient work flow and those platform dependency controls having been
>> merged into it.
>> 
>> For the stateless device, V4L2 is just another interface for userspace
>> to translate it into registers.
>> 
>> 2. Why use a structure to store register infomation not marco ?
>> I really don't want to define many marcos for a device having more than
>> a hundred of registers. And there are many fields in a registers.
>> 
>> For the VDPU1/VDPU2 which would support more than 10 video codecs, these
>> two devices would re-use many registers for many codecs, It would be
>> hard to show the conflict relations between them in marco but more easy
>> with C union and structure.
>> 
>> BTW, I would prefer to write a number of registers into the device
>> though AHB bus not just generate one then write one, you can save some
>> times here.
>> 
>> 
>> Besides the two previous answers. I really have a big problem with v4l2
>> design. Which would driver wait the work of the previous picture is
>> done, leading a large gap time more idle of the device. 
>> 
>> I am ok the current face that v4l2 stateless driver is not stateless.
>> But it would limit the ability of stateless decoder. It is more flexible
>> to those videos having different resolution or orientation sequences.
>> 
>> But I don't like the method to reconstruct the bitstream in driver, it
>> is a bad idea to limit what data the device want. Those problem is
>> mainly talking in the HEVC slice thread. And it was ironic for the VPx
>> serial codec, which mixed compressed data and umcompress header together
>> and twisted. Even for the ITU H serial codec, it would become a problem
>> in SVC or Google Android CTS test.
>> 
>> And thanks kwiboo, ezequielg and Paulk, I copy some v4l2 code from their
>> code.
>> 
>> Randy Li (1):
>>  staging: video: rockchip: add video codec
>> 
>> ayaka (3):
>>  [WIP]: staging: video: rockchip: add v4l2 common
>>  [WIP] staging: video: rockchip: vdpu2
>>  [TEST]: rockchip: mpp: support qtable
>> 
>> drivers/staging/Kconfig   |2 +
>> drivers/staging/Makefile  |1 +
>> drivers/staging/rockchip-mpp/Kconfig  |   54 +
>> drivers/staging/rockchip-mpp/Makefile |8 +
>> drivers/staging/rockchip-mpp/mpp_debug.h  |   87 ++
>> drivers/staging/rockchip-mpp/mpp_dev_common.c | 1365 +
>> drivers/staging/rockchip-mpp/mpp_dev_common.h |  215 +++
>> drivers/staging/rockchip-mpp/mpp_de

[PATCH 4/4] staging: video: rockchip: add video codec

[ayaka]

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 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 0/4] WIP: rockchip mpp for v4l2 video decoder

[ayaka]

From: Randy 'ayaka' Li 

Hello
  Those patches are based on the previous vendor driver I post before,
but it can apply without the previous one.
  I really want to make it work before FOSDEM and I didn't. And upcoming
the lunar new year holiday would last two week.

  I have verified the v4l2 part but I meet a problem with power or
clock, it would be a complex problem, I would handle to solve it after I
am back. But I just tell my design on this kind dirver.

A few questions I think you may ask I would like to answer it here.

1. Why it is based on the previous vendor driver ?
The vendor driver I post to mail list is a clean version which having a
efficient work flow and those platform dependency controls having been
merged into it.

For the stateless device, V4L2 is just another interface for userspace
to translate it into registers.

2. Why use a structure to store register infomation not marco ?
I really don't want to define many marcos for a device having more than
a hundred of registers. And there are many fields in a registers.

For the VDPU1/VDPU2 which would support more than 10 video codecs, these
two devices would re-use many registers for many codecs, It would be
hard to show the conflict relations between them in marco but more easy
with C union and structure.

BTW, I would prefer to write a number of registers into the device
though AHB bus not just generate one then write one, you can save some
times here.


Besides the two previous answers. I really have a big problem with v4l2
design. Which would driver wait the work of the previous picture is
done, leading a large gap time more idle of the device. 

I am ok the current face that v4l2 stateless driver is not stateless.
But it would limit the ability of stateless decoder. It is more flexible
to those videos having different resolution or orientation sequences.

But I don't like the method to reconstruct the bitstream in driver, it
is a bad idea to limit what data the device want. Those problem is
mainly talking in the HEVC slice thread. And it was ironic for the VPx
serial codec, which mixed compressed data and umcompress header together
and twisted. Even for the ITU H serial codec, it would become a problem
in SVC or Google Android CTS test.

And thanks kwiboo, ezequielg and Paulk, I copy some v4l2 code from their
code.

Randy Li (1):
  staging: video: rockchip: add video codec

ayaka (3):
  [WIP]: staging: video: rockchip: add v4l2 common
  [WIP] staging: video: rockchip: vdpu2
  [TEST]: rockchip: mpp: support qtable

 drivers/staging/Kconfig   |2 +
 drivers/staging/Makefile  |1 +
 drivers/staging/rockchip-mpp/Kconfig  |   54 +
 drivers/staging/rockchip-mpp/Makefile |8 +
 drivers/staging/rockchip-mpp/mpp_debug.h  |   87 ++
 drivers/staging/rockchip-mpp/mpp_dev_common.c | 1365 +
 drivers/staging/rockchip-mpp/mpp_dev_common.h |  215 +++
 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c |  878 +++
 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c  |  755 +
 drivers/staging/rockchip-mpp/mpp_service.c|  197 +++
 drivers/staging/rockchip-mpp/mpp_service.h|   38 +
 drivers/staging/rockchip-mpp/rkvdec/hal.h |   53 +
 drivers/staging/rockchip-mpp/rkvdec/regs.h|  395 +
 drivers/staging/rockchip-mpp/vdpu2/hal.h  |   52 +
 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c|  253 +++
 drivers/staging/rockchip-mpp/vdpu2/regs.h |  699 +
 16 files changed, 5052 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/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 3/4] [TEST]: rockchip: mpp: support qtable

[ayaka]

Yes, the buffer won't be freed.
I don't want to store buffers for a session.
I just want to use it to verify the FFmpeg.

Signed-off-by: ayaka 
---
 drivers/staging/rockchip-mpp/mpp_dev_common.h |  3 ++
 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c  |  3 ++
 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 42 +++
 3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.h 
b/drivers/staging/rockchip-mpp/mpp_dev_common.h
index 36770af53a95..33d7725be67b 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.h
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.h
@@ -100,6 +100,9 @@ struct mpp_session {
struct v4l2_ctrl_handler ctrl_handler;
/* TODO: FIXME: slower than helper function ? */
struct v4l2_ctrl **ctrls;
+
+   dma_addr_t qtable_addr;
+   void *qtable_vaddr;
 };
 
 /* The context for the a task */
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c 
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
index 03ed080bb35c..9e00501c3577 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
@@ -402,6 +402,9 @@ static int rkvdpu_open(struct file *filp)
return error;
}
 
+   session->qtable_vaddr = dmam_alloc_coherent(mpp_dev->dev, 64 * 4,
+   >qtable_addr,
+   GFP_KERNEL);
filp->private_data = >fh;
 
mpp_debug_leave();
diff --git a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c 
b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
index a16f7629a811..416348630779 100644
--- a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
+++ b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
@@ -27,6 +27,34 @@
 
 #define DEC_LITTLE_ENDIAN  (1)
 
+static const u8 zigzag[64] = {
+   0,   1,  8, 16,  9,  2,  3, 10,
+   17, 24, 32, 25, 18, 11,  4,  5,
+   12, 19, 26, 33, 40, 48, 41, 34,
+   27, 20, 13,  6,  7, 14, 21, 28,
+   35, 42, 49, 56, 57, 50, 43, 36,
+   29, 22, 15, 23, 30, 37, 44, 51,
+   58, 59, 52, 45, 38, 31, 39, 46,
+   53, 60, 61, 54, 47, 55, 62, 63
+};
+
+static void mpeg2_dec_copy_qtable(u8 *qtable,
+   const struct v4l2_ctrl_mpeg2_quantization *ctrl)
+{
+   int i, n;
+
+   if (!qtable || !ctrl)
+   return;
+
+   for (i = 0; i < 64; i++) {
+   n = zigzag[i];
+   qtable[n + 0] = ctrl->intra_quantiser_matrix[i];
+   qtable[n + 64] = ctrl->non_intra_quantiser_matrix[i];
+   qtable[n + 128] = ctrl->chroma_intra_quantiser_matrix[i];
+   qtable[n + 192] = ctrl->chroma_non_intra_quantiser_matrix[i];
+   }
+}
+
 static void init_hw_cfg(struct vdpu2_regs *p_regs)
 {
 p_regs->sw54.dec_strm_wordsp = 1;
@@ -61,7 +89,6 @@ 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;
struct sg_table *sgt;
@@ -69,9 +96,6 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session, void 
*regs,
 
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;

@@ -164,6 +188,7 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session, 
void *regs)
 {
const struct v4l2_ctrl_mpeg2_slice_params *params;
const struct v4l2_mpeg2_sequence *sequence;
+   const struct v4l2_ctrl_mpeg2_quantization *quantization;
const struct v4l2_mpeg2_picture *picture;
struct vb2_v4l2_buffer *dst_buf;
dma_addr_t cur_addr, fwd_addr, bwd_addr;
@@ -177,6 +202,9 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session, 
void *regs)
picture = >picture;
sequence = >sequence;
 
+   quantization = rockchip_mpp_get_cur_ctrl(session,
+   V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
+
dst_buf = v4l2_m2m_next_dst_buf(session->fh.m2m_ctx);
 
sgt = vb2_dma_sg_plane_desc(_buf->vb2_buf, 0);
@@ -219,9 +247,7 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session, 
void *regs)
p_regs->sw134.refer2_base = bwd_addr >> 2;
p_regs->sw135.refer3_base = bwd_addr >> 2;
 
-#if 0
-//ref & qtable config
-p_regs->sw61.qtable_base = mpp_buffer_get_fd(ctx->qp_table);
-#endif
+   mpeg2_dec_copy_qtable(session->qtable_vaddr, quantization);
+p_regs->sw61.qtable_base = session->qtable_addr;
return 0;
 }
-- 
2.20.1

[PATCH 2/4] [WIP] staging: video: rockchip: vdpu2

[ayaka]

From: Randy 'ayaka' Li 

It doesn't work yet, I am suffering unknow power or
clock problem, but the vendor driver I post to ML
would work.

I want to put the implementation of those v4l2 ioctl
which related to device in echo device's files, but
the current inheritance looks ugly.

TODO:
qp table

Signed-off-by: Randy Li 
Signed-off-by: Randy Li 
---
 drivers/staging/rockchip-mpp/Makefile|   2 +-
 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 588 ++--
 drivers/staging/rockchip-mpp/vdpu2/hal.h |  52 ++
 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c   | 227 ++
 drivers/staging/rockchip-mpp/vdpu2/regs.h| 699 +++
 5 files changed, 1361 insertions(+), 207 deletions(-)
 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/Makefile 
b/drivers/staging/rockchip-mpp/Makefile
index 36d2958ea7f4..5aa0c596b706 100644
--- a/drivers/staging/rockchip-mpp/Makefile
+++ b/drivers/staging/rockchip-mpp/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 rk-mpp-service-objs := mpp_service.o
 rk-mpp-device-objs := mpp_dev_common.o
-rk-mpp-vdpu2-objs := mpp_dev_vdpu2.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
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c 
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
index 5789c8940543..03ed080bb35c 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
@@ -24,61 +24,18 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #include "mpp_debug.h"
 #include "mpp_dev_common.h"
+#include "vdpu2/hal.h"
 
 #define RKVDPU2_DRIVER_NAME"mpp_vdpu2"
 #define RKVDPU2_NODE_NAME  "vpu-service"
 
-/* The maximum registers number of all the version */
-#define ROCKCHIP_VDPU2_REG_NUM 159
-
-/* The first register of the decoder is Reg50(0x000c8) */
-#define RKVDPU2_REG_DEC_CTRL   0x0c8
-#define RKVDPU2_REG_DEC_CTRL_INDEX (50)
-
-#define RKVDPU2_REG_SYS_CTRL   0x0d4
-#define RKVDPU2_REG_SYS_CTRL_INDEX (53)
-#defineRKVDPU2_GET_FORMAT(x)   ((x) & 0xf)
-#defineRKVDPU2_FMT_H264D   0
-#defineRKVDPU2_FMT_MPEG4D  1
-#defineRKVDPU2_FMT_H263D   2
-#defineRKVDPU2_FMT_JPEGD   3
-#defineRKVDPU2_FMT_VC1D4
-#defineRKVDPU2_FMT_MPEG2D  5
-#defineRKVDPU2_FMT_MPEG1D  6
-#defineRKVDPU2_FMT_VP6D7
-#defineRKVDPU2_FMT_RESERVED8
-#defineRKVDPU2_FMT_VP7D9
-#defineRKVDPU2_FMT_VP8D10
-#defineRKVDPU2_FMT_AVSD11
-
-#define RKVDPU2_REG_DEC_INT_EN 0x0dc
-#define RKVDPU2_REG_DEC_INT_EN_INDEX   (55)
-#defineRKVDPU2_INT_TIMEOUT BIT(13)
-#defineRKVDPU2_INT_STRM_ERROR  BIT(12)
-#defineRKVDPU2_INT_SLICE   BIT(9)
-#defineRKVDPU2_INT_ASO_ERROR   BIT(8)
-#defineRKVDPU2_INT_BUF_EMPTY   BIT(6)
-#defineRKVDPU2_INT_BUS_ERROR   BIT(5)
-#defineRKVDPU2_DEC_INT BIT(4)
-#defineRKVDPU2_DEC_IRQ_DIS BIT(1)
-#defineRKVDPU2_DEC_INT_RAW BIT(0)
-
-#define RKVDPU2_REG_DEC_DEV_CTRL   0x0e4
-#define RKVDPU2_REG_DEC_DEV_CTRL_INDEX (57)
-#defineRKVDPU2_DEC_CLOCK_GATE_EN   BIT(4)
-#defineRKVDPU2_DEC_START   BIT(0)
-
-#define RKVDPU2_REG59  0x0ec
-#define RKVDPU2_REG59_INDEX(59)
-
-#define RKVDPU2_REG_DIR_MV_BASE 0x0f8
-#define RKVDPU2_REG_DIR_MV_BASE_INDEX   (62)
-
-#define RKVDPU2_REG_STREAM_RLC_BASE0x100
-#define RKVDPU2_REG_STREAM_RLC_BASE_INDEX  (64)
-
 #define to_rkvdpu_task(ctx)\
container_of(ctx, struct rkvdpu_task, mpp_task)
 #define to_rkvdpu_dev(dev) \
@@ -102,184 +59,389 @@ struct rkvdpu_task {
 
u32 reg[ROCKCHIP_VDPU2_REG_NUM];
u32 idx;
-   struct extra_info_for_iommu ext_inf;
 
u32 strm_base;
u32 irq_status;
 };
 
-/*
- * file handle translate information
- */
-static const char trans_tbl_default[] = {
-   61, 62, 63, 64, 131, 134, 135, 148
+static struct rockchip_mpp_control vdpu_controls[] = {
+   {
+ 

[PATCH 1/4] [WIP]: staging: video: rockchip: add v4l2 common

[ayaka]

From: Randy 'ayaka' Li 

The current version is designed for multi-planes
buffers.

TODO:
improve the interface and work flow of v4l2
finish a task before it would be dequeued

Signed-off-by: Randy Li 
Signed-off-by: Randy Li 
---
 drivers/staging/rockchip-mpp/Kconfig  |   54 +
 drivers/staging/rockchip-mpp/Makefile |8 +
 drivers/staging/rockchip-mpp/mpp_debug.h  |   87 ++
 drivers/staging/rockchip-mpp/mpp_dev_common.c | 1365 +
 drivers/staging/rockchip-mpp/mpp_dev_common.h |  212 +++
 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c |  878 +++
 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c  |  576 +++
 drivers/staging/rockchip-mpp/mpp_service.c|  197 +++
 drivers/staging/rockchip-mpp/mpp_service.h|   38 +
 drivers/staging/rockchip-mpp/rkvdec/hal.h |   53 +
 drivers/staging/rockchip-mpp/rkvdec/regs.h|  395 +
 11 files changed, 3863 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/regs.h

diff --git a/drivers/staging/rockchip-mpp/Kconfig 
b/drivers/staging/rockchip-mpp/Kconfig
new file mode 100644
index ..9d58cd1ab6e4
--- /dev/null
+++ b/drivers/staging/rockchip-mpp/Kconfig
@@ -0,0 +1,54 @@
+# 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_SG
+   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 ..36d2958ea7f4
--- /dev/null
+++ b/drivers/staging/rockchip-mpp/Makefile
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0
+rk-mpp-service-objs := mpp_service.o
+rk-mpp-device-objs := mpp_dev_common.o
+rk-mpp-vdpu2-objs := mpp_dev_vdpu2.o
+
+obj-$(CONFIG_ROCKCHIP_MPP_SERVICE) += rk-mpp-service.o
+obj-$(CONFIG_ROCKCHIP_MPP_DEVICE) += rk-mpp-device.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 details.
+ *
+ */
+
+#ifndef _ROCKCHIP_MPP_DEBUG_H_
+#define _ROCKCHIP_MPP_DEBUG_H_
+
+#include 
+
+/*
+ * debug flag usage:
+ * +--+---+
+ * | 8bit |  24bit|
+ * +--+---+
+ *  0~23 bit is for different informatio

Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[Ayaka]

Sent from my iPad

> On Jan 30, 2019, at 3:17 PM, Tomasz Figa  wrote:
> 
>> On Wed, Jan 30, 2019 at 3:28 PM Ayaka  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jan 30, 2019, at 11:35 AM, Tomasz Figa  wrote:
>>> 
>>> On Wed, Jan 30, 2019 at 11:29 AM Alexandre Courbot
>>>  wrote:
>>>> 
>>>>>> On Wed, Jan 30, 2019 at 6:41 AM Nicolas Dufresne  
>>>>>> wrote:
>>>>>> 
>>>>>> Le mardi 29 janvier 2019 à 16:44 +0900, Alexandre Courbot a écrit :
>>>>>> On Fri, Jan 25, 2019 at 10:04 PM Paul Kocialkowski
>>>>>>  wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>>> On Thu, 2019-01-24 at 20:23 +0800, Ayaka wrote:
>>>>>>>> Sent from my iPad
>>>>>>>> 
>>>>>>>>> On Jan 24, 2019, at 6:27 PM, Paul Kocialkowski 
>>>>>>>>>  wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>>> On Thu, 2019-01-10 at 21:32 +0800, ayaka wrote:
>>>>>>>>>> I forget a important thing, for the rkvdec and rk hevc decoder, it 
>>>>>>>>>> would
>>>>>>>>>> requests cabac table, scaling list, picture parameter set and 
>>>>>>>>>> reference
>>>>>>>>>> picture storing in one or various of DMA buffers. I am not talking 
>>>>>>>>>> about
>>>>>>>>>> the data been parsed, the decoder would requests a raw data.
>>>>>>>>>> 
>>>>>>>>>> For the pps and rps, it is possible to reuse the slice header, just 
>>>>>>>>>> let
>>>>>>>>>> the decoder know the offset from the bitstream bufer, I would 
>>>>>>>>>> suggest to
>>>>>>>>>> add three properties(with sps) for them. But I think we need a 
>>>>>>>>>> method to
>>>>>>>>>> mark a OUTPUT side buffer for those aux data.
>>>>>>>>> 
>>>>>>>>> I'm quite confused about the hardware implementation then. From what
>>>>>>>>> you're saying, it seems that it takes the raw bitstream elements 
>>>>>>>>> rather
>>>>>>>>> than parsed elements. Is it really a stateless implementation?
>>>>>>>>> 
>>>>>>>>> The stateless implementation was designed with the idea that only the
>>>>>>>>> raw slice data should be passed in bitstream form to the decoder. For
>>>>>>>>> H.264, it seems that some decoders also need the slice header in raw
>>>>>>>>> bitstream form (because they take the full slice NAL unit), see the
>>>>>>>>> discussions in this thread:
>>>>>>>>> media: docs-rst: Document m2m stateless video decoder interface
>>>>>>>> 
>>>>>>>> Stateless just mean it won’t track the previous result, but I don’t
>>>>>>>> think you can define what a date the hardware would need. Even you
>>>>>>>> just build a dpb for the decoder, it is still stateless, but parsing
>>>>>>>> less or more data from the bitstream doesn’t stop a decoder become a
>>>>>>>> stateless decoder.
>>>>>>> 
>>>>>>> Yes fair enough, the format in which the hardware decoder takes the
>>>>>>> bitstream parameters does not make it stateless or stateful per-se.
>>>>>>> It's just that stateless decoders should have no particular reason for
>>>>>>> parsing the bitstream on their own since the hardware can be designed
>>>>>>> with registers for each relevant bitstream element to configure the
>>>>>>> decoding pipeline. That's how GPU-based decoder implementations are
>>>>>>> implemented (VAAPI/VDPAU/NVDEC, etc).
>>>>>>> 
>>>>>>> So the format we have agreed on so far for the stateless interface is
>>>>>>> to pass parsed elements via v4l2 control structures.
>>>>>>> 
>>>>>>> If the hardware can only work by parsing the bitstream itself, I'm not
>>

Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[Ayaka]

Sent from my iPad

> On Jan 30, 2019, at 5:41 AM, Nicolas Dufresne  wrote:
> 
>> Le mardi 29 janvier 2019 à 16:44 +0900, Alexandre Courbot a écrit :
>> On Fri, Jan 25, 2019 at 10:04 PM Paul Kocialkowski
>>  wrote:
>>> Hi,
>>> 
>>>> On Thu, 2019-01-24 at 20:23 +0800, Ayaka wrote:
>>>> Sent from my iPad
>>>> 
>>>>> On Jan 24, 2019, at 6:27 PM, Paul Kocialkowski 
>>>>>  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> On Thu, 2019-01-10 at 21:32 +0800, ayaka wrote:
>>>>>> I forget a important thing, for the rkvdec and rk hevc decoder, it would
>>>>>> requests cabac table, scaling list, picture parameter set and reference
>>>>>> picture storing in one or various of DMA buffers. I am not talking about
>>>>>> the data been parsed, the decoder would requests a raw data.
>>>>>> 
>>>>>> For the pps and rps, it is possible to reuse the slice header, just let
>>>>>> the decoder know the offset from the bitstream bufer, I would suggest to
>>>>>> add three properties(with sps) for them. But I think we need a method to
>>>>>> mark a OUTPUT side buffer for those aux data.
>>>>> 
>>>>> I'm quite confused about the hardware implementation then. From what
>>>>> you're saying, it seems that it takes the raw bitstream elements rather
>>>>> than parsed elements. Is it really a stateless implementation?
>>>>> 
>>>>> The stateless implementation was designed with the idea that only the
>>>>> raw slice data should be passed in bitstream form to the decoder. For
>>>>> H.264, it seems that some decoders also need the slice header in raw
>>>>> bitstream form (because they take the full slice NAL unit), see the
>>>>> discussions in this thread:
>>>>> media: docs-rst: Document m2m stateless video decoder interface
>>>> 
>>>> Stateless just mean it won’t track the previous result, but I don’t
>>>> think you can define what a date the hardware would need. Even you
>>>> just build a dpb for the decoder, it is still stateless, but parsing
>>>> less or more data from the bitstream doesn’t stop a decoder become a
>>>> stateless decoder.
>>> 
>>> Yes fair enough, the format in which the hardware decoder takes the
>>> bitstream parameters does not make it stateless or stateful per-se.
>>> It's just that stateless decoders should have no particular reason for
>>> parsing the bitstream on their own since the hardware can be designed
>>> with registers for each relevant bitstream element to configure the
>>> decoding pipeline. That's how GPU-based decoder implementations are
>>> implemented (VAAPI/VDPAU/NVDEC, etc).
>>> 
>>> So the format we have agreed on so far for the stateless interface is
>>> to pass parsed elements via v4l2 control structures.
>>> 
>>> If the hardware can only work by parsing the bitstream itself, I'm not
>>> sure what the best solution would be. Reconstructing the bitstream in
>>> the kernel is a pretty bad option, but so is parsing in the kernel or
>>> having the data both in parsed and raw forms. Do you see another
>>> possibility?
>> 
>> Is reconstructing the bitstream so bad? The v4l2 controls provide a
>> generic interface to an encoded format which the driver needs to
>> convert into a sequence that the hardware can understand. Typically
>> this is done by populating hardware-specific structures. Can't we
>> consider that in this specific instance, the hardware-specific
>> structure just happens to be identical to the original bitstream
>> format?
> 
> At maximum allowed bitrate for let's say HEVC (940MB/s iirc), yes, it
Lucky, most of hardware won’t be able to processing such a big buffer.
General speaking, the register is 24bits for stream length in bytes.
> would be really really bad. In GStreamer project we have discussed for
> a while (but have never done anything about) adding the ability through
> a bitmask to select which part of the stream need to be parsed, as
> parsing itself was causing some overhead. Maybe similar thing applies,
> though as per our new design, it's the fourcc that dictate the driver
> behaviour, we'd need yet another fourcc for drivers that wants the full
> bitstream (which seems odd if you have already parsed everything, I
> think this need some clarification).
> 
>> 
>> I agree that this is not strictly optimal for that particular
>> hardware, but such is the cost of abstractions, and in this specific
>> case I don't believe the cost would be particularly high?

Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[Ayaka]

Sent from my iPad

> On Jan 30, 2019, at 11:35 AM, Tomasz Figa  wrote:
> 
> On Wed, Jan 30, 2019 at 11:29 AM Alexandre Courbot
>  wrote:
>> 
>>> On Wed, Jan 30, 2019 at 6:41 AM Nicolas Dufresne  
>>> wrote:
>>> 
>>>> Le mardi 29 janvier 2019 à 16:44 +0900, Alexandre Courbot a écrit :
>>>> On Fri, Jan 25, 2019 at 10:04 PM Paul Kocialkowski
>>>>  wrote:
>>>>> Hi,
>>>>> 
>>>>>> On Thu, 2019-01-24 at 20:23 +0800, Ayaka wrote:
>>>>>> Sent from my iPad
>>>>>> 
>>>>>>> On Jan 24, 2019, at 6:27 PM, Paul Kocialkowski 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>>> On Thu, 2019-01-10 at 21:32 +0800, ayaka wrote:
>>>>>>>> I forget a important thing, for the rkvdec and rk hevc decoder, it 
>>>>>>>> would
>>>>>>>> requests cabac table, scaling list, picture parameter set and reference
>>>>>>>> picture storing in one or various of DMA buffers. I am not talking 
>>>>>>>> about
>>>>>>>> the data been parsed, the decoder would requests a raw data.
>>>>>>>> 
>>>>>>>> For the pps and rps, it is possible to reuse the slice header, just let
>>>>>>>> the decoder know the offset from the bitstream bufer, I would suggest 
>>>>>>>> to
>>>>>>>> add three properties(with sps) for them. But I think we need a method 
>>>>>>>> to
>>>>>>>> mark a OUTPUT side buffer for those aux data.
>>>>>>> 
>>>>>>> I'm quite confused about the hardware implementation then. From what
>>>>>>> you're saying, it seems that it takes the raw bitstream elements rather
>>>>>>> than parsed elements. Is it really a stateless implementation?
>>>>>>> 
>>>>>>> The stateless implementation was designed with the idea that only the
>>>>>>> raw slice data should be passed in bitstream form to the decoder. For
>>>>>>> H.264, it seems that some decoders also need the slice header in raw
>>>>>>> bitstream form (because they take the full slice NAL unit), see the
>>>>>>> discussions in this thread:
>>>>>>> media: docs-rst: Document m2m stateless video decoder interface
>>>>>> 
>>>>>> Stateless just mean it won’t track the previous result, but I don’t
>>>>>> think you can define what a date the hardware would need. Even you
>>>>>> just build a dpb for the decoder, it is still stateless, but parsing
>>>>>> less or more data from the bitstream doesn’t stop a decoder become a
>>>>>> stateless decoder.
>>>>> 
>>>>> Yes fair enough, the format in which the hardware decoder takes the
>>>>> bitstream parameters does not make it stateless or stateful per-se.
>>>>> It's just that stateless decoders should have no particular reason for
>>>>> parsing the bitstream on their own since the hardware can be designed
>>>>> with registers for each relevant bitstream element to configure the
>>>>> decoding pipeline. That's how GPU-based decoder implementations are
>>>>> implemented (VAAPI/VDPAU/NVDEC, etc).
>>>>> 
>>>>> So the format we have agreed on so far for the stateless interface is
>>>>> to pass parsed elements via v4l2 control structures.
>>>>> 
>>>>> If the hardware can only work by parsing the bitstream itself, I'm not
>>>>> sure what the best solution would be. Reconstructing the bitstream in
>>>>> the kernel is a pretty bad option, but so is parsing in the kernel or
>>>>> having the data both in parsed and raw forms. Do you see another
>>>>> possibility?
>>>> 
>>>> Is reconstructing the bitstream so bad? The v4l2 controls provide a
>>>> generic interface to an encoded format which the driver needs to
>>>> convert into a sequence that the hardware can understand. Typically
>>>> this is done by populating hardware-specific structures. Can't we
>>>> consider that in this specific instance, the hardware-specific
>>>> structure just happens to be identical to the original bitstream
>>>> format?
>

Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls.

[Ayaka]

Sent from my iPad

> On Jan 24, 2019, at 10:23 PM, Maxime Ripard  wrote:
> 
> Hi!
> 
> On Sun, Jan 20, 2019 at 08:48:32PM +0800, ayaka wrote:
>>>>> +struct v4l2_ctrl_h264_scaling_matrix {
>>>>> +__u8 scaling_list_4x4[6][16];
>>>>> +__u8 scaling_list_8x8[6][64];
>>>>> +};
>>>> I wonder which decoder want this.
>>> I'm not sure I follow you, scaling lists are an important part of the
>>> decoding process, so all of them?
>> 
>> Not actually, when the scaling list is in the sequence(a flag for it), we
>> need to tell the decoder a scaling table.
> 
> Right, that's why the scaling list has a control of its own.
> 
>> But the initial state of that table is known, so for some decoder,
>> it would have a internal table.
> 
> That control is optional, so you can just ignore that setting in that
> case
> 
>> And for some decoder, it wants in the Z order while the others
>> won't.
> 
> We're designing a generic API here, so it doesn't matter. Some will
I know, I just wonder whether the other driver request it
> have to convert it internally in the drivers for the Z order, while
> others will be able to use it as is.
> 
>>>>> +struct v4l2_ctrl_h264_slice_param {
>>>>> +/* Size in bytes, including header */
>>>>> +__u32 size;
>>>>> +/* Offset in bits to slice_data() from the beginning of this slice. 
>>>>> */
>>>>> +__u32 header_bit_size;
>>>>> +
>>>>> +__u16 first_mb_in_slice;
>>>>> +__u8 slice_type;
>>>>> +__u8 pic_parameter_set_id;
>>>>> +__u8 colour_plane_id;
>>>>> +__u16 frame_num;
>>>>> +__u16 idr_pic_id;
>>>>> +__u16 pic_order_cnt_lsb;
>>>>> +__s32 delta_pic_order_cnt_bottom;
>>>>> +__s32 delta_pic_order_cnt0;
>>>>> +__s32 delta_pic_order_cnt1;
>>>>> +__u8 redundant_pic_cnt;
>>>>> +
>>>>> +struct v4l2_h264_pred_weight_table pred_weight_table;
>>>>> +/* Size in bits of dec_ref_pic_marking() syntax element. */
>>>>> +__u32 dec_ref_pic_marking_bit_size;
>>>>> +/* Size in bits of pic order count syntax. */
>>>>> +__u32 pic_order_cnt_bit_size;
>>>>> +
>>>>> +__u8 cabac_init_idc;
>>>>> +__s8 slice_qp_delta;
>>>>> +__s8 slice_qs_delta;
>>>>> +__u8 disable_deblocking_filter_idc;
>>>>> +__s8 slice_alpha_c0_offset_div2;
>>>>> +__s8 slice_beta_offset_div2;
>>>>> +__u32 slice_group_change_cycle;
>>>>> +
>>>>> +__u8 num_ref_idx_l0_active_minus1;
>>>>> +__u8 num_ref_idx_l1_active_minus1;
>>>>> +/*  Entries on each list are indices
>>>>> + *  into v4l2_ctrl_h264_decode_param.dpb[]. */
>>>>> +__u8 ref_pic_list0[32];
>>>>> +__u8 ref_pic_list1[32];
>>>>> +
>>>>> +__u8 flags;
>>>>> +};
>>>>> +
>>>> We need some addtional properties or the Rockchip won't work.
>>>> 1. u16 idr_pic_id for identifies IDR (instantaneous decoding refresh)
>>>> picture
>>> idr_pic_id is already there
>> Sorry for miss that.
>>> 
>>>> 2. u16 ref_pic_mk_len for length of decoded reference picture marking bits
>>>> 3. u8 poc_length for length of picture order count field in stream
>>>> 
>>>> The last two are used for the hardware to skip a part stream.
>>> I'm not sure what you mean here, those parameters are not in the
>>> bitstream, what do you want to use them for?
>> 
>> Or Rockchip's decoder won't work. Their decoder can't find the data part
>> without skip some segments in slice data.
>> 
>> I should say something more about the stateless decoder, it is hard to
>> define what a stateless decoder will do, some would like to parse more
>> information but some won't. You even have no idea on what it would
>> accelerate. OK, I should say for those ISO H serial codec, it would be more
>> simple but for those VPx serial, the decoders design is a mess.
> 
> Can't you use header_bit_size in that case to skip over the the parts
> of the slice you don't care about and go to the data?
> 
No, the decoder request extra size of those two segment of h.264 bitstream
>>>>> +#define V4L2_H264_DPB_ENTRY_FLAG

Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[Ayaka]

Sent from my iPad

> On Jan 24, 2019, at 6:27 PM, Paul Kocialkowski 
>  wrote:
> 
> Hi,
> 
>> On Thu, 2019-01-10 at 21:32 +0800, ayaka wrote:
>> I forget a important thing, for the rkvdec and rk hevc decoder, it would 
>> requests cabac table, scaling list, picture parameter set and reference 
>> picture storing in one or various of DMA buffers. I am not talking about 
>> the data been parsed, the decoder would requests a raw data.
>> 
>> For the pps and rps, it is possible to reuse the slice header, just let 
>> the decoder know the offset from the bitstream bufer, I would suggest to 
>> add three properties(with sps) for them. But I think we need a method to 
>> mark a OUTPUT side buffer for those aux data.
> 
> I'm quite confused about the hardware implementation then. From what
> you're saying, it seems that it takes the raw bitstream elements rather
> than parsed elements. Is it really a stateless implementation?
> 
> The stateless implementation was designed with the idea that only the
> raw slice data should be passed in bitstream form to the decoder. For
> H.264, it seems that some decoders also need the slice header in raw
> bitstream form (because they take the full slice NAL unit), see the
> discussions in this thread:
> media: docs-rst: Document m2m stateless video decoder interface

Stateless just mean it won’t track the previous result, but I don’t think you 
can define what a date the hardware would need. Even you just build a dpb for 
the decoder, it is still stateless, but parsing less or more data from the 
bitstream doesn’t stop a decoder become a stateless decoder.
> 
> Can you detail exactly what the rockchip decoder absolutely needs in
> raw bitstream format?
> 
> Cheers,
> 
> Paul
> 
>>> On 1/8/19 6:00 PM, Ayaka wrote:
>>> Sent from my iPad
>>> 
>>>> On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski 
>>>>  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>>> On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:
>>>>> 
>>>>> Sent from my iPad
>>>>> 
>>>>>> On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski 
>>>>>>  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>>>> On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
>>>>>>>> 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_BEFORE0x01
>>>>>>>>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER0x02
>>>>>>>>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
>>>>>>>>>> +
>>>>>>>>>> +#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX16
>>>>>>>>>> +
>>>>>>>>>> +struct v4l2_hevc_dpb_entry {
>>>>>>>>>> +__u32buffer_tag;
>>>>>>>>>> +__u8rps;
>>>>>>>>>> +__u8field_pic;
>>>>>>>>>> +__u16pic_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.
>>>>>> What exactly is that reference index? Is it a bitstream element or
>>>>>> something deduced from the bitstream?
>>>>>> 
>>>>> picture order count(POC) for HEVC and frame_num in AVC. I think it is
>>>>> the number used in list0(P slice and B slice) and list1(B slice).
>>>> The picture order count is already the last field of the DPB entry
>>>> structure. There is one for each field picture.
>>> As we are not sure whether there is a field coded slice or CTU, I would 
>>> hold this part and else about the field.
>>>>>>> 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 

Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[Ayaka]

Sent from my iPad

> On Jan 24, 2019, at 6:36 PM, Paul Kocialkowski 
>  wrote:
> 
> Hi,
> 
>> On Tue, 2019-01-08 at 18:00 +0800, Ayaka wrote:
>> 
>> Sent from my iPad
>> 
>>> On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>>> On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>> On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski 
>>>>>  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>>> On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
>>>>>>> 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_BEFORE0x01
>>>>>>>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER0x02
>>>>>>>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
>>>>>>>>> +
>>>>>>>>> +#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX16
>>>>>>>>> +
>>>>>>>>> +struct v4l2_hevc_dpb_entry {
>>>>>>>>> +__u32buffer_tag;
>>>>>>>>> +__u8rps;
>>>>>>>>> +__u8field_pic;
>>>>>>>>> +__u16pic_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.
>>>>> 
>>>>> What exactly is that reference index? Is it a bitstream element or
>>>>> something deduced from the bitstream?
>>>>> 
>>>> picture order count(POC) for HEVC and frame_num in AVC. I think it is
>>>> the number used in list0(P slice and B slice) and list1(B slice).
>>> 
>>> The picture order count is already the last field of the DPB entry
>>> structure. There is one for each field picture.
>> As we are not sure whether there is a field coded slice or CTU, I
>> would hold this part and else about the field.
> 
> I'm not sure what you meant here, sorry.
As we talked in IRC, I am not sure the field coded picture is supported in HEVC.
And I don’t why there would be two pic order cnt, a picture can only be used a 
short term or  a long term reference at one picture decoding
> 
>>>>>> 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.
>>>>> 
>>>>> The motion vectors are passed as part of the raw bitstream data, in the
>>>>> slices. Is there a case where the motion vectors are coded differently?
>>>> No, it is an additional cache for decoder, even FFmpeg having such
>>>> data, I think allwinner must output it into somewhere.
>>> 
>>> Ah yes I see what you mean! This is handled internally by our driver
>>> and not exposed to userspace. I don't think it would be a good idea to
>>> expose this cache or request that userspace allocates it like a video
>>> buffer.
>>> 
>> No, usually the driver should allocate, as the user space have no
>> idea on size of each devices.
>> But for advantage user, application can fix a broken picture with a
>> proper data or analysis a object motion from that.
>> So I would suggest attaching this information to a picture buffer as
>> a meta data. 
> 
> Right, the driver will allocate chunks of memory for the decoding
> metadata used by the hardware decoder.
> 
> Well, I don't think V4L2 has any mechanism to expose this data for now
> and since it's very specific to the hardware implementation, I guess
> the interest in having that is generally pretty low.
> 
> That's maybe something that could be added later if someone wants to
> work on it, but I think we are better off keeping this metadata hidden
> by 

Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls.

[ayaka]

I am sorry I am a little busy for the lunar new year recently and the 
H.264 syntax rules are little complex, I will try explain my ideas more 
clear here.


On 1/17/19 7:01 PM, Maxime Ripard wrote:

Hi,

On Tue, Jan 08, 2019 at 05:52:28PM +0800, Randy 'ayaka' Li wrote:

+struct v4l2_ctrl_h264_scaling_matrix {
+   __u8 scaling_list_4x4[6][16];
+   __u8 scaling_list_8x8[6][64];
+};

I wonder which decoder want this.

I'm not sure I follow you, scaling lists are an important part of the
decoding process, so all of them?
Not actually, when the scaling list is in the sequence(a flag for it), 
we need to tell the decoder a scaling table. But the initial state of 
that table is known, so for some decoder, it would have a internal 
table. And for some decoder, it wants in the Z order while the others won't.



+struct v4l2_ctrl_h264_slice_param {
+   /* Size in bytes, including header */
+   __u32 size;
+   /* Offset in bits to slice_data() from the beginning of this slice. */
+   __u32 header_bit_size;
+
+   __u16 first_mb_in_slice;
+   __u8 slice_type;
+   __u8 pic_parameter_set_id;
+   __u8 colour_plane_id;
+   __u16 frame_num;
+   __u16 idr_pic_id;
+   __u16 pic_order_cnt_lsb;
+   __s32 delta_pic_order_cnt_bottom;
+   __s32 delta_pic_order_cnt0;
+   __s32 delta_pic_order_cnt1;
+   __u8 redundant_pic_cnt;
+
+   struct v4l2_h264_pred_weight_table pred_weight_table;
+   /* Size in bits of dec_ref_pic_marking() syntax element. */
+   __u32 dec_ref_pic_marking_bit_size;
+   /* Size in bits of pic order count syntax. */
+   __u32 pic_order_cnt_bit_size;
+
+   __u8 cabac_init_idc;
+   __s8 slice_qp_delta;
+   __s8 slice_qs_delta;
+   __u8 disable_deblocking_filter_idc;
+   __s8 slice_alpha_c0_offset_div2;
+   __s8 slice_beta_offset_div2;
+   __u32 slice_group_change_cycle;
+
+   __u8 num_ref_idx_l0_active_minus1;
+   __u8 num_ref_idx_l1_active_minus1;
+   /*  Entries on each list are indices
+*  into v4l2_ctrl_h264_decode_param.dpb[]. */
+   __u8 ref_pic_list0[32];
+   __u8 ref_pic_list1[32];
+
+   __u8 flags;
+};
+

We need some addtional properties or the Rockchip won't work.
1. u16 idr_pic_id for identifies IDR (instantaneous decoding refresh)
picture

idr_pic_id is already there

Sorry for miss that.



2. u16 ref_pic_mk_len for length of decoded reference picture marking bits
3. u8 poc_length for length of picture order count field in stream

The last two are used for the hardware to skip a part stream.

I'm not sure what you mean here, those parameters are not in the
bitstream, what do you want to use them for?


Or Rockchip's decoder won't work. Their decoder can't find the data part 
without skip some segments in slice data.


I should say something more about the stateless decoder, it is hard to 
define what a stateless decoder will do, some would like to parse more 
information but some won't. You even have no idea on what it would 
accelerate. OK, I should say for those ISO H serial codec, it would be 
more simple but for those VPx serial, the decoders design is a mess.



+#define V4L2_H264_DPB_ENTRY_FLAG_VALID 0x01
+#define V4L2_H264_DPB_ENTRY_FLAG_ACTIVE0x02
+#define V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM 0x04
+
+struct v4l2_h264_dpb_entry {
+   __u32 tag;
+   __u16 frame_num;
+   __u16 pic_num;

Although the long term reference would use picture order count
and short term for frame num, but only one of them is used
for a entry of a dpb.

Besides, for a frame picture frame_num = pic_num * 2,
and frame_num = pic_num * 2 + 1 for a filed.

I'm not sure what is your point?


I found I was wrong at the last email.


But stateless hardware decoder usually don't care about whether it is long
term or short term, as the real dpb updating or management work are not done
by the the driver or device and decoding job would only use the two list(or
one list for slice P) for reference pictures. So those flag for long term or
status can be removed as well.
And I agree above with my last mail, so I would suggest to keep a 
property as index for both frame_num and pic_num, as only one of them 
would be used for a picture decoding once time.





+   /* Note that field is indicated by v4l2_buffer.field */
+   __s32 top_field_order_cnt;
+   __s32 bottom_field_order_cnt;
+   __u8 flags; /* V4L2_H264_DPB_ENTRY_FLAG_* */
+};
+
+struct v4l2_ctrl_h264_decode_param {
+   __u32 num_slices;
+   __u8 idr_pic_flag;
+   __u8 nal_ref_idc;
+   __s32 top_field_order_cnt;
+   __s32 bottom_field_order_cnt;
+   __u8 ref_pic_list_p0[32];
+   __u8 ref_pic_list_b0[32];
+   __u8 ref_pic_list_b1[32];

I would prefer to keep only two list, list0 and list 1.

I'm not even sure why this is needed in the first place anymore. It's
not part of the bitstream, and it seems to come from ChromeOS' Rockchip driver 
that uses

Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls.

[ayaka]

I forget a important thing, for the rkvdec and rk hevc decoder, it would 
requests cabac table, scaling list, picture parameter set and reference 
picture storing in one or various of DMA buffers. I am not talking about 
the data been parsed, the decoder would requests a raw data.


For the pps and rps, it is possible to reuse the slice header, just let 
the decoder know the offset from the bitstream bufer, I would suggest to 
add three properties(with sps) for them. But I think we need a method to 
mark a OUTPUT side buffer for those aux data.


On 1/9/19 1:01 AM, ayaka wrote:


On 1/8/19 5:52 PM, Randy 'ayaka' Li wrote:

On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:

From: Pawel Osciak 

Stateless video codecs will require both the H264 metadata and 
slices in

order to be able to decode frames.

This introduces the definitions for a new pixel format for H264 
slices that
have been parsed, as well as the structures used to pass the 
metadata from

the userspace to the kernel.

Co-Developed-by: Maxime Ripard 
Signed-off-by: Pawel Osciak 
Signed-off-by: Guenter Roeck 
Signed-off-by: Maxime Ripard 
---
  Documentation/media/uapi/v4l/biblio.rst   |   9 +
  .../media/uapi/v4l/extended-controls.rst  | 364 
++

  .../media/uapi/v4l/pixfmt-compressed.rst  |  20 +
  .../media/uapi/v4l/vidioc-queryctrl.rst   |  30 ++
  .../media/videodev2.h.rst.exceptions  |   5 +
  drivers/media/v4l2-core/v4l2-ctrls.c  |  42 ++
  drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
  include/media/v4l2-ctrls.h    |  10 +
  include/uapi/linux/v4l2-controls.h    | 166 
  include/uapi/linux/videodev2.h    |  11 +
  10 files changed, 658 insertions(+)
+#define V4L2_H264_DPB_ENTRY_FLAG_VALID    0x01
+#define V4L2_H264_DPB_ENTRY_FLAG_ACTIVE    0x02
+#define V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM    0x04
+
+struct v4l2_h264_dpb_entry {
+    __u32 tag;
+    __u16 frame_num;
+    __u16 pic_num;

Although the long term reference would use picture order count
and short term for frame num, but only one of them is used
for a entry of a dpb.

Besides, for a frame picture frame_num = pic_num * 2,
and frame_num = pic_num * 2 + 1 for a filed.


I mistook something before and something Herman told me is wrong, I 
read the book explaining the ITU standard.


The index of a short term reference picture would be frame_num or POC 
and LongTermPicNum for long term.


But stateless hardware decoder usually don't care about whether it is 
long term or short term, as the real dpb updating or management work 
are not done by the the driver or device and decoding job would only 
use the two list(or one list for slice P) for reference pictures. So 
those flag for long term or status can be removed as well.


Stateless decoder would care about just reference index of this 
picture and maybe some extra property for the filed coded below. 
Keeping a property here for the index of a picture is enough.



+    /* Note that field is indicated by v4l2_buffer.field */
+    __s32 top_field_order_cnt;
+    __s32 bottom_field_order_cnt;
+    __u8 flags; /* V4L2_H264_DPB_ENTRY_FLAG_* */
+};
+
+struct v4l2_ctrl_h264_decode_param {
+    __u32 num_slices;
+    __u8 idr_pic_flag;
+    __u8 nal_ref_idc;
+    __s32 top_field_order_cnt;
+    __s32 bottom_field_order_cnt;
+    __u8 ref_pic_list_p0[32];
+    __u8 ref_pic_list_b0[32];
+    __u8 ref_pic_list_b1[32];

I would prefer to keep only two list, list0 and list 1.
Anyway P slice just use the list0 and B would use the both.

+    struct v4l2_h264_dpb_entry dpb[16];
+};
+
  #endif
diff --git a/include/uapi/linux/videodev2.h 
b/include/uapi/linux/videodev2.h

index 173a94d2cbef..dd028e0bf306 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -643,6 +643,7 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* 
H264 with start codes */
  #define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* 
H264 without start codes */
  #define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* 
H264 MVC */
+#define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* 
H264 parsed slices */
  #define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* 
H263  */
  #define V4L2_PIX_FMT_MPEG1    v4l2_fourcc('M', 'P', 'G', '1') /* 
MPEG-1 ES */
  #define V4L2_PIX_FMT_MPEG2    v4l2_fourcc('M', 'P', 'G', '2') /* 
MPEG-2 ES */

@@ -1631,6 +1632,11 @@ struct v4l2_ext_control {
  __u32 __user *p_u32;
  struct v4l2_ctrl_mpeg2_slice_params __user 
*p_mpeg2_slice_params;
  struct v4l2_ctrl_mpeg2_quantization __user 
*p_mpeg2_quantization;

+    struct v4l2_ctrl_h264_sps __user *p_h264_sps;
+    struct v4l2_ctrl_h264_pps __user *p_h264_pps;
+    struct v4l2_ctrl_h264_scaling_matrix __user *p_h264_scal_mtrx;
+    struct v4l2_ctrl_h264_slice_param __user *p_h264_slice_param

Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[ayaka]

I forget a important thing, for the rkvdec and rk hevc decoder, it would 
requests cabac table, scaling list, picture parameter set and reference 
picture storing in one or various of DMA buffers. I am not talking about 
the data been parsed, the decoder would requests a raw data.


For the pps and rps, it is possible to reuse the slice header, just let 
the decoder know the offset from the bitstream bufer, I would suggest to 
add three properties(with sps) for them. But I think we need a method to 
mark a OUTPUT side buffer for those aux data.


On 1/8/19 6:00 PM, Ayaka wrote:


Sent from my iPad


On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski  
wrote:

Hi,


On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:

Sent from my iPad


On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski  
wrote:

Hi,


On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
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_BEFORE0x01
+#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER0x02
+#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
+
+#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX16
+
+struct v4l2_hevc_dpb_entry {
+__u32buffer_tag;
+__u8rps;
+__u8field_pic;
+__u16pic_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.

What exactly is that reference index? Is it a bitstream element or
something deduced from the bitstream?


picture order count(POC) for HEVC and frame_num in AVC. I think it is
the number used in list0(P slice and B slice) and list1(B slice).

The picture order count is already the last field of the DPB entry
structure. There is one for each field picture.

As we are not sure whether there is a field coded slice or CTU, I would hold 
this part and else about the field.

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.

The motion vectors are passed as part of the raw bitstream data, in the
slices. Is there a case where the motion vectors are coded differently?

No, it is an additional cache for decoder, even FFmpeg having such
data, I think allwinner must output it into somewhere.

Ah yes I see what you mean! This is handled internally by our driver
and not exposed to userspace. I don't think it would be a good idea to
expose this cache or request that userspace allocates it like a video
buffer.


No, usually the driver should allocate, as the user space have no idea on size 
of each devices.
But for advantage user, application can fix a broken picture with a proper data 
or analysis a object motion from that.
So I would suggest attaching this information to a picture buffer as a meta 
data.

+
+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.

Yes, it's possible that some of the elements are not necessary for some
decoders. What we want is to cover all the elements that might be
required for a decoder.

I wonder whether allwinner need that, those sao flag usually ignored
by decoder in design. But more is better than less, it is hard to
extend a v4l2 structure  in the future, maybe a new HEVC profile
would bring a new property, it is still too early for HEVC.

Yes this is used by our decoder. The idea is to have all the basic
bitstream elements in the structures (even if some decoders don't use
them all) and add others for extension as separate controls later.


+struct v4l2_ctrl_hevc_slice_params {
+__u32bit_size;
+__u32data_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;



+__u16slice_pic_order_cnt;
+__u8slice_sao_luma_flag

Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls.

[ayaka]

On 1/8/19 5:52 PM, Randy 'ayaka' Li wrote:

On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:

From: Pawel Osciak 

Stateless video codecs will require both the H264 metadata and slices in
order to be able to decode frames.

This introduces the definitions for a new pixel format for H264 slices that
have been parsed, as well as the structures used to pass the metadata from
the userspace to the kernel.

Co-Developed-by: Maxime Ripard 
Signed-off-by: Pawel Osciak 
Signed-off-by: Guenter Roeck 
Signed-off-by: Maxime Ripard 
---
  Documentation/media/uapi/v4l/biblio.rst   |   9 +
  .../media/uapi/v4l/extended-controls.rst  | 364 ++
  .../media/uapi/v4l/pixfmt-compressed.rst  |  20 +
  .../media/uapi/v4l/vidioc-queryctrl.rst   |  30 ++
  .../media/videodev2.h.rst.exceptions  |   5 +
  drivers/media/v4l2-core/v4l2-ctrls.c  |  42 ++
  drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
  include/media/v4l2-ctrls.h|  10 +
  include/uapi/linux/v4l2-controls.h| 166 
  include/uapi/linux/videodev2.h|  11 +
  10 files changed, 658 insertions(+)
+#define V4L2_H264_DPB_ENTRY_FLAG_VALID 0x01
+#define V4L2_H264_DPB_ENTRY_FLAG_ACTIVE0x02
+#define V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM 0x04
+
+struct v4l2_h264_dpb_entry {
+   __u32 tag;
+   __u16 frame_num;
+   __u16 pic_num;

Although the long term reference would use picture order count
and short term for frame num, but only one of them is used
for a entry of a dpb.

Besides, for a frame picture frame_num = pic_num * 2,
and frame_num = pic_num * 2 + 1 for a filed.


I mistook something before and something Herman told me is wrong, I read 
the book explaining the ITU standard.


The index of a short term reference picture would be frame_num or POC 
and LongTermPicNum for long term.


But stateless hardware decoder usually don't care about whether it is 
long term or short term, as the real dpb updating or management work are 
not done by the the driver or device and decoding job would only use the 
two list(or one list for slice P) for reference pictures. So those flag 
for long term or status can be removed as well.


Stateless decoder would care about just reference index of this picture 
and maybe some extra property for the filed coded below. Keeping a 
property here for the index of a picture is enough.



+   /* Note that field is indicated by v4l2_buffer.field */
+   __s32 top_field_order_cnt;
+   __s32 bottom_field_order_cnt;
+   __u8 flags; /* V4L2_H264_DPB_ENTRY_FLAG_* */
+};
+
+struct v4l2_ctrl_h264_decode_param {
+   __u32 num_slices;
+   __u8 idr_pic_flag;
+   __u8 nal_ref_idc;
+   __s32 top_field_order_cnt;
+   __s32 bottom_field_order_cnt;
+   __u8 ref_pic_list_p0[32];
+   __u8 ref_pic_list_b0[32];
+   __u8 ref_pic_list_b1[32];

I would prefer to keep only two list, list0 and list 1.
Anyway P slice just use the list0 and B would use the both.

+   struct v4l2_h264_dpb_entry dpb[16];
+};
+
  #endif
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 173a94d2cbef..dd028e0bf306 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -643,6 +643,7 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with 
start codes */
  #define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264 
without start codes */
  #define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 MVC */
+#define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H264 parsed 
slices */
  #define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263 
 */
  #define V4L2_PIX_FMT_MPEG1v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1 ES
 */
  #define V4L2_PIX_FMT_MPEG2v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2 ES
 */
@@ -1631,6 +1632,11 @@ struct v4l2_ext_control {
__u32 __user *p_u32;
struct v4l2_ctrl_mpeg2_slice_params __user 
*p_mpeg2_slice_params;
struct v4l2_ctrl_mpeg2_quantization __user 
*p_mpeg2_quantization;
+   struct v4l2_ctrl_h264_sps __user *p_h264_sps;
+   struct v4l2_ctrl_h264_pps __user *p_h264_pps;
+   struct v4l2_ctrl_h264_scaling_matrix __user *p_h264_scal_mtrx;
+   struct v4l2_ctrl_h264_slice_param __user *p_h264_slice_param;
+   struct v4l2_ctrl_h264_decode_param __user *p_h264_decode_param;
void __user *ptr;
};
  } __attribute__ ((packed));
@@ -1678,6 +1684,11 @@ enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_U32   = 0x0102,
V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS = 0x0103,
V4L2_CTRL_TYPE_MPEG2_QUANTIZATION = 0x0104,
+   V4L2_CTRL_TYPE_H264_SPS  = 0x0105,
+   V4L2_CTRL_TYPE_H264_PPS  = 0x0106,
+   V4L2_CTRL_TYPE_H264_SCALING_MATRIX = 0x0107

Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[Ayaka]

Sent from my iPad

> On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski  
> wrote:
> 
> Hi,
> 
>> On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:
>> 
>> Sent from my iPad
>> 
>>> On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>>>> On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
>>>>> 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_BEFORE0x01
>>>>>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER0x02
>>>>>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
>>>>>>> +
>>>>>>> +#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX16
>>>>>>> +
>>>>>>> +struct v4l2_hevc_dpb_entry {
>>>>>>> +__u32buffer_tag;
>>>>>>> +__u8rps;
>>>>>>> +__u8field_pic;
>>>>>>> +__u16pic_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.
>>> 
>>> What exactly is that reference index? Is it a bitstream element or
>>> something deduced from the bitstream?
>>> 
>> picture order count(POC) for HEVC and frame_num in AVC. I think it is
>> the number used in list0(P slice and B slice) and list1(B slice).
> 
> The picture order count is already the last field of the DPB entry
> structure. There is one for each field picture.
As we are not sure whether there is a field coded slice or CTU, I would hold 
this part and else about the field.
> 
>>>> 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.
>>> 
>>> The motion vectors are passed as part of the raw bitstream data, in the
>>> slices. Is there a case where the motion vectors are coded differently?
>> No, it is an additional cache for decoder, even FFmpeg having such
>> data, I think allwinner must output it into somewhere.
> 
> Ah yes I see what you mean! This is handled internally by our driver
> and not exposed to userspace. I don't think it would be a good idea to
> expose this cache or request that userspace allocates it like a video
> buffer.
> 
No, usually the driver should allocate, as the user space have no idea on size 
of each devices.
But for advantage user, application can fix a broken picture with a proper data 
or analysis a object motion from that.
So I would suggest attaching this information to a picture buffer as a meta 
data. 
>>>>>>> +
>>>>>>> +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.
>>> 
>>> Yes, it's possible that some of the elements are not necessary for some
>>> decoders. What we want is to cover all the elements that might be
>>> required for a decoder.
>> I wonder whether allwinner

Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls.

[Randy 'ayaka' Li]

On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:
> From: Pawel Osciak 
> 
> Stateless video codecs will require both the H264 metadata and slices in
> order to be able to decode frames.
> 
> This introduces the definitions for a new pixel format for H264 slices that
> have been parsed, as well as the structures used to pass the metadata from
> the userspace to the kernel.
> 
> Co-Developed-by: Maxime Ripard 
> Signed-off-by: Pawel Osciak 
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/media/uapi/v4l/biblio.rst   |   9 +
>  .../media/uapi/v4l/extended-controls.rst  | 364 ++
>  .../media/uapi/v4l/pixfmt-compressed.rst  |  20 +
>  .../media/uapi/v4l/vidioc-queryctrl.rst   |  30 ++
>  .../media/videodev2.h.rst.exceptions  |   5 +
>  drivers/media/v4l2-core/v4l2-ctrls.c  |  42 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
>  include/media/v4l2-ctrls.h|  10 +
>  include/uapi/linux/v4l2-controls.h| 166 
>  include/uapi/linux/videodev2.h|  11 +
>  10 files changed, 658 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/biblio.rst 
> b/Documentation/media/uapi/v4l/biblio.rst
> index 386d6cf83e9c..73aeb7ce47d2 100644
> --- a/Documentation/media/uapi/v4l/biblio.rst
> +++ b/Documentation/media/uapi/v4l/biblio.rst
> @@ -115,6 +115,15 @@ ITU BT.1119
>  
>  :author:International Telecommunication Union (http://www.itu.ch)
>  
> +.. _h264:
> +
> +ITU H.264
> +=
> +
> +:title: ITU-T Recommendation H.264 "Advanced Video Coding for Generic 
> Audiovisual Services"
> +
> +:author:International Telecommunication Union (http://www.itu.ch)
> +
>  .. _jfif:
>  
>  JFIF
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> b/Documentation/media/uapi/v4l/extended-controls.rst
> index 65a1d873196b..87c0d151577f 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -1674,6 +1674,370 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>   non-intra-coded frames, in zigzag scanning order. Only relevant for
>   non-4:2:0 YUV formats.
>  
> +.. _v4l2-mpeg-h264:
> +
> +``V4L2_CID_MPEG_VIDEO_H264_SPS (struct)``
> +Specifies the sequence parameter set (as extracted from the
> +bitstream) for the associated H264 slice data. This includes the
> +necessary parameters for configuring a stateless hardware decoding
> +pipeline for H264.  The bitstream parameters are defined according
> +to :ref:`h264`. Unless there's a specific comment, refer to the
> +specification for the documentation of these fields.
> +
> +.. c:type:: v4l2_ctrl_h264_sps
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_ctrl_h264_sps
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - __u8
> +  - ``profile_idc``
> +  -
> +* - __u8
> +  - ``constraint_set_flags``
> +  - TODO
> +* - __u8
> +  - ``level_idc``
> +  -
> +* - __u8
> +  - ``seq_parameter_set_id``
> +  -
> +* - __u8
> +  - ``chroma_format_idc``
> +  -
> +* - __u8
> +  - ``bit_depth_luma_minus8``
> +  -
> +* - __u8
> +  - ``bit_depth_chroma_minus8``
> +  -
> +* - __u8
> +  - ``log2_max_frame_num_minus4``
> +  -
> +* - __u8
> +  - ``pic_order_cnt_type``
> +  -
> +* - __u8
> +  - ``log2_max_pic_order_cnt_lsb_minus4``
> +  -
> +* - __u8
> +  - ``max_num_ref_frames``
> +  -
> +* - __u8
> +  - ``num_ref_frames_in_pic_order_cnt_cycle``
> +  -
> +* - __s32
> +  - ``offset_for_ref_frame[255]``
> +  -
> +* - __s32
> +  - ``offset_for_non_ref_pic``
> +  -
> +* - __s32
> +  - ``offset_for_top_to_bottom_field``
> +  -
> +* - __u16
> +  - ``pic_width_in_mbs_minus1``
> +  -
> +* - __u16
> +  - ``pic_height_in_map_units_minus1``
> +  -
> +* - __u8
> +  - ``flags``
> +  - TODO
> +
> +``V4L2_CID_MPEG_VIDEO_H264_PPS (struct)``
> +Specifies the picture parameter set (as extracted from the
> +bitstream) for the associated H264 slice data. This includes the
> +necessary parameters for configuring a stateless hardware decoding
> +pipeline for H264.  The bitstream parameters are defined according
> +to :ref:`h264`. Unless there's a specific comment, refer to the
> +specification for the documentation of these fields.
> +
> +.. c:type:: v4l2_ctrl_h264_pps
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_ctrl_h264_pps
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - __u8
> +  - ``pic_parameter_set_id``
> +  -
> +* - __u8
> +  - ``seq_parameter_set_id``
> +  -
> +* - __u8
> +  - ``num_slice_groups_minus1``
> +  -
> +* - __u8
> +  - 

Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399

[Ayaka]

Sent from my iPad

> On Jan 8, 2019, at 2:33 PM, Tomasz Figa  wrote:
> 
>> On Mon, Jan 7, 2019 at 2:30 AM Ayaka  wrote:
>> 
>> Hello Ezequiel
>> 
>> Sent from my iPad
>> 
>>>> On Jan 7, 2019, at 1:21 AM, Ezequiel Garcia 
>>>>  wrote:
>>>> 
>>>> On Sun, 6 Jan 2019 at 13:16, Ayaka  wrote:
>>>> 
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>> On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia  
>>>>> wrote:
>>>>> 
>>>>> On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote:
>>>>>>> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi Randy,
>>>>>>> 
>>>>>>> Thanks a lot for this patches. They are really useful
>>>>>>> to provide more insight into the VPU hardware.
>>>>>>> 
>>>>>>> This change will make the vpu encoder and vpu decoder
>>>>>>> completely independent, can they really work in parallel?
>>>>>> As I said it depends on the platform, but with this patch, the user 
>>>>>> space would think they can work at the same time.
>>>>> 
>>>>> 
>>>>> I think there is some confusion.
>>>>> 
>>>>> The devicetree is one thing: it is a hardware representation,
>>>>> a way to describe the hardware, for the kernel/bootloader to
>>>>> parse.
>>>>> 
>>>>> The userspace view will depend on the driver implementation.
>>>>> 
>>>>> The current devicetree and driver (without your patches),
>>>>> model the VPU as a single piece of hardware, exposing a decoder
>>>>> and an encoder.
>>>>> 
>>>>> The V4L driver will then create two video devices, i.e. /dev/videoX
>>>>> and /dev/videoY. So userspace sees an independent view of the
>>>>> devices.
>>>>> 
>>>> I knew that, the problem is that the driver should not always create a 
>>>> decoder and encoder pair, they may not exist at some platforms, even some 
>>>> platforms doesn’t have a encoder. You may have a look on the rk3328 I post 
>>>> on the first email as example.
>>> 
>>> That is correct. But that still doesn't tackle my question: is the
>>> hardware able to run a decoding and an encoding job in parallel?
>>> 
>> For rk3328, yes, you see I didn’t draw them in the same box.
>>> If not, then it's wrong to describe them as independent entities.
>>> 
>>>>> However, they are internally connected, and thus we can
>>>>> easily avoid two jobs running in parallel.
>>>>> 
>>>> That is what the mpp service did in my patches, handing the relationship 
>>>> between each devices. And it is not a easy work, maybe a 4k decoder would 
>>>> be blocked by another high frame rate encoding work or another decoder 
>>>> session. The vendor kernel have more worry about this,  but not in this 
>>>> version.
>>> 
>>> Right. That is one way to design it. Another way is having a single
>>> devicetree node for the VPU encoder/decoder "complex".
>> No, you can’t assume which one is in the combo group, it can be various. you 
>> see, in the rk3328, the vdpu is paired with an avs+ decoder. That is why I 
>> use a virtual device standing for scheduler.
> 
> First of all, thanks for all the input. Having more understanding of
> the hardware and shortcomings of the current V4L2 APIs is really
> important to let us further evolve the API and make sure that it works
> for further use cases.
I replied the problems of the v4l2 request API in the other threads. I am 
waiting the feedback from those threads.
> 
> As for the Device Tree itself, it doesn't always describe the hardware
> in 100%.
Also please note the merged device tree for the video codec won’t fix for most 
of the rockchip platform.
> Most of the time it's just the necessary information to
> choose and instantiate the right drivers and bind to the right
> hardware resources. The information on which hardware instances on the
> SoC can work independently can of course be described in DT (e.g. by
> sub-nodes of a video-codec complex OR a set of phandles, e.g.
> rockchip,shared-instances), but it's also perfectly fine to defer this
> kind of knowledge to the drivers themselves.
I wish there is a common mechanism for those device would share some resources. 
Although there is a multiple functions framework,  but that is not I want. They 
are multiple functions but they are used at the same time not separately.
> 
> Best regards,
> Tomasz

Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[Ayaka]

;
>>>>> +__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.
> 
> The purpose of this field is to indicate whether the current picture is
> a progressive frame or an interlaced field picture, which is useful for
> decoding.
> 
> At least our decoder has a register field to indicate frame/top
> field/bottom field, so we certainly need to keep the info around.
> Looking at the spec and the ffmpeg implementation, it looks like this
> flag of the bitstream is the usual way to report field coding.
It depends whether the decoder cares about scan type or more, I wonder prefer 
general_interlaced_source_flag for just scan type, it would be better than 
reading another SEL.
> 
> Cheers,
> 
> Paul
Randy “ayaka” LI
> 
>>>>> +
>>>>> +/* 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
> -- 
> Paul Kocialkowski, Bootlin (formerly Free Electrons)
> Embedded Linux and kernel engineering
> https://bootlin.com
> 

Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399

[Ayaka]

Hello Ezequiel

Sent from my iPad

> On Jan 7, 2019, at 1:21 AM, Ezequiel Garcia  
> wrote:
> 
>> On Sun, 6 Jan 2019 at 13:16, Ayaka  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia  wrote:
>>> 
>>> On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote:
>>>>> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia  
>>>>> wrote:
>>>>> 
>>>>> Hi Randy,
>>>>> 
>>>>> Thanks a lot for this patches. They are really useful
>>>>> to provide more insight into the VPU hardware.
>>>>> 
>>>>> This change will make the vpu encoder and vpu decoder
>>>>> completely independent, can they really work in parallel?
>>>> As I said it depends on the platform, but with this patch, the user space 
>>>> would think they can work at the same time.
>>> 
>>> 
>>> I think there is some confusion.
>>> 
>>> The devicetree is one thing: it is a hardware representation,
>>> a way to describe the hardware, for the kernel/bootloader to
>>> parse.
>>> 
>>> The userspace view will depend on the driver implementation.
>>> 
>>> The current devicetree and driver (without your patches),
>>> model the VPU as a single piece of hardware, exposing a decoder
>>> and an encoder.
>>> 
>>> The V4L driver will then create two video devices, i.e. /dev/videoX
>>> and /dev/videoY. So userspace sees an independent view of the
>>> devices.
>>> 
>> I knew that, the problem is that the driver should not always create a 
>> decoder and encoder pair, they may not exist at some platforms, even some 
>> platforms doesn’t have a encoder. You may have a look on the rk3328 I post 
>> on the first email as example.
> 
> That is correct. But that still doesn't tackle my question: is the
> hardware able to run a decoding and an encoding job in parallel?
> 
For rk3328, yes, you see I didn’t draw them in the same box.
> If not, then it's wrong to describe them as independent entities.
> 
>>> However, they are internally connected, and thus we can
>>> easily avoid two jobs running in parallel.
>>> 
>> That is what the mpp service did in my patches, handing the relationship 
>> between each devices. And it is not a easy work, maybe a 4k decoder would be 
>> blocked by another high frame rate encoding work or another decoder session. 
>> The vendor kernel have more worry about this,  but not in this version.
> 
> Right. That is one way to design it. Another way is having a single
> devicetree node for the VPU encoder/decoder "complex".
No, you can’t assume which one is in the combo group, it can be various. you 
see, in the rk3328, the vdpu is paired with an avs+ decoder. That is why I use 
a virtual device standing for scheduler.
> 
> Thanks for the input!
> -- 
> Ezequiel García, VanguardiaSur
> www.vanguardiasur.com.ar

Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399

[Ayaka]

Sent from my iPad

> On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia  wrote:
> 
> On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote:
>>> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia  wrote:
>>> 
>>> Hi Randy,
>>> 
>>> Thanks a lot for this patches. They are really useful
>>> to provide more insight into the VPU hardware.
>>> 
>>> This change will make the vpu encoder and vpu decoder
>>> completely independent, can they really work in parallel?
>> As I said it depends on the platform, but with this patch, the user space 
>> would think they can work at the same time.
> 
> 
> I think there is some confusion.
> 
> The devicetree is one thing: it is a hardware representation,
> a way to describe the hardware, for the kernel/bootloader to
> parse.
> 
> The userspace view will depend on the driver implementation.
> 
> The current devicetree and driver (without your patches),
> model the VPU as a single piece of hardware, exposing a decoder
> and an encoder.
> 
> The V4L driver will then create two video devices, i.e. /dev/videoX
> and /dev/videoY. So userspace sees an independent view of the
> devices.
> 
I knew that, the problem is that the driver should not always create a decoder 
and encoder pair, they may not exist at some platforms, even some platforms 
doesn’t have a encoder. You may have a look on the rk3328 I post on the first 
email as example.
> However, they are internally connected, and thus we can
> easily avoid two jobs running in parallel.
> 
That is what the mpp service did in my patches, handing the relationship 
between each devices. And it is not a easy work, maybe a 4k decoder would be 
blocked by another high frame rate encoding work or another decoder session. 
The vendor kernel have more worry about this,  but not in this version.
> So, in other words, if the VPU can issue a decoder and encoder
> job in parallel, then it's useful to model it as two independent
> devices. Otherwise, it's better not to.
> 
> I hope this can clarify things a bit for you!
> 
I would review the request API for those codecs structures and some basic 
designs, people from LibreELEC told me a few noticed inform.
> PS: Too bad I won't be at FOSDEM to discuss this personally.
I am sure Paulk from bootlin would be there and some others guy related, I have 
not cared about this for a little long time, there are more huge problem I 
should point out now.
> 
> Thanks,
> Ezequiel
> 
>> BTW, not only the decoder, there is a post processor with the decoder, it 
>> can be used as part of the decoder pipeline with only a macro block delay
>> or process the data from an external buffer.
>> I forget to write a note on what this driver doesn’t present. The real one 
>> would have much complex scheduler system, but this one is just a queue.
>> More task management feature are not there.
>> Also the clock boosting is removing and the loading analysis, which are 
>> useful for encoder, especially on the rv1108.
>>> Could you provide more details about what is
>>> shared between these devices?
>> No, if Rockchip doesn’t tell, my mouth is sealed.
>>> Thanks a lot!
>>> 
>>>> On Sun, 2019-01-06 at 02:31 +0800, Randy Li wrote:
>>>> 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";
>>>> +};
>>>> 

Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399

[Ayaka]

> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia  wrote:
> 
> Hi Randy,
> 
> Thanks a lot for this patches. They are really useful
> to provide more insight into the VPU hardware.
> 
> This change will make the vpu encoder and vpu decoder
> completely independent, can they really work in parallel?
As I said it depends on the platform, but with this patch, the user space would 
think they can work at the same time. BTW, not only the decoder, there is a 
post processor with the decoder, it can be used as part of the decoder pipeline 
with only a macro block delay or process the data from an external buffer.
I forget to write a note on what this driver doesn’t present. The real one 
would have much complex scheduler system, but this one is just a queue. More 
task management feature are not there.
Also the clock boosting is removing and the loading analysis, which are useful 
for encoder, especially on the rv1108.
> Could you provide more details about what is
> shared between these devices?
No, if Rockchip doesn’t tell, my mouth is sealed.
> Thanks a lot!
> 
>> On Sun, 2019-01-06 at 02:31 +0800, Randy Li wrote:
>> 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>, < 

Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399

[Ayaka]

> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia  wrote:
> 
> Hi Randy,
> 
> Thanks a lot for this patches. They are really useful
> to provide more insight into the VPU hardware.
> 
> This change will make the vpu encoder and vpu decoder
> completely independent, can they really work in parallel?
As I said it depends on the platform, but with this patch, the user space would 
think they can work at the same time. BTW, not only the decoder, there is a 
post processor with the decoder, it can be used as part of the decoder pipeline 
with only a macro block delay or process the data from an external buffer.
I forget to write a note on what this driver doesn’t present. The real one 
would have much complex scheduler system, but this one is just a queue. More 
task management feature are not there.
Also the clock boosting is removing and the loading analysis, which are useful 
for encoder, especially on the rv1108.
> Could you provide more details about what is
> shared between these devices?
No, if Rockchip doesn’t tell, my mouth is sealed.
> Thanks a lot!
> 
>> On Sun, 2019-01-06 at 02:31 +0800, Randy Li wrote:
>> 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 = 

Re: [PATCH] ARM: dts: rockchip: add missing grf phandle for rk3288

[ayaka]

On 05/14/2017 10:59 PM, Heiko Stuebner wrote:

Hi Randy,

Am Sonntag, 7. Mai 2017, 22:34:46 CEST schrieb Randy Li:

The PWM devices need to access the grf to switch the PWM IP.

The grf property is not part of the pwm binding and I remember
this coming up in veyron times, when Thiery didn't want such settings
in the pwm driver. So the kernel pwm driver does not switch anything
right now.

OK, I see, I will contact the u-boot, submit a patch there.




And tsadc uses it to shutdown the system.

No it doesn't. The tsadc on rk3288 does not do any grf settings right now,
as it is using the v2_initialize function. Only rk3366 and rk3399 seem
to do any grf settings in the current v4.12-rc1 . Or is there some tsadc
patch from you pending to change that?
Not yet, there is a register CRU_GLB_RST_ST at rk3288 cru. I think I 
need to submit a patch for it.



Heiko

Re: [PATCH] ARM: dts: rockchip: add missing grf phandle for rk3288

[ayaka]

On 05/14/2017 10:59 PM, Heiko Stuebner wrote:

Hi Randy,

Am Sonntag, 7. Mai 2017, 22:34:46 CEST schrieb Randy Li:

The PWM devices need to access the grf to switch the PWM IP.

The grf property is not part of the pwm binding and I remember
this coming up in veyron times, when Thiery didn't want such settings
in the pwm driver. So the kernel pwm driver does not switch anything
right now.

OK, I see, I will contact the u-boot, submit a patch there.




And tsadc uses it to shutdown the system.

No it doesn't. The tsadc on rk3288 does not do any grf settings right now,
as it is using the v2_initialize function. Only rk3366 and rk3399 seem
to do any grf settings in the current v4.12-rc1 . Or is there some tsadc
patch from you pending to change that?
Not yet, there is a register CRU_GLB_RST_ST at rk3288 cru. I think I 
need to submit a patch for it.



Heiko

Re: [PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats

[ayaka]

On 04/18/2017 03:33 AM, Mauro Carvalho Chehab wrote:

Em Sun,  5 Mar 2017 18:00:32 +0800
Randy Li  escreveu:


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,
Some developers from Gstreamer think it should be renamed as CM10 for 
the P010CM, I don't have much idea about that.

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.

You should check your patches with checkpatch... I'm getting
this:


WARNING: 'simliar' may be misspelled - perhaps 'similar'?
#61: FILE: Documentation/media/uapi/v4l/pixfmt-p010.rst:13:
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``

I am sorry about that



WARNING: 'simliar' may be misspelled - perhaps 'similar'?
#334: FILE: Documentation/media/uapi/v4l/pixfmt-p016.rst:13:
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``



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``

It is probably ok to use the UTF symbol for 1/2, but you should check
if both PDF and HTML outputs will be ok.

I see, I would upload a new version later



+
+
+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 

Re: [PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats

[ayaka]

On 04/18/2017 03:33 AM, Mauro Carvalho Chehab wrote:

Em Sun,  5 Mar 2017 18:00:32 +0800
Randy Li  escreveu:


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,
Some developers from Gstreamer think it should be renamed as CM10 for 
the P010CM, I don't have much idea about that.

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.

You should check your patches with checkpatch... I'm getting
this:


WARNING: 'simliar' may be misspelled - perhaps 'similar'?
#61: FILE: Documentation/media/uapi/v4l/pixfmt-p010.rst:13:
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``

I am sorry about that



WARNING: 'simliar' may be misspelled - perhaps 'similar'?
#334: FILE: Documentation/media/uapi/v4l/pixfmt-p016.rst:13:
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``



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``

It is probably ok to use the UTF symbol for 1/2, but you should check
if both PDF and HTML outputs will be ok.

I see, I would upload a new version later



+
+
+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
--- 

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Clint Taylor <clinton.a.tay...@intel.com> 於 2017年3月28日 上午6:49 寫道：
> 
>> On 03/26/2017 09:05 PM, Ayaka wrote:
>> 
>> 
>> 從我的 iPad 傳送
>> 
>>>> Ander Conselvan De Oliveira <conselv...@gmail.com> 於 2017年3月14日 下午9:53 寫道：
>>>> 
>>>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>>>> 
>>>> 從我的 iPad 傳送
>>>> 
>>>>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月7日 上午2:34 寫道：
>>>>>> 
>>>>>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
>>>>>> 
>>>>>> 
>>>>>> 從我的 iPad 傳送
>>>>>> 
>>>>>>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月6日 下午9:06 寫道：
>>>>>>>> 
>>>>>>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>>>>>>>> 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.
>>>>>>> 
>>>>>>> What? Why? You just undid what Clint did in v6.
>>>>>> 
>>>>>> He missed a file also keeping the wrong description of rockchip.
>>>>> 
>>>>> I don't follow. Who missed what exactly?
>>>> 
>>>> What he sent is v5, I increase the order number twice in the message, it 
>>>> confuse me as well.
>>>> I think Clint forgot the include/uapi/drm/drm_fourcc.h .
>>> 
>>> Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
>>> 
>>> https://patchwork.freedesktop.org/patch/141342/
>> Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
>> since I think the V is after the U.
> 
> From the MSDN fourcc website:
> "If the combined U-V array is addressed as an array of DWORDs, the least 
> significant word (LSW) contains the U value and the most significant word 
> (MSW) contains the V value. The stride of the combined U-V plane is equal to 
> the stride of the Y plane. The U-V plane has half as many lines as the Y 
> plane."
> 
> The LSW contains U and the MSW contains V, hence the Cr:Cb in the comments of 
> the V6 patch.
> 
> -Clint
ok it is correct. I think I mistake it that is why my converter for gstreamer 
doesn't work
> 
>>> 
>>> 
>>> Ander
>>> 
>>>>> 
>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> 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 },
>>>&g

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Clint Taylor  於 2017年3月28日 上午6:49 寫道：
> 
>> On 03/26/2017 09:05 PM, Ayaka wrote:
>> 
>> 
>> 從我的 iPad 傳送
>> 
>>>> Ander Conselvan De Oliveira  於 2017年3月14日 下午9:53 寫道：
>>>> 
>>>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>>>> 
>>>> 從我的 iPad 傳送
>>>> 
>>>>>> Ville Syrjälä  於 2017年3月7日 上午2:34 寫道：
>>>>>> 
>>>>>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
>>>>>> 
>>>>>> 
>>>>>> 從我的 iPad 傳送
>>>>>> 
>>>>>>>> Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
>>>>>>>> 
>>>>>>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>>>>>>>> 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.
>>>>>>> 
>>>>>>> What? Why? You just undid what Clint did in v6.
>>>>>> 
>>>>>> He missed a file also keeping the wrong description of rockchip.
>>>>> 
>>>>> I don't follow. Who missed what exactly?
>>>> 
>>>> What he sent is v5, I increase the order number twice in the message, it 
>>>> confuse me as well.
>>>> I think Clint forgot the include/uapi/drm/drm_fourcc.h .
>>> 
>>> Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
>>> 
>>> https://patchwork.freedesktop.org/patch/141342/
>> Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
>> since I think the V is after the U.
> 
> From the MSDN fourcc website:
> "If the combined U-V array is addressed as an array of DWORDs, the least 
> significant word (LSW) contains the U value and the most significant word 
> (MSW) contains the V value. The stride of the combined U-V plane is equal to 
> the stride of the Y plane. The U-V plane has half as many lines as the Y 
> plane."
> 
> The LSW contains U and the MSW contains V, hence the Cr:Cb in the comments of 
> the V6 patch.
> 
> -Clint
ok it is correct. I think I mistake it that is why my converter for gstreamer 
doesn't work
> 
>>> 
>>> 
>>> Ander
>>> 
>>>>> 
>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> 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,  .nu

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Ander Conselvan De Oliveira <conselv...@gmail.com> 於 2017年3月14日 下午9:53 寫道：
> 
>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>> 
>> 從我的 iPad 傳送
>> 
>>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月7日 上午2:34 寫道：
>>>> 
>>>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
>>>> 
>>>> 
>>>> 從我的 iPad 傳送
>>>> 
>>>>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月6日 下午9:06 寫道：
>>>>>> 
>>>>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>>>>>> 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.
>>>>> 
>>>>> What? Why? You just undid what Clint did in v6.
>>>> 
>>>> He missed a file also keeping the wrong description of rockchip.
>>> 
>>> I don't follow. Who missed what exactly?
>> 
>> What he sent is v5, I increase the order number twice in the message, it 
>> confuse me as well. 
>> I think Clint forgot the include/uapi/drm/drm_fourcc.h .
> 
> Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
> 
> https://patchwork.freedesktop.org/patch/141342/
Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
since I think the V is after the U.
> 
> 
> Ander
> 
>>> 
>>> 
>>>>> 
>>>>>> 
>>>>>> 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
>>>>> 
>>>>> -- 
>>>>> Ville Syrjälä
>>>>> Intel OTC
>>> 
>>> -- 
>>> Ville Syrjälä
>>> Intel OTC
>> 
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Ander Conselvan De Oliveira  於 2017年3月14日 下午9:53 寫道：
> 
>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>> 
>> 從我的 iPad 傳送
>> 
>>>> Ville Syrjälä  於 2017年3月7日 上午2:34 寫道：
>>>> 
>>>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
>>>> 
>>>> 
>>>> 從我的 iPad 傳送
>>>> 
>>>>>> Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
>>>>>> 
>>>>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>>>>>> 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.
>>>>> 
>>>>> What? Why? You just undid what Clint did in v6.
>>>> 
>>>> He missed a file also keeping the wrong description of rockchip.
>>> 
>>> I don't follow. Who missed what exactly?
>> 
>> What he sent is v5, I increase the order number twice in the message, it 
>> confuse me as well. 
>> I think Clint forgot the include/uapi/drm/drm_fourcc.h .
> 
> Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
> 
> https://patchwork.freedesktop.org/patch/141342/
Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
since I think the V is after the U.
> 
> 
> Ander
> 
>>> 
>>> 
>>>>> 
>>>>>> 
>>>>>> 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
>>>>> 
>>>>> -- 
>>>>> Ville Syrjälä
>>>>> Intel OTC
>>> 
>>> -- 
>>> Ville Syrjälä
>>> Intel OTC
>> 
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月7日 上午2:34 寫道：
> 
>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
>> 
>> 
>> 從我的 iPad 傳送
>> 
>>>> Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月6日 下午9:06 寫道：
>>>> 
>>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>>>> 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.
>>> 
>>> What? Why? You just undid what Clint did in v6.
>> He missed a file also keeping the wrong description of rockchip.
> 
> I don't follow. Who missed what exactly?
What he sent is v5, I increase the order number twice in the message, it 
confuse me as well. 
I think Clint forgot the include/uapi/drm/drm_fourcc.h .
> 
> 
>>> 
>>>> 
>>>> 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
>>> 
>>> -- 
>>> Ville Syrjälä
>>> Intel OTC
> 
> -- 
> Ville Syrjälä
> Intel OTC

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Ville Syrjälä  於 2017年3月7日 上午2:34 寫道：
> 
>> On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
>> 
>> 
>> 從我的 iPad 傳送
>> 
>>>> Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
>>>> 
>>>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>>>> 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.
>>> 
>>> What? Why? You just undid what Clint did in v6.
>> He missed a file also keeping the wrong description of rockchip.
> 
> I don't follow. Who missed what exactly?
What he sent is v5, I increase the order number twice in the message, it 
confuse me as well. 
I think Clint forgot the include/uapi/drm/drm_fourcc.h .
> 
> 
>>> 
>>>> 
>>>> 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
>>> 
>>> -- 
>>> Ville Syrjälä
>>> Intel OTC
> 
> -- 
> Ville Syrjälä
> Intel OTC

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
> 
>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>> 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.
> 
> What? Why? You just undid what Clint did in v6.
He missed a file also keeping the wrong description of rockchip.
> 
>> 
>> 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
> 
> -- 
> Ville Syrjälä
> Intel OTC

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
> 
>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>> 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.
> 
> What? Why? You just undid what Clint did in v6.
He missed a file also keeping the wrong description of rockchip.
> 
>> 
>> 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
> 
> -- 
> Ville Syrjälä
> Intel OTC

Re: [PATCH v10 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform

[ayaka]

What is wrong with this patch? I have not seen it is merged in 
next-20170303.



On 12/11/2016 11:36 PM, Randy Li wrote:

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 
Acked-by: John Youn 
---
  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);

Re: [PATCH v10 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform

[ayaka]

What is wrong with this patch? I have not seen it is merged in 
next-20170303.



On 12/11/2016 11:36 PM, Randy Li wrote:

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 
Acked-by: John Youn 
---
  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);

Re: [PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[Ayaka]

從我的 iPad 傳送

> Mauro Carvalho Chehab <mche...@s-opensource.com> 於 2017年2月3日 下午10:04 寫道：
> 
> Em Thu, 5 Jan 2017 20:27:17 +0200
> Sakari Ailus <sakari.ai...@iki.fi> escreveu:
> 
>> Hi Randy,
>> 
>>> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
>>> 
>>> 
>>>> On 01/05/2017 06:30 PM, Sakari Ailus wrote:  
>>>> Hi Randy,
>>>> 
>>>> Thanks for the update.
>>>> 
>>>>> On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:  
>>>>> 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 
>>>>> ++  
>>>> You need to include the formats in pixfmt.rst in order to compile the
>>>> documentation.
>>>> 
>>>> $ make htmldocs
>>>> 
>>>> And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
>>>> 
>>>> In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
>>>> .  
>>> OK, I would fix them in new version.
>>> The view of byte order for P010 serial is left empty, it is a little hard
>>> for me to use flat-table to draw them. Is there possible to use something
>>> like latex to do this job?  
>> 
>> Hmm. Not as far as I know. We recently switched from DocBook mostly due to
>> ReST being more simple to use AFAIU. I think LaTeX output could be produced
>> ReST, that might not be very helpful here though.
> 
> No, you can't use LaTeX, as it won't be properly displayed on all output
> formats. There are a few options to define tables in ReST, but we prefer
> using flat-table because the other formats are harder to maintain at the
> V4L2 uAPI documentation.
> 
> Just one note about this series: it won't be merged upstream until
> someone adds a driver needing those pixel formats.
> 
I made a mistake, the pixel format I want is not P010, I would post a new patch 
for that.
> Regards,
> Mauro
> 
> 
> Thanks,
> Mauro

Re: [PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[Ayaka]

從我的 iPad 傳送

> Mauro Carvalho Chehab  於 2017年2月3日 下午10:04 寫道：
> 
> Em Thu, 5 Jan 2017 20:27:17 +0200
> Sakari Ailus  escreveu:
> 
>> Hi Randy,
>> 
>>> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
>>> 
>>> 
>>>> On 01/05/2017 06:30 PM, Sakari Ailus wrote:  
>>>> Hi Randy,
>>>> 
>>>> Thanks for the update.
>>>> 
>>>>> On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:  
>>>>> 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 
>>>>> ++  
>>>> You need to include the formats in pixfmt.rst in order to compile the
>>>> documentation.
>>>> 
>>>> $ make htmldocs
>>>> 
>>>> And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
>>>> 
>>>> In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
>>>> .  
>>> OK, I would fix them in new version.
>>> The view of byte order for P010 serial is left empty, it is a little hard
>>> for me to use flat-table to draw them. Is there possible to use something
>>> like latex to do this job?  
>> 
>> Hmm. Not as far as I know. We recently switched from DocBook mostly due to
>> ReST being more simple to use AFAIU. I think LaTeX output could be produced
>> ReST, that might not be very helpful here though.
> 
> No, you can't use LaTeX, as it won't be properly displayed on all output
> formats. There are a few options to define tables in ReST, but we prefer
> using flat-table because the other formats are harder to maintain at the
> V4L2 uAPI documentation.
> 
> Just one note about this series: it won't be merged upstream until
> someone adds a driver needing those pixel formats.
> 
I made a mistake, the pixel format I want is not P010, I would post a new patch 
for that.
> Regards,
> Mauro
> 
> 
> Thanks,
> Mauro

rockchip: edp: Meet a problem with supporting eDP panel at firefly release

[ayaka]

Hello:

I meet a problem when I want to add support for a lg,lp079qx1-sp0v eDP 
panel at firefly release rk3288 platform. I could hardly make the eDP 
work both on firefly release and firefly reload. Does you have any idea 
about that?


[   11.136586] i2c i2c-6: of_i2c: modalias failure on /dp@ff97/ports
[   11.143127] i2c i2c-6: Failed to create I2C device for /dp@ff97/ports
[   11.150288] rockchip-drm display-subsystem: bound ff97.dp (ops 
rockchip_dp_component_ops [analogix_dp_rockchip])

[   11.160944] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   11.167645] [drm] No driver support for vblank timestamp query.
[  OK  ] Started LSB: Load kernel modules needed to enable cpufreq scaling.
[   11.205908] rockchip-drm display-subsystem: fb0:  frame buffer device
[   11.221525] [drm] Initialized rockchip 1.0.0 20140818 for 
display-subsystem on minor 0

[   11.275427] rockchip-dp ff97.dp: AUX CH command reply failed!
[  OK  ] Created slice system-systemd\x2dbacklight.slice.
 Starting Load/Save Screen Backlight...htness of 
backlight:backlight...

 Starting LSB: set CPUFreq kernel parameters...
[   11.450557] rockchip-dp ff97.dp: Rx Max Link Rate is abnormal :20 !
[   11.457274] rockchip-dp ff97.dp: Rx Max Lane count is abnormal :0 !
[   11.480023] rockchip-dp ff97.dp: AUX CH command reply failed!
[   11.532742] rockchip-dp ff97.dp: AUX CH command reply failed!
[   11.595626] rockchip-dp ff97.dp: LT link start failed!
[   11.601167] rockchip-dp ff97.dp: eDP link training failed (-121)
[  OK  ] Started Load/Save Screen Backlight Brightness of 
backlight:backlight.

[   11.622300] rockchip-dp ff97.dp: AUX CH command reply failed!
[   11.637980] rockchip-dp ff97.dp: AUX CH command reply failed!
[   11.667878] rockchip-dp ff97.dp: AUX CH command reply failed!

rockchip: edp: Meet a problem with supporting eDP panel at firefly release

[ayaka]

Hello:

I meet a problem when I want to add support for a lg,lp079qx1-sp0v eDP 
panel at firefly release rk3288 platform. I could hardly make the eDP 
work both on firefly release and firefly reload. Does you have any idea 
about that?


[   11.136586] i2c i2c-6: of_i2c: modalias failure on /dp@ff97/ports
[   11.143127] i2c i2c-6: Failed to create I2C device for /dp@ff97/ports
[   11.150288] rockchip-drm display-subsystem: bound ff97.dp (ops 
rockchip_dp_component_ops [analogix_dp_rockchip])

[   11.160944] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   11.167645] [drm] No driver support for vblank timestamp query.
[  OK  ] Started LSB: Load kernel modules needed to enable cpufreq scaling.
[   11.205908] rockchip-drm display-subsystem: fb0:  frame buffer device
[   11.221525] [drm] Initialized rockchip 1.0.0 20140818 for 
display-subsystem on minor 0

[   11.275427] rockchip-dp ff97.dp: AUX CH command reply failed!
[  OK  ] Created slice system-systemd\x2dbacklight.slice.
 Starting Load/Save Screen Backlight...htness of 
backlight:backlight...

 Starting LSB: set CPUFreq kernel parameters...
[   11.450557] rockchip-dp ff97.dp: Rx Max Link Rate is abnormal :20 !
[   11.457274] rockchip-dp ff97.dp: Rx Max Lane count is abnormal :0 !
[   11.480023] rockchip-dp ff97.dp: AUX CH command reply failed!
[   11.532742] rockchip-dp ff97.dp: AUX CH command reply failed!
[   11.595626] rockchip-dp ff97.dp: LT link start failed!
[   11.601167] rockchip-dp ff97.dp: eDP link training failed (-121)
[  OK  ] Started Load/Save Screen Backlight Brightness of 
backlight:backlight.

[   11.622300] rockchip-dp ff97.dp: AUX CH command reply failed!
[   11.637980] rockchip-dp ff97.dp: AUX CH command reply failed!
[   11.667878] rockchip-dp ff97.dp: AUX CH command reply failed!

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[ayaka]

On 01/15/2017 12:54 AM, Eduardo Valentin wrote:

Folks,

On Wed, Jan 04, 2017 at 12:30:40AM +0800, ayaka wrote:


On 01/03/2017 09:13 AM, Randy Li wrote:


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.

I check the schematic, the otp interrupt is not used at firefly reload nor
connected to the control of PMIC.
I also check power supply, the power is PD_PERI domain comes from VD_LOGIC
which is always on all the platform.
It more likely the tsadc doesn't report correctly temperature value?

Folks, I got a bit confused about this discussion. I have put these
patches into linux-next, as I did not see anything wrong with them. And
I was about to send to next -rc.

Are these correct or not? Is it fine to move forward with them?
Yes, but you need to merge the other patch the Caesar just sent, or it 
would stop the booting sequence at rk3288.


I believe for tomorrows rc is a bit too late, but I think they could
still go to the next rc.

BR,


-Caesar

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[ayaka]

On 01/15/2017 12:54 AM, Eduardo Valentin wrote:

Folks,

On Wed, Jan 04, 2017 at 12:30:40AM +0800, ayaka wrote:


On 01/03/2017 09:13 AM, Randy Li wrote:


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.

I check the schematic, the otp interrupt is not used at firefly reload nor
connected to the control of PMIC.
I also check power supply, the power is PD_PERI domain comes from VD_LOGIC
which is always on all the platform.
It more likely the tsadc doesn't report correctly temperature value?

Folks, I got a bit confused about this discussion. I have put these
patches into linux-next, as I did not see anything wrong with them. And
I was about to send to next -rc.

Are these correct or not? Is it fine to move forward with them?
Yes, but you need to merge the other patch the Caesar just sent, or it 
would stop the booting sequence at rk3288.


I believe for tomorrows rc is a bit too late, but I think they could
still go to the next rc.

BR,


-Caesar

Re: [PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[ayaka]

On 01/05/2017 06:30 PM, Sakari Ailus wrote:

Hi Randy,

Thanks for the update.

On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:

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 ++

You need to include the formats in pixfmt.rst in order to compile the
documentation.

$ make htmldocs

And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .

In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
.

OK, I would fix them in new version.
The view of byte order for P010 serial is left empty, it is a little 
hard for me to use flat-table to draw them. Is there possible to use 
something like latex to do this job?


Regarding P010 and the rest --- I'm fine with that, considering also that
NV12 was never a great name for a format...

Re: [PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[ayaka]

On 01/05/2017 06:30 PM, Sakari Ailus wrote:

Hi Randy,

Thanks for the update.

On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:

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 ++

You need to include the formats in pixfmt.rst in order to compile the
documentation.

$ make htmldocs

And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .

In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
.

OK, I would fix them in new version.
The view of byte order for P010 serial is left empty, it is a little 
hard for me to use flat-table to draw them. Is there possible to use 
something like latex to do this job?


Regarding P010 and the rest --- I'm fine with that, considering also that
NV12 was never a great name for a format...

Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Daniel Stone  於 2017年1月5日 上午1:02 寫道：
> 
> Hi Randy,
> 
>> On 4 January 2017 at 16:29, Randy Li  wrote:
>> 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 },
> 
> It seems like P010 stores each Y component in a 16-bit value, with the
> bottom 6 bits ignored. So I think cpp here should be 2.
No, the rest bits are used to store the next pixel. The P010 is just a 10 bits 
color depth pixel format.
> 
> Cheers,
> Daniel

Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

[Ayaka]

從我的 iPad 傳送

> Daniel Stone  於 2017年1月5日 上午1:02 寫道：
> 
> Hi Randy,
> 
>> On 4 January 2017 at 16:29, Randy Li  wrote:
>> 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 },
> 
> It seems like P010 stores each Y component in a 16-bit value, with the
> bottom 6 bits ignored. So I think cpp here should be 2.
No, the rest bits are used to store the next pixel. The P010 is just a 10 bits 
color depth pixel format.
> 
> Cheers,
> Daniel

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

[ayaka]

On 01/04/2017 11:56 PM, Ville Syrjälä wrote:

On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote:

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_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 */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cr:Cb plane 10 bits per channel */

We could use a better description of the format here. IIRC there is
10bits of actual data contained in each 16bits. So there should be a
proper comment explaning in which way the bits are stored.
It is a little hard to describe P010, which leaves a problem cpp 
information in the new patches.
Also I have no idea how to draw the byte-order table the rst document 
for v4l2.


  
  /*

   * 3 plane YCbCr
--
2.7.4

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

[ayaka]

On 01/04/2017 11:56 PM, Ville Syrjälä wrote:

On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote:

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_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 */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cr:Cb plane 10 bits per channel */

We could use a better description of the format here. IIRC there is
10bits of actual data contained in each 16bits. So there should be a
proper comment explaning in which way the bits are stored.
It is a little hard to describe P010, which leaves a problem cpp 
information in the new patches.
Also I have no idea how to draw the byte-order table the rst document 
for v4l2.


  
  /*

   * 3 plane YCbCr
--
2.7.4

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] mmc: dw_mmc: revise the reset path in runtime resume

[ayaka]

On 01/04/2017 08:51 PM, Ziyuan Xu wrote:

Immediately after reset, issue the command which sets
update_clock_register_only bit, the card clock will restart. Revise
dw_mci_ctrl_reset to dw_mci_reset, which has wrapped this sequence.

The patch fixes commit e9ed8835e990 ("mmc: dw_mmc: add runtime PM
callback"). MMC_PM_KEEP_POWEP is disabled for SD card and eMMC slots, so
that they have no chance to invoke dw_mci_setup_bus for update clock
behaviour. Let's consummate it.

Reported-by: Randy Li 
Signed-off-by: Ziyuan Xu 
Thank you Ziyuan, it works for me, but I capture those warning message 
in boot log
[5.943096] Unable to handle kernel NULL pointer dereference at 
virtual address 0004

[5.951227] pgd = c0004000
[5.953958] [0004] *pgd=
[5.957563] Internal error: Oops: 5 [#1] SMP ARM
[5.962177] Modules linked in:
[5.965238] CPU: 0 PID: 117 Comm: kworker/0:3 Not tainted 
4.9.0-next-20161224+ #122

[5.972875] Hardware name: Rockchip (Device Tree)
[5.977586] Workqueue: events_freezable mmc_rescan
[5.982377] task: ee186740 task.stack: ee1d2000
[5.986908] PC is at mci_send_cmd.constprop.5+0x20/0xb0
[5.992129] LR is at dw_mci_reset+0xdc/0x130
[5.996400] pc : []lr : [] psr: 6013
[5.996400] sp : ee1d3d38  ip : ee1d3d68  fp : ee1d3d64
[6.007862] r10: ee1d2000  r9 : c04fe918  r8 : c04fe918
[6.013083] r7 : c0c03d00  r6 : ee171780  r5 : c0c03d00  r4 : ee17e618
[6.019604] r3 : 0201  r2 : f08e4000  r1 : 0020  r0 : 
[6.026127] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
Segment none

[6.033253] Control: 10c5387d  Table: 406a  DAC: 0051
[6.038994] Process kworker/0:3 (pid: 117, stack limit = 0xee1d2210)
[6.045340] Stack: (0xee1d3d38 to 0xee1d4000)
[6.049696] 
3d20:   c0495ed0 
c0714e60
[6.057870] 3d40: ee17e618 0001 ee171780 c0c03d00 c04fe918 
c04fe918 ee1d3d7c ee1d3d68
[6.066043] 3d60: c05d0308 c05cf450 ee17e618  ee1d3da4 
ee1d3d80 c05d07fc c05d0238
[6.074216] 3d80:  eeae5a10  c0c03d00 c04fe918 
c04fe918 ee1d3db4 ee1d3da8
[6.082389] 3da0: c04fe954 c05d0718 ee1d3dec ee1d3db8 c0501c70 
c04fe924 c0162310 c044f7b0
[6.090563] 3dc0:  eeae5a10 c0c62510  c0c03d00 
c04fe918 c0175574 ee1d2000
[6.098737] 3de0: ee1d3e0c ee1d3df0 c0501df0 c0501b88 eeae5a10 
c0c62510  c0c03d00
[6.106911] 3e00: ee1d3e5c ee1d3e10 c0501898 c0501dcc c0c0408c 
eeae5aa8 eeda0d00 
[6.115085] 3e20: c0c04108 ee1867c0 ee1d3eac 00040900 c016e53c 
eeae5a10 0004 eeae5a84
[6.123259] 3e40: 6013 ee1d2000 c0c0408c ee160c00 ee1d3e7c 
ee1d3e60 c0501b5c c05013e4
[6.131433] 3e60:  ee160e1c 2013  ee1d3ecc 
ee1d3e80 c05b0128 c0501af8
[6.139607] 3e80: e000 ee160e80  ee186740 c0156324 
0100 0200 00040900
[6.147781] 3ea0: ee1d3f14 ee160e94 ee160e1c ee160c00 6013 
eeda3e00 ee160e98 
[6.155956] 3ec0: ee1d3ef4 ee1d3ed0 c05b3a68 c05aff80 ee160e94 
ee176380 eeda0880 
[6.164130] 3ee0: eeda3e00 ee160e98 ee1d3f2c ee1d3ef8 c0142374 
c05b383c c0c03d00 eeda0898
[6.172303] 3f00: ee1d2000 eeda0880 ee176398 0008 c0c03d00 
eeda0898 ee1d2000 ee176380
[6.180477] 3f20: ee1d3f74 ee1d3f30 c014329c c01421d0 ee1d3f54 
c0959c8c ee1d2000 
[6.188650] 3f40: ee15a880 c0c20f1a ee1d1e7c eea00600 ee1d2000 
 ee15a880 ee176380
[6.196824] 3f60: ee1d1e7c eea0061c ee1d3fac ee1d3f78 c0148ed0 
c0143248  c014323c
[6.204996] 3f80: ee1d3fac ee15a880 c0148da8   
  
[6.213168] 3fa0:  ee1d3fb0 c0108e90 c0148db4  
  
[6.221341] 3fc0:      
  
[6.229514] 3fe0:     0013 
  
[6.237696] [] (mci_send_cmd.constprop.5) from [] 
(dw_mci_reset+0xdc/0x130)
[6.246393] [] (dw_mci_reset) from [] 
(dw_mci_runtime_resume+0xf0/0x1cc)
[6.254833] [] (dw_mci_runtime_resume) from [] 
(pm_generic_runtime_resume+0x3c/0x48)
[6.264313] [] (pm_generic_runtime_resume) from 
[] (__rpm_callback+0xf4/0x244)
[6.273273] [] (__rpm_callback) from [] 
(rpm_callback+0x30/0x90)
[6.281017] [] (rpm_callback) from [] 
(rpm_resume+0x4c0/0x714)
[6.288588] [] (rpm_resume) from [] 
(__pm_runtime_resume+0x70/0x90)
[6.296592] [] (__pm_runtime_resume) from [] 
(__mmc_claim_host+0x1b4/0x1ec)
[6.305287] [] (__mmc_claim_host) from [] 
(mmc_rescan+0x238/0x3f4)
[6.313206] [] (mmc_rescan) from [] 
(process_one_work+0x1b0/0x4c0)
[6.321125] [] (process_one_work) from [] 
(worker_thread+0x60/0x548)
[6.329215] [] (worker_thread) from [] 
(kthread+0x128/0x158)
[6.336614] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)

[6.343836] Code: e52de004 

Re: [PATCH v2] mmc: dw_mmc: revise the reset path in runtime resume

[ayaka]

On 01/04/2017 08:51 PM, Ziyuan Xu wrote:

Immediately after reset, issue the command which sets
update_clock_register_only bit, the card clock will restart. Revise
dw_mci_ctrl_reset to dw_mci_reset, which has wrapped this sequence.

The patch fixes commit e9ed8835e990 ("mmc: dw_mmc: add runtime PM
callback"). MMC_PM_KEEP_POWEP is disabled for SD card and eMMC slots, so
that they have no chance to invoke dw_mci_setup_bus for update clock
behaviour. Let's consummate it.

Reported-by: Randy Li 
Signed-off-by: Ziyuan Xu 
Thank you Ziyuan, it works for me, but I capture those warning message 
in boot log
[5.943096] Unable to handle kernel NULL pointer dereference at 
virtual address 0004

[5.951227] pgd = c0004000
[5.953958] [0004] *pgd=
[5.957563] Internal error: Oops: 5 [#1] SMP ARM
[5.962177] Modules linked in:
[5.965238] CPU: 0 PID: 117 Comm: kworker/0:3 Not tainted 
4.9.0-next-20161224+ #122

[5.972875] Hardware name: Rockchip (Device Tree)
[5.977586] Workqueue: events_freezable mmc_rescan
[5.982377] task: ee186740 task.stack: ee1d2000
[5.986908] PC is at mci_send_cmd.constprop.5+0x20/0xb0
[5.992129] LR is at dw_mci_reset+0xdc/0x130
[5.996400] pc : []lr : [] psr: 6013
[5.996400] sp : ee1d3d38  ip : ee1d3d68  fp : ee1d3d64
[6.007862] r10: ee1d2000  r9 : c04fe918  r8 : c04fe918
[6.013083] r7 : c0c03d00  r6 : ee171780  r5 : c0c03d00  r4 : ee17e618
[6.019604] r3 : 0201  r2 : f08e4000  r1 : 0020  r0 : 
[6.026127] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
Segment none

[6.033253] Control: 10c5387d  Table: 406a  DAC: 0051
[6.038994] Process kworker/0:3 (pid: 117, stack limit = 0xee1d2210)
[6.045340] Stack: (0xee1d3d38 to 0xee1d4000)
[6.049696] 
3d20:   c0495ed0 
c0714e60
[6.057870] 3d40: ee17e618 0001 ee171780 c0c03d00 c04fe918 
c04fe918 ee1d3d7c ee1d3d68
[6.066043] 3d60: c05d0308 c05cf450 ee17e618  ee1d3da4 
ee1d3d80 c05d07fc c05d0238
[6.074216] 3d80:  eeae5a10  c0c03d00 c04fe918 
c04fe918 ee1d3db4 ee1d3da8
[6.082389] 3da0: c04fe954 c05d0718 ee1d3dec ee1d3db8 c0501c70 
c04fe924 c0162310 c044f7b0
[6.090563] 3dc0:  eeae5a10 c0c62510  c0c03d00 
c04fe918 c0175574 ee1d2000
[6.098737] 3de0: ee1d3e0c ee1d3df0 c0501df0 c0501b88 eeae5a10 
c0c62510  c0c03d00
[6.106911] 3e00: ee1d3e5c ee1d3e10 c0501898 c0501dcc c0c0408c 
eeae5aa8 eeda0d00 
[6.115085] 3e20: c0c04108 ee1867c0 ee1d3eac 00040900 c016e53c 
eeae5a10 0004 eeae5a84
[6.123259] 3e40: 6013 ee1d2000 c0c0408c ee160c00 ee1d3e7c 
ee1d3e60 c0501b5c c05013e4
[6.131433] 3e60:  ee160e1c 2013  ee1d3ecc 
ee1d3e80 c05b0128 c0501af8
[6.139607] 3e80: e000 ee160e80  ee186740 c0156324 
0100 0200 00040900
[6.147781] 3ea0: ee1d3f14 ee160e94 ee160e1c ee160c00 6013 
eeda3e00 ee160e98 
[6.155956] 3ec0: ee1d3ef4 ee1d3ed0 c05b3a68 c05aff80 ee160e94 
ee176380 eeda0880 
[6.164130] 3ee0: eeda3e00 ee160e98 ee1d3f2c ee1d3ef8 c0142374 
c05b383c c0c03d00 eeda0898
[6.172303] 3f00: ee1d2000 eeda0880 ee176398 0008 c0c03d00 
eeda0898 ee1d2000 ee176380
[6.180477] 3f20: ee1d3f74 ee1d3f30 c014329c c01421d0 ee1d3f54 
c0959c8c ee1d2000 
[6.188650] 3f40: ee15a880 c0c20f1a ee1d1e7c eea00600 ee1d2000 
 ee15a880 ee176380
[6.196824] 3f60: ee1d1e7c eea0061c ee1d3fac ee1d3f78 c0148ed0 
c0143248  c014323c
[6.204996] 3f80: ee1d3fac ee15a880 c0148da8   
  
[6.213168] 3fa0:  ee1d3fb0 c0108e90 c0148db4  
  
[6.221341] 3fc0:      
  
[6.229514] 3fe0:     0013 
  
[6.237696] [] (mci_send_cmd.constprop.5) from [] 
(dw_mci_reset+0xdc/0x130)
[6.246393] [] (dw_mci_reset) from [] 
(dw_mci_runtime_resume+0xf0/0x1cc)
[6.254833] [] (dw_mci_runtime_resume) from [] 
(pm_generic_runtime_resume+0x3c/0x48)
[6.264313] [] (pm_generic_runtime_resume) from 
[] (__rpm_callback+0xf4/0x244)
[6.273273] [] (__rpm_callback) from [] 
(rpm_callback+0x30/0x90)
[6.281017] [] (rpm_callback) from [] 
(rpm_resume+0x4c0/0x714)
[6.288588] [] (rpm_resume) from [] 
(__pm_runtime_resume+0x70/0x90)
[6.296592] [] (__pm_runtime_resume) from [] 
(__mmc_claim_host+0x1b4/0x1ec)
[6.305287] [] (__mmc_claim_host) from [] 
(mmc_rescan+0x238/0x3f4)
[6.313206] [] (mmc_rescan) from [] 
(process_one_work+0x1b0/0x4c0)
[6.321125] [] (process_one_work) from [] 
(worker_thread+0x60/0x548)
[6.329215] [] (worker_thread) from [] 
(kthread+0x128/0x158)
[6.336614] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)

[6.343836] Code: e52de004 e8bd4000 e3035d00 e34c50c0 (e5909004)
[

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[ayaka]

On 01/03/2017 09:13 AM, Randy Li wrote:



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.
I check the schematic, the otp interrupt is not used at firefly reload 
nor connected to the control of PMIC.
I also check power supply, the power is PD_PERI domain comes from 
VD_LOGIC which is always on all the platform.

It more likely the tsadc doesn't report correctly temperature value?


-Caesar

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[ayaka]

On 01/03/2017 09:13 AM, Randy Li wrote:



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.
I check the schematic, the otp interrupt is not used at firefly reload 
nor connected to the control of PMIC.
I also check power supply, the power is PD_PERI domain comes from 
VD_LOGIC which is always on all the platform.

It more likely the tsadc doesn't report correctly temperature value?


-Caesar

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 07:07 PM, Sakari Ailus wrote:

Hi,

On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:


On 01/02/2017 05:10 PM, Sakari Ailus wrote:

Hi Randy,

Thanks for the patch.

On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:

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>

If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.

Do you mean it would be better if it is called as NV12_10?

If it otherwise resembles NV12 but just has 10 bits per pixel, I think
NV12_10 is a good name for it.
The main reason I don't like it is that there is a various of software 
having used the P010 for this kind of pixel format. It would leadi a 
conflict between them(and I never saw it is used as NV12_10), as the 
P010 is more common to be used.
I left a problem unsolved for P010 in v4l2, P010 have two variant, 
little endian and big endian. Which could be easy identified in drm 
driver(there is a flag for all the big endian pixel format).



Could you also add ReST documentation for the format, please?

I will.

The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this

The kernel used in rockchip has supported that format in drm driver, but
just we don't have a agreement about the pixel format. As the Gstreamer and
some others would call it with a P010_ prefix, but Mark(rockchip's drm
author) prefer the something like NV12_10, that is why I sent out those
patches, I want the upstream decided its final name.

Ack.

I think we haven't really tried to unify the format naming in the past
between the two subsystems. If existing conventions exist on both regarding
this format, then it's probably better to follow those.

Cc Laurent as well.


reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.


---
  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 
*/

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 07:07 PM, Sakari Ailus wrote:

Hi,

On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:


On 01/02/2017 05:10 PM, Sakari Ailus wrote:

Hi Randy,

Thanks for the patch.

On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:

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 

If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.

Do you mean it would be better if it is called as NV12_10?

If it otherwise resembles NV12 but just has 10 bits per pixel, I think
NV12_10 is a good name for it.
The main reason I don't like it is that there is a various of software 
having used the P010 for this kind of pixel format. It would leadi a 
conflict between them(and I never saw it is used as NV12_10), as the 
P010 is more common to be used.
I left a problem unsolved for P010 in v4l2, P010 have two variant, 
little endian and big endian. Which could be easy identified in drm 
driver(there is a flag for all the big endian pixel format).



Could you also add ReST documentation for the format, please?

I will.

The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this

The kernel used in rockchip has supported that format in drm driver, but
just we don't have a agreement about the pixel format. As the Gstreamer and
some others would call it with a P010_ prefix, but Mark(rockchip's drm
author) prefer the something like NV12_10, that is why I sent out those
patches, I want the upstream decided its final name.

Ack.

I think we haven't really tried to unify the format naming in the past
between the two subsystems. If existing conventions exist on both regarding
this format, then it's probably better to follow those.

Cc Laurent as well.


reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.


---
  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 
*/

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 05:10 PM, Sakari Ailus wrote:

Hi Randy,

Thanks for the patch.

On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:

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 

If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.

Do you mean it would be better if it is called as NV12_10?


Could you also add ReST documentation for the format, please?

I will.


The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this
The kernel used in rockchip has supported that format in drm driver, but 
just we don't have a agreement about the pixel format. As the Gstreamer 
and some others would call it with a P010_ prefix, but Mark(rockchip's 
drm author) prefer the something like NV12_10, that is why I sent out 
those patches, I want the upstream decided its final name.

reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.


---
  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 
*/

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 05:10 PM, Sakari Ailus wrote:

Hi Randy,

Thanks for the patch.

On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:

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 

If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.

Do you mean it would be better if it is called as NV12_10?


Could you also add ReST documentation for the format, please?

I will.


The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this
The kernel used in rockchip has supported that format in drm driver, but 
just we don't have a agreement about the pixel format. As the Gstreamer 
and some others would call it with a P010_ prefix, but Mark(rockchip's 
drm author) prefer the something like NV12_10, that is why I sent out 
those patches, I want the upstream decided its final name.

reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.


---
  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 
*/

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[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


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(-)

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

[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


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(-)

Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"

[ayaka]

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



On 12/29/2016 06:25 PM, Randy Li wrote:


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"

Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"

[ayaka]

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



On 12/29/2016 06:25 PM, Randy Li wrote:


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 @@ 

Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"

[ayaka]

[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.



On 12/29/2016 06:25 PM, Randy Li wrote:



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)
  

Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"

[ayaka]

[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.



On 12/29/2016 06:25 PM, Randy Li wrote:



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 

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

[ayaka]

On 12/07/2016 10:55 PM, Daniel Vetter wrote:

On Wed, Dec 07, 2016 at 08:57:23AM +0800, Ayaka wrote:


從我的 iPad 傳送


Thierry Reding <thierry.red...@gmail.com> 於 2016年12月6日 下午11:46 寫道：


On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.

Signed-off-by: Randy Li <ay...@soulik.info>
---
.../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
drivers/gpu/drm/panel/panel-simple.c   | 27 ++
2 files changed, 34 insertions(+)
create mode 100644 
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

Applied, thanks.

Wait, it is RFC, not pass the test.

Well 2 months of silence, it's reasonable to assume that this works for
you ... I guess you need to supply a fixup patch asap ;-)
Sorry, my exynos 4412 board is broken, I will order one and fix this 
problem, please don't merge this patch until somebody confirm that it is 
adjusted to correct parameter.

-Daniel

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

[ayaka]

On 12/07/2016 10:55 PM, Daniel Vetter wrote:

On Wed, Dec 07, 2016 at 08:57:23AM +0800, Ayaka wrote:


從我的 iPad 傳送


Thierry Reding  於 2016年12月6日 下午11:46 寫道：


On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.

Signed-off-by: Randy Li 
---
.../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
drivers/gpu/drm/panel/panel-simple.c   | 27 ++
2 files changed, 34 insertions(+)
create mode 100644 
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

Applied, thanks.

Wait, it is RFC, not pass the test.

Well 2 months of silence, it's reasonable to assume that this works for
you ... I guess you need to supply a fixup patch asap ;-)
Sorry, my exynos 4412 board is broken, I will order one and fix this 
problem, please don't merge this patch until somebody confirm that it is 
adjusted to correct parameter.

-Daniel

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

[Ayaka]

從我的 iPad 傳送

> Thierry Reding  於 2016年12月6日 下午11:46 寫道：
> 
>> On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
>> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
>> supported by the simple panel driver.
>> 
>> Signed-off-by: Randy Li 
>> ---
>> .../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
>> drivers/gpu/drm/panel/panel-simple.c   | 27 
>> ++
>> 2 files changed, 34 insertions(+)
>> create mode 100644 
>> Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> 
> Applied, thanks.
Wait, it is RFC, not pass the test.
> 
> Thierry

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

[Ayaka]

從我的 iPad 傳送

> Thierry Reding  於 2016年12月6日 下午11:46 寫道：
> 
>> On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
>> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
>> supported by the simple panel driver.
>> 
>> Signed-off-by: Randy Li 
>> ---
>> .../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
>> drivers/gpu/drm/panel/panel-simple.c   | 27 
>> ++
>> 2 files changed, 34 insertions(+)
>> create mode 100644 
>> Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> 
> Applied, thanks.
Wait, it is RFC, not pass the test.
> 
> Thierry

Re: [PATCH v9 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform

[Ayaka]

Hello John
  I still waiting them be merged, but I still can't find it at next-20161206.

從我的 iPad 傳送

> John Youn <john.y...@synopsys.com> 於 2016年10月25日 上午9:30 寫道：
> 
>> On 10/23/2016 2:33 AM, ayaka wrote:
>> 
>> 
>>> On 10/22/2016 03:27 AM, John Youn wrote:
>>>> On 10/20/2016 11:38 AM, Randy Li wrote:
>>>> 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>
>>>> ---
>>>>  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 2a21a04..e91ddbc 100644
>>>> --- a/drivers/usb/dwc2/core.h
>>>> +++ b/drivers/usb/dwc2/core.h
>>>> @@ -859,6 +859,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 d85c5c9..c3d2168 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 8e1728b..65953cf 100644
>>>> --- a/drivers/usb/dwc2/platform.c
>>>> +++ b/drivers/usb/dwc2/platform.c
>>>> @@ -366,6 +366,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

Re: [PATCH v9 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform

[Ayaka]

Hello John
  I still waiting them be merged, but I still can't find it at next-20161206.

從我的 iPad 傳送

> John Youn  於 2016年10月25日 上午9:30 寫道：
> 
>> On 10/23/2016 2:33 AM, ayaka wrote:
>> 
>> 
>>> On 10/22/2016 03:27 AM, John Youn wrote:
>>>> On 10/20/2016 11:38 AM, Randy Li wrote:
>>>> 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 
>>>> ---
>>>>  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 2a21a04..e91ddbc 100644
>>>> --- a/drivers/usb/dwc2/core.h
>>>> +++ b/drivers/usb/dwc2/core.h
>>>> @@ -859,6 +859,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 d85c5c9..c3d2168 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 8e1728b..65953cf 100644
>>>> --- a/drivers/usb/dwc2/platform.c
>>>> +++ b/drivers/usb/dwc2/platform.c
>>>> @@ -366,6 +366,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_wor

Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP

[ayaka]

On 10/28/2016 05:29 PM, Randy Li wrote:



On 10/28/2016 05:11 PM, Shawn Lin wrote:

On 2016/10/23 3:18, Randy Li wrote:

I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first. The eDP_AVDD_1V8 more
likely to be applied to eDP phy, but I have no time to confirmed
it yet.


Comfirm it or at least someone should be able to answer your
question, Mark?

I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is 
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a 
short time.


Have you considered to add some details about vcc-supply and vccio-
supply for your analogix_dp-rockchip.txt ?

From your commit msg, these two properties are more likely to be
required but the code itself tell me them should be optional(from the
point of backward compatibility, it should also be optinoal).
Yes, I keep it optional for the same reason. Most of boards won't turn 
off those power supply and may use some fixed regulators.




Signed-off-by: Randy Li 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
+
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..6bf0441 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,7 @@ struct rockchip_dp_device {
 struct clk   *grfclk;
 struct regmap*grf;
 struct reset_control *rst;
+struct regulator_bulk_data supplies[2];

 struct work_struct psr_work;
 spinlock_t psr_lock;
@@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
analogix_dp_plat_data *plat_data)

 cancel_work_sync(>psr_work);

+ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret) {
+dev_err(dp->dev, "failed to enable vdd supply %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 +177,9 @@ static int rockchip_dp_powerdown(struct
analogix_dp_plat_data *plat_data)

 clk_disable_unprepare(dp->pclk);

+regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+
 return 0;
 }

@@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
rockchip_dp_device *dp)
 return PTR_ERR(dp->rst);
 }

+dp->supplies[0].supply = "vcc";
+dp->supplies[1].supply = "vccio";
+ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret < 0) {
+dev_err(dev, "failed to get regulators: %d\n", ret);
+}
+ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret < 0) {
+dev_err(dev, "failed to enable regulators: %d\n", ret);
+}
+
 ret = clk_prepare_enable(dp->pclk);
 if (ret < 0) {
 dev_err(dp->dev, "failed to enable pclk %d\n", ret);

Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP

[ayaka]

On 10/28/2016 05:29 PM, Randy Li wrote:



On 10/28/2016 05:11 PM, Shawn Lin wrote:

On 2016/10/23 3:18, Randy Li wrote:

I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first. The eDP_AVDD_1V8 more
likely to be applied to eDP phy, but I have no time to confirmed
it yet.


Comfirm it or at least someone should be able to answer your
question, Mark?

I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is 
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a 
short time.


Have you considered to add some details about vcc-supply and vccio-
supply for your analogix_dp-rockchip.txt ?

From your commit msg, these two properties are more likely to be
required but the code itself tell me them should be optional(from the
point of backward compatibility, it should also be optinoal).
Yes, I keep it optional for the same reason. Most of boards won't turn 
off those power supply and may use some fixed regulators.




Signed-off-by: Randy Li 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
+
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..6bf0441 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,7 @@ struct rockchip_dp_device {
 struct clk   *grfclk;
 struct regmap*grf;
 struct reset_control *rst;
+struct regulator_bulk_data supplies[2];

 struct work_struct psr_work;
 spinlock_t psr_lock;
@@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
analogix_dp_plat_data *plat_data)

 cancel_work_sync(>psr_work);

+ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret) {
+dev_err(dp->dev, "failed to enable vdd supply %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 +177,9 @@ static int rockchip_dp_powerdown(struct
analogix_dp_plat_data *plat_data)

 clk_disable_unprepare(dp->pclk);

+regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+
 return 0;
 }

@@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
rockchip_dp_device *dp)
 return PTR_ERR(dp->rst);
 }

+dp->supplies[0].supply = "vcc";
+dp->supplies[1].supply = "vccio";
+ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret < 0) {
+dev_err(dev, "failed to get regulators: %d\n", ret);
+}
+ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret < 0) {
+dev_err(dev, "failed to enable regulators: %d\n", ret);
+}
+
 ret = clk_prepare_enable(dp->pclk);
 if (ret < 0) {
 dev_err(dp->dev, "failed to enable pclk %d\n", ret);

Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP

[ayaka]

On 10/28/2016 05:29 PM, Randy Li wrote:



On 10/28/2016 05:11 PM, Shawn Lin wrote:

On 2016/10/23 3:18, Randy Li wrote:

I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first. The eDP_AVDD_1V8 more
likely to be applied to eDP phy, but I have no time to confirmed
it yet.


Comfirm it or at least someone should be able to answer your
question, Mark?

I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is 
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a 
short time.


Have you considered to add some details about vcc-supply and vccio-
supply for your analogix_dp-rockchip.txt ?

From your commit msg, these two properties are more likely to be
required but the code itself tell me them should be optional(from the
point of backward compatibility, it should also be optinoal).
Yes, I keep it optional for the same reason. Most of boards won't turn 
off those power supply and may use some fixed regulators.




Signed-off-by: Randy Li 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
+
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..6bf0441 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,7 @@ struct rockchip_dp_device {
 struct clk   *grfclk;
 struct regmap*grf;
 struct reset_control *rst;
+struct regulator_bulk_data supplies[2];

 struct work_struct psr_work;
 spinlock_t psr_lock;
@@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
analogix_dp_plat_data *plat_data)

 cancel_work_sync(>psr_work);

+ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret) {
+dev_err(dp->dev, "failed to enable vdd supply %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 +177,9 @@ static int rockchip_dp_powerdown(struct
analogix_dp_plat_data *plat_data)

 clk_disable_unprepare(dp->pclk);

+regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+
 return 0;
 }

@@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
rockchip_dp_device *dp)
 return PTR_ERR(dp->rst);
 }

+dp->supplies[0].supply = "vcc";
+dp->supplies[1].supply = "vccio";
+ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret < 0) {
+dev_err(dev, "failed to get regulators: %d\n", ret);
+}
+ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret < 0) {
+dev_err(dev, "failed to enable regulators: %d\n", ret);
+}
+
 ret = clk_prepare_enable(dp->pclk);
 if (ret < 0) {
 dev_err(dp->dev, "failed to enable pclk %d\n", ret);

Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP

[ayaka]

On 10/28/2016 05:29 PM, Randy Li wrote:



On 10/28/2016 05:11 PM, Shawn Lin wrote:

On 2016/10/23 3:18, Randy Li wrote:

I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first. The eDP_AVDD_1V8 more
likely to be applied to eDP phy, but I have no time to confirmed
it yet.


Comfirm it or at least someone should be able to answer your
question, Mark?

I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is 
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a 
short time.


Have you considered to add some details about vcc-supply and vccio-
supply for your analogix_dp-rockchip.txt ?

From your commit msg, these two properties are more likely to be
required but the code itself tell me them should be optional(from the
point of backward compatibility, it should also be optinoal).
Yes, I keep it optional for the same reason. Most of boards won't turn 
off those power supply and may use some fixed regulators.




Signed-off-by: Randy Li 
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
+
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..6bf0441 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,7 @@ struct rockchip_dp_device {
 struct clk   *grfclk;
 struct regmap*grf;
 struct reset_control *rst;
+struct regulator_bulk_data supplies[2];

 struct work_struct psr_work;
 spinlock_t psr_lock;
@@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
analogix_dp_plat_data *plat_data)

 cancel_work_sync(>psr_work);

+ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret) {
+dev_err(dp->dev, "failed to enable vdd supply %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 +177,9 @@ static int rockchip_dp_powerdown(struct
analogix_dp_plat_data *plat_data)

 clk_disable_unprepare(dp->pclk);

+regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+
 return 0;
 }

@@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
rockchip_dp_device *dp)
 return PTR_ERR(dp->rst);
 }

+dp->supplies[0].supply = "vcc";
+dp->supplies[1].supply = "vccio";
+ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret < 0) {
+dev_err(dev, "failed to get regulators: %d\n", ret);
+}
+ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+dp->supplies);
+if (ret < 0) {
+dev_err(dev, "failed to enable regulators: %d\n", ret);
+}
+
 ret = clk_prepare_enable(dp->pclk);
 if (ret < 0) {
 dev_err(dp->dev, "failed to enable pclk %d\n", ret);

Re: [PATCH v9 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform

[ayaka]

On 10/22/2016 03:27 AM, John Youn wrote:

On 10/20/2016 11:38 AM, Randy Li wrote:

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 
---
  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 2a21a04..e91ddbc 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -859,6 +859,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 d85c5c9..c3d2168 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 8e1728b..65953cf 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -366,6 +366,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;
@@ -410,6 +418,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);


Hi Randy,

This fails compile if CONFIG_GENERIC_PHY is disabled. I think you need
to make a fix to your phy_reset patch first.
In the last time, cac18ecb6f44b11bc303d7afbae3887b27938fa4 have not been 
merged, I though the
[PATCH v8 1/3] phy: Add reset callback for not generic phy have been 
merged before that. when the rebase abandon it.
Should re-send that patch? As the mainline have not been affected, could 
you arrange a squash for it?


Regards,
John

Re: [PATCH v9 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform

[ayaka]

On 10/22/2016 03:27 AM, John Youn wrote:

On 10/20/2016 11:38 AM, Randy Li wrote:

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 
---
  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 2a21a04..e91ddbc 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -859,6 +859,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 d85c5c9..c3d2168 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 8e1728b..65953cf 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -366,6 +366,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;
@@ -410,6 +418,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);


Hi Randy,

This fails compile if CONFIG_GENERIC_PHY is disabled. I think you need
to make a fix to your phy_reset patch first.
In the last time, cac18ecb6f44b11bc303d7afbae3887b27938fa4 have not been 
merged, I though the
[PATCH v8 1/3] phy: Add reset callback for not generic phy have been 
merged before that. when the rebase abandon it.
Should re-send that patch? As the mainline have not been affected, could 
you arrange a squash for it?


Regards,
John

Re: [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp

[ayaka]

On 10/21/2016 04:25 PM, Heiko Stuebner wrote:

Am Donnerstag, 20. Oktober 2016, 15:47:56 CEST schrieb Tomeu Vizoso:

On 10/20/2016 03:45 PM, Heiko Stübner wrote:

Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:

Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
doesn't attemp to parse the 'ports' subnode as containing i2c devices.

This is to avoid spurious failure messages such as:

i2c i2c-6: of_i2c: modalias failure on /dp@ff97/ports

On the one hand, the edp really has an i2c bus - with its only client the
EDID listening at 0x50 (and maybe 0x30).

On the other hand, adding an empty bus to the (implementation independent)
devicetree just to make the Linux i2c subsystem happy sounds heavily like
a
implementation-specific hack, as the edp i2c bus doesn't leak into the
outside world otherwise.

I guess this empty i2c bus not being part of the binding document points
heavily into the implementation-specific corner :-) .

My short search on other patches touching this didn't reveal anything but
maybe this was already discussed somewhere and found to be ok?

Here it is:

http://www.spinics.net/lists/linux-tegra/msg27862.html

thanks ... I'm still not sure about the placeholder though, aka needing an
undocumented subnode to make a Linux error message silent.

Sorry, I report the error result, it would work.

And about the problem at this thread beginning, I found I have to use 
something like Xserver to access DRM or the panel would not be power on. 
The legacy fbdev won't help.
But there is still problem to be solved, so the eDP panel for firefly is 
not ready yet.


In the thread you pointed to I also did not see any dt-maintainer involvement
pointing one way or another, but spinics is often not easy to navigate
threads, so I may have missed that.



Another option could be to just make of_i2c_register_device silent if
of_modalias_node returns -ENODEV?


Heiko


Signed-off-by: Tomeu Vizoso 
Cc: Randy Li 
Cc: Jon Hunter 
---

  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 2f814ffeb605..94f4b7eecca2 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1075,6 +1075,11 @@

};

};

};

+
+   i2c-bus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };

};

hdmi: hdmi@ff98 {



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp

[ayaka]

On 10/21/2016 04:25 PM, Heiko Stuebner wrote:

Am Donnerstag, 20. Oktober 2016, 15:47:56 CEST schrieb Tomeu Vizoso:

On 10/20/2016 03:45 PM, Heiko Stübner wrote:

Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:

Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
doesn't attemp to parse the 'ports' subnode as containing i2c devices.

This is to avoid spurious failure messages such as:

i2c i2c-6: of_i2c: modalias failure on /dp@ff97/ports

On the one hand, the edp really has an i2c bus - with its only client the
EDID listening at 0x50 (and maybe 0x30).

On the other hand, adding an empty bus to the (implementation independent)
devicetree just to make the Linux i2c subsystem happy sounds heavily like
a
implementation-specific hack, as the edp i2c bus doesn't leak into the
outside world otherwise.

I guess this empty i2c bus not being part of the binding document points
heavily into the implementation-specific corner :-) .

My short search on other patches touching this didn't reveal anything but
maybe this was already discussed somewhere and found to be ok?

Here it is:

http://www.spinics.net/lists/linux-tegra/msg27862.html

thanks ... I'm still not sure about the placeholder though, aka needing an
undocumented subnode to make a Linux error message silent.

Sorry, I report the error result, it would work.

And about the problem at this thread beginning, I found I have to use 
something like Xserver to access DRM or the panel would not be power on. 
The legacy fbdev won't help.
But there is still problem to be solved, so the eDP panel for firefly is 
not ready yet.


In the thread you pointed to I also did not see any dt-maintainer involvement
pointing one way or another, but spinics is often not easy to navigate
threads, so I may have missed that.



Another option could be to just make of_i2c_register_device silent if
of_modalias_node returns -ENODEV?


Heiko


Signed-off-by: Tomeu Vizoso 
Cc: Randy Li 
Cc: Jon Hunter 
---

  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 2f814ffeb605..94f4b7eecca2 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1075,6 +1075,11 @@

};

};

};

+
+   i2c-bus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };

};

hdmi: hdmi@ff98 {



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v9 2/2] ARM: dts: add TOPEET itop elite based board

[Ayaka]

從我的 iPad 傳送

> Krzysztof Kozlowski  於 2016年10月19日 上午1:37 寫道：
> 
>> On Wed, Oct 19, 2016 at 01:18:49AM +0800, Randy Li wrote:
>> The TOPEET itop exynos 4412 have three versions base board. The
>> Elite version is the cheap one without too much peripheral devices
>> on it.
>> 
>> Currently supported are serial console, wired networking(USB),
>> USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
>> PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
>> enabled.
>> 
>> The FIMC is not used for camera currently, I enabled it just for a
>> colorspace converter.
>> 
>> Signed-off-by: Randy Li 
>> Reviewed-by: Krzysztof Kozlowski 
> 
> Thanks, applied, with missing Rob's ack, minor changes in commit msg and
> fix in pin function (you used macro for pull up/down instead of
> function).
The last time I saw the other dts have applied that, but they are not now. A 
header file is also missed reported by kbuild, but I didn't meet that.
> 
> Best regards,
> Krzysztof

Re: [PATCH v9 2/2] ARM: dts: add TOPEET itop elite based board

[Ayaka]

從我的 iPad 傳送

> Krzysztof Kozlowski  於 2016年10月19日 上午1:37 寫道：
> 
>> On Wed, Oct 19, 2016 at 01:18:49AM +0800, Randy Li wrote:
>> The TOPEET itop exynos 4412 have three versions base board. The
>> Elite version is the cheap one without too much peripheral devices
>> on it.
>> 
>> Currently supported are serial console, wired networking(USB),
>> USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
>> PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
>> enabled.
>> 
>> The FIMC is not used for camera currently, I enabled it just for a
>> colorspace converter.
>> 
>> Signed-off-by: Randy Li 
>> Reviewed-by: Krzysztof Kozlowski 
> 
> Thanks, applied, with missing Rob's ack, minor changes in commit msg and
> fix in pin function (you used macro for pull up/down instead of
> function).
The last time I saw the other dts have applied that, but they are not now. A 
header file is also missed reported by kbuild, but I didn't meet that.
> 
> Best regards,
> Krzysztof

Re: [PATCH v8 1/2] ARM: dts: Add TOPEET itop core board SCP package version

[ayaka]

On 10/18/2016 12:27 AM, Krzysztof Kozlowski wrote:

On Mon, Sep 19, 2016 at 11:48:22PM +0800, Randy Li wrote:

The TOPEET itop is a samsung exnynos 4412 core board, which have
two package versions. This patch add the support for SCP version.

Currently supported are USB3503A HSIC, USB OTG, eMMC, rtc and
PMIC. The future features are in the based board. Also MFC and
watchdog have been enabled.

Signed-off-by: Randy Li 
---
  arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 
  1 file changed, 501 insertions(+)
  create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi

I wanted to apply it... but then I saw a bunch of checkpatch trivial issues.
Really, after v8? The code must compile (v6 did not compile...), there
should be no warnings from smatch, sparse and checkpatch (only the last
one is applicable for DTS). Unless of course checkpatch would be
wrong... but in this case it is correct. You did not follow coding
style:

WARNING: please, no spaces at the start of a line
#134: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:109:
+devfreq = <_leftbus>;$

ERROR: code indent should use tabs where possible
#135: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:110:
+status = "okay";$
Oh, it is a copy mistake, the copy operation makes the original tab 
becomes spaces.

Should I send a new version to correct them?



Best regards,
Krzysztof

Re: [PATCH v8 1/2] ARM: dts: Add TOPEET itop core board SCP package version

[ayaka]

On 10/18/2016 12:27 AM, Krzysztof Kozlowski wrote:

On Mon, Sep 19, 2016 at 11:48:22PM +0800, Randy Li wrote:

The TOPEET itop is a samsung exnynos 4412 core board, which have
two package versions. This patch add the support for SCP version.

Currently supported are USB3503A HSIC, USB OTG, eMMC, rtc and
PMIC. The future features are in the based board. Also MFC and
watchdog have been enabled.

Signed-off-by: Randy Li 
---
  arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 
  1 file changed, 501 insertions(+)
  create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi

I wanted to apply it... but then I saw a bunch of checkpatch trivial issues.
Really, after v8? The code must compile (v6 did not compile...), there
should be no warnings from smatch, sparse and checkpatch (only the last
one is applicable for DTS). Unless of course checkpatch would be
wrong... but in this case it is correct. You did not follow coding
style:

WARNING: please, no spaces at the start of a line
#134: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:109:
+devfreq = <_leftbus>;$

ERROR: code indent should use tabs where possible
#135: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:110:
+status = "okay";$
Oh, it is a copy mistake, the copy operation makes the original tab 
becomes spaces.

Should I send a new version to correct them?



Best regards,
Krzysztof

rockchip: drm: analogix_dp-rockchip would stock the kernel

[ayaka]

Hello:
   I meet a problem with eDP in rk3288 with the linux next 20161006, it 
is just like the early stage of 4.4
kernel.  I have added a eDP panel entry in the firefly reload board, 
once the kernel loaded analogix_dp-rockchip.ko, after printed the 
following two lines, the kernel stop working.
rockchip-drm display-subsystem: bound ff94.vop (ops 
vop_component_ops [rockchipdrm])
rockchip-drm display-subsystem: bound ff93.vop (ops 
vop_component_ops [rockchipdrm])
In the early June of the 4.4 kernel, I meet the same problem with rk3288 
evb board with different error message, I have to disable the display 
system that time.

  In the today test, I meet the same problem with rk3399 evb board in 4.4.
  I have no idea what caused that, and it is a little hard to debug as 
kernel still would never kill that task.

Randy Li

rockchip: drm: analogix_dp-rockchip would stock the kernel

[ayaka]

Hello:
   I meet a problem with eDP in rk3288 with the linux next 20161006, it 
is just like the early stage of 4.4
kernel.  I have added a eDP panel entry in the firefly reload board, 
once the kernel loaded analogix_dp-rockchip.ko, after printed the 
following two lines, the kernel stop working.
rockchip-drm display-subsystem: bound ff94.vop (ops 
vop_component_ops [rockchipdrm])
rockchip-drm display-subsystem: bound ff93.vop (ops 
vop_component_ops [rockchipdrm])
In the early June of the 4.4 kernel, I meet the same problem with rk3288 
evb board with different error message, I have to disable the display 
system that time.

  In the today test, I meet the same problem with rk3399 evb board in 4.4.
  I have no idea what caused that, and it is a little hard to debug as 
kernel still would never kill that task.

Randy Li

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

[ayaka]

On 09/24/2016 02:00 AM, Rob Herring wrote:

On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:

The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.

Signed-off-by: Randy Li 
---
  .../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
  drivers/gpu/drm/panel/panel-simple.c   | 27 ++
  2 files changed, 34 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt 
b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
new file mode 100644
index 000..dd22685
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa070wp03xg"

What about VCC, VLED, LED_EN (PWM), LVBIT, LVFMT, DITHER signals?

I didn't see the other simple-panel has that, so I didn't neither.
And I think it would only have VCC and LED_EN(PWM).



+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

[ayaka]

On 09/24/2016 02:00 AM, Rob Herring wrote:

On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:

The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.

Signed-off-by: Randy Li 
---
  .../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
  drivers/gpu/drm/panel/panel-simple.c   | 27 ++
  2 files changed, 34 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt 
b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
new file mode 100644
index 000..dd22685
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa070wp03xg"

What about VCC, VLED, LED_EN (PWM), LVBIT, LVFMT, DITHER signals?

I didn't see the other simple-panel has that, so I didn't neither.
And I think it would only have VCC and LED_EN(PWM).



+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.

Re: RK3288 USB Issues

[ayaka]

On 09/25/2016 04:10 AM, Norbert Lange wrote:

Hello,

did you try without your patches, to see if you can reproduce the problem?
I can fix my issues if I disable usb autosuspend

To narrow down the causes I can think of:
*) Some hardware issue only on my side -> please try to reproduce it
with an unpached kernel

Of course it does. Without those patch it won't work.

*) Some other stuff I modified -> gonna try a clean kernel with just
your patches (hopefully will find time on sunday

Of course I did that. You could check my kernel repository at github
https://github.com/hizukiayaka/linux-kernel/tree/firefly-rk3288-reload-next


*) Maybe some different kernel config options -> mine are
multi_v7_defconfig with a few modules added
Not sure with that defconfig, even I didn't know whether you enabled the 
USB module


Kind regards,
Norbert

2016-09-24 20:53 GMT+02:00 ayaka <ay...@soulik.info>:

On 09/23/2016 03:10 PM, Norbert Lange wrote:

Hi,

I wanted to reply to the Linux mailing List (your patch thread), I
dont know exactly where since the addresses are blanked out.
Just tell me where I should move this discussion.

The board can use both USB peripherals (haven`t tested the OTG Port).
The issue starts if the board has *no* USB peripherals attached
(either booting without any USB peripherals, or disconnecting all
peripherals).

I have checked my patches with kernel next-20160923, I didn't meet your
problem. The firefly RK3288 release board works fine.


*Then* I cant connect a single peripheral, just getting read errors.
I may not match your situation, there is always a usb hub at firefly 
board, unless I would remove that chip, there is always a USB peripheral 
device there.

Seems like something is getting powered down if no USB peripheral is
connected, and can`t start up again.

Kind regard,
Norbert

2016-09-23 2:48 GMT+02:00 Ayaka <ay...@soulik.info>:


從我的 iPad 傳送


Norbert Lange <nolang...@gmail.com> 於 2016年9月23日 上午7:37 寫道：

Hello Randi,
I am Randy
sorry for stalking you, but I have a problem with the USB Ports on

You have better CC to Linux-use as well

RK3288 and Heiko pointed me to your patch [1].

Firefly RK3288
Linux Kernel 4.8rc3 with multi_v7_defconfig and some additional
modules and mali drm driver
Your patch v7 applied [2]

[1] https://irclog.whitequark.org/linux-rockchip/2016-09-20
[2] https://www.spinics.net/lists/linux-usb/msg146496.html

I can easily reproduce the issue, if no USB Device is connected then
attaching USB Devices will produce Read Errors.
The only way around that is to always leave one device connected.


So the board could only connect to use one usb peripheral device?

# plug in an USB Stick
Sep 10 23:05:19 hipase2firefly kernel: usb 1-1: reset high-speed USB
device numb
Sep 10 23:05:24 hipase2firefly kernel: usb 1-1: device descriptor
read/64, error
Sep 10 23:05:40 hipase2firefly kernel: usb 1-1: device descriptor
read/64, error
Sep 10 23:05:42 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:43 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:44 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:44 hipase2firefly kernel: usb 1-1: USB disconnect, device
number 2
Sep 10 23:05:45 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:47 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:48 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:49 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:49 hipase2firefly kernel: usb usb1-port1: unable to
enumerate USB d

# reset without disconnecting USB
# connecting a second USB Device (Logitech Receiver)

Sep 10 23:03:14 hipase2firefly kernel: usb 1-1.4: new full-speed USB
device numb
Sep 10 23:03:14 hipase2firefly mtp-probe[2207]: checking bus 1, device
4: "/sys/
Sep 10 23:03:14 hipase2firefly mtp-probe[2207]: bus: 1, device: 4 was
not an MTP
Sep 10 23:03:14 hipase2firefly kernel: logitech-djreceiver
0003:046D:C52B.0003:
Sep 10 23:03:14 hipase2firefly kernel: input: Logitech K400 as
/devices/platform
Sep 10 23:03:14 hipase2firefly kernel: logitech-hidpp-device
0003:046D:4024.0004

# disconnectin 1 USB Device
Sep 10 23:04:00 hipase2firefly kernel: usb 1-1.4: USB disconnect, device
number

#reconnecting the same device
Sep 10 23:05:49 hipase2firefly kernel: usb 1-1.4: new full-speed USB
device numb
Sep 10 23:05:49 hipase2firefly kernel: logitech-djreceiver
0003:046D:C52B.0007:
Sep 10 23:05:49 hipase2firefly mtp-probe[2276]: checking bus 1, device
5: "/sys/
Sep 10 23:05:49 hipase2firefly mtp-probe[2276]: bus: 1, device: 5 was
not an MTP
Sep 10 23:05:49 hipase2firefly kernel: input: Logitech K400 as
/devices/platform
Sep 10 23:05:49 hipase2firefly kernel: logitech-hidpp-device
0003:046D:4024.0008

# disconnecting both USB Devices
Sep 10 23:06:45 hipase2firefly kernel: usb 1-1.4: USB disconnect, device
number
Sep 10 

Re: RK3288 USB Issues

[ayaka]

On 09/25/2016 04:10 AM, Norbert Lange wrote:

Hello,

did you try without your patches, to see if you can reproduce the problem?
I can fix my issues if I disable usb autosuspend

To narrow down the causes I can think of:
*) Some hardware issue only on my side -> please try to reproduce it
with an unpached kernel

Of course it does. Without those patch it won't work.

*) Some other stuff I modified -> gonna try a clean kernel with just
your patches (hopefully will find time on sunday

Of course I did that. You could check my kernel repository at github
https://github.com/hizukiayaka/linux-kernel/tree/firefly-rk3288-reload-next


*) Maybe some different kernel config options -> mine are
multi_v7_defconfig with a few modules added
Not sure with that defconfig, even I didn't know whether you enabled the 
USB module


Kind regards,
Norbert

2016-09-24 20:53 GMT+02:00 ayaka :

On 09/23/2016 03:10 PM, Norbert Lange wrote:

Hi,

I wanted to reply to the Linux mailing List (your patch thread), I
dont know exactly where since the addresses are blanked out.
Just tell me where I should move this discussion.

The board can use both USB peripherals (haven`t tested the OTG Port).
The issue starts if the board has *no* USB peripherals attached
(either booting without any USB peripherals, or disconnecting all
peripherals).

I have checked my patches with kernel next-20160923, I didn't meet your
problem. The firefly RK3288 release board works fine.


*Then* I cant connect a single peripheral, just getting read errors.
I may not match your situation, there is always a usb hub at firefly 
board, unless I would remove that chip, there is always a USB peripheral 
device there.

Seems like something is getting powered down if no USB peripheral is
connected, and can`t start up again.

Kind regard,
Norbert

2016-09-23 2:48 GMT+02:00 Ayaka :


從我的 iPad 傳送


Norbert Lange  於 2016年9月23日 上午7:37 寫道：

Hello Randi,
I am Randy
sorry for stalking you, but I have a problem with the USB Ports on

You have better CC to Linux-use as well

RK3288 and Heiko pointed me to your patch [1].

Firefly RK3288
Linux Kernel 4.8rc3 with multi_v7_defconfig and some additional
modules and mali drm driver
Your patch v7 applied [2]

[1] https://irclog.whitequark.org/linux-rockchip/2016-09-20
[2] https://www.spinics.net/lists/linux-usb/msg146496.html

I can easily reproduce the issue, if no USB Device is connected then
attaching USB Devices will produce Read Errors.
The only way around that is to always leave one device connected.


So the board could only connect to use one usb peripheral device?

# plug in an USB Stick
Sep 10 23:05:19 hipase2firefly kernel: usb 1-1: reset high-speed USB
device numb
Sep 10 23:05:24 hipase2firefly kernel: usb 1-1: device descriptor
read/64, error
Sep 10 23:05:40 hipase2firefly kernel: usb 1-1: device descriptor
read/64, error
Sep 10 23:05:42 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:43 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:44 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:44 hipase2firefly kernel: usb 1-1: USB disconnect, device
number 2
Sep 10 23:05:45 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:47 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:48 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:49 hipase2firefly kernel: usb usb1-port1: Cannot enable.
Maybe the
Sep 10 23:05:49 hipase2firefly kernel: usb usb1-port1: unable to
enumerate USB d

# reset without disconnecting USB
# connecting a second USB Device (Logitech Receiver)

Sep 10 23:03:14 hipase2firefly kernel: usb 1-1.4: new full-speed USB
device numb
Sep 10 23:03:14 hipase2firefly mtp-probe[2207]: checking bus 1, device
4: "/sys/
Sep 10 23:03:14 hipase2firefly mtp-probe[2207]: bus: 1, device: 4 was
not an MTP
Sep 10 23:03:14 hipase2firefly kernel: logitech-djreceiver
0003:046D:C52B.0003:
Sep 10 23:03:14 hipase2firefly kernel: input: Logitech K400 as
/devices/platform
Sep 10 23:03:14 hipase2firefly kernel: logitech-hidpp-device
0003:046D:4024.0004

# disconnectin 1 USB Device
Sep 10 23:04:00 hipase2firefly kernel: usb 1-1.4: USB disconnect, device
number

#reconnecting the same device
Sep 10 23:05:49 hipase2firefly kernel: usb 1-1.4: new full-speed USB
device numb
Sep 10 23:05:49 hipase2firefly kernel: logitech-djreceiver
0003:046D:C52B.0007:
Sep 10 23:05:49 hipase2firefly mtp-probe[2276]: checking bus 1, device
5: "/sys/
Sep 10 23:05:49 hipase2firefly mtp-probe[2276]: bus: 1, device: 5 was
not an MTP
Sep 10 23:05:49 hipase2firefly kernel: input: Logitech K400 as
/devices/platform
Sep 10 23:05:49 hipase2firefly kernel: logitech-hidpp-device
0003:046D:4024.0008

# disconnecting both USB Devices
Sep 10 23:06:45 hipase2firefly kernel: usb 1-1.4: USB disconnect, device
number
Sep 10 23:06:49 hipase2firefly kernel: usb 1-1.1: USB disconnect, device
num

Re: RK3288 USB Issues

[ayaka]

On 09/23/2016 03:10 PM, Norbert Lange wrote:

Hi,

I wanted to reply to the Linux mailing List (your patch thread), I
dont know exactly where since the addresses are blanked out.
Just tell me where I should move this discussion.

The board can use both USB peripherals (haven`t tested the OTG Port).
The issue starts if the board has *no* USB peripherals attached
(either booting without any USB peripherals, or disconnecting all
peripherals).
I have checked my patches with kernel next-20160923, I didn't meet your 
problem. The firefly RK3288 release board works fine.

*Then* I cant connect a single peripheral, just getting read errors.

Seems like something is getting powered down if no USB peripheral is
connected, and can`t start up again.

Kind regard,
Norbert

2016-09-23 2:48 GMT+02:00 Ayaka <ay...@soulik.info>:


從我的 iPad 傳送


Norbert Lange <nolang...@gmail.com> 於 2016年9月23日 上午7:37 寫道：

Hello Randi,
I am Randy
sorry for stalking you, but I have a problem with the USB Ports on

You have better CC to Linux-use as well

RK3288 and Heiko pointed me to your patch [1].

Firefly RK3288
Linux Kernel 4.8rc3 with multi_v7_defconfig and some additional
modules and mali drm driver
Your patch v7 applied [2]

[1] https://irclog.whitequark.org/linux-rockchip/2016-09-20
[2] https://www.spinics.net/lists/linux-usb/msg146496.html

I can easily reproduce the issue, if no USB Device is connected then
attaching USB Devices will produce Read Errors.
The only way around that is to always leave one device connected.


So the board could only connect to use one usb peripheral device?

# plug in an USB Stick
Sep 10 23:05:19 hipase2firefly kernel: usb 1-1: reset high-speed USB device numb
Sep 10 23:05:24 hipase2firefly kernel: usb 1-1: device descriptor read/64, error
Sep 10 23:05:40 hipase2firefly kernel: usb 1-1: device descriptor read/64, error
Sep 10 23:05:42 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:43 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:44 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:44 hipase2firefly kernel: usb 1-1: USB disconnect, device number 2
Sep 10 23:05:45 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:47 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:48 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:49 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:49 hipase2firefly kernel: usb usb1-port1: unable to enumerate USB d

# reset without disconnecting USB
# connecting a second USB Device (Logitech Receiver)

Sep 10 23:03:14 hipase2firefly kernel: usb 1-1.4: new full-speed USB device numb
Sep 10 23:03:14 hipase2firefly mtp-probe[2207]: checking bus 1, device 4: "/sys/
Sep 10 23:03:14 hipase2firefly mtp-probe[2207]: bus: 1, device: 4 was not an MTP
Sep 10 23:03:14 hipase2firefly kernel: logitech-djreceiver 0003:046D:C52B.0003:
Sep 10 23:03:14 hipase2firefly kernel: input: Logitech K400 as /devices/platform
Sep 10 23:03:14 hipase2firefly kernel: logitech-hidpp-device 0003:046D:4024.0004

# disconnectin 1 USB Device
Sep 10 23:04:00 hipase2firefly kernel: usb 1-1.4: USB disconnect, device number

#reconnecting the same device
Sep 10 23:05:49 hipase2firefly kernel: usb 1-1.4: new full-speed USB device numb
Sep 10 23:05:49 hipase2firefly kernel: logitech-djreceiver 0003:046D:C52B.0007:
Sep 10 23:05:49 hipase2firefly mtp-probe[2276]: checking bus 1, device 5: "/sys/
Sep 10 23:05:49 hipase2firefly mtp-probe[2276]: bus: 1, device: 5 was not an MTP
Sep 10 23:05:49 hipase2firefly kernel: input: Logitech K400 as /devices/platform
Sep 10 23:05:49 hipase2firefly kernel: logitech-hidpp-device 0003:046D:4024.0008

# disconnecting both USB Devices
Sep 10 23:06:45 hipase2firefly kernel: usb 1-1.4: USB disconnect, device number
Sep 10 23:06:49 hipase2firefly kernel: usb 1-1.1: USB disconnect, device number
Sep 10 23:06:49 hipase2firefly systemd-udevd[2339]:
inotify_add_watch(9, /dev/sdb, 10) failed: No such file or directory

# reconnecting the Logitech Receiver
Sep 10 23:08:40 hipase2firefly kernel: usb 1-1: reset high-speed USB
device number 2 using dwc2
Sep 10 23:08:46 hipase2firefly kernel: usb 1-1: device descriptor
read/64, error -110
Sep 10 23:09:01 hipase2firefly kernel: usb 1-1: device descriptor
read/64, error -110
Sep 10 23:09:03 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:04 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:05 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:05 hipase2firefly kernel: usb 1-1: USB disconnect, device number 2
Sep 10 23:09:07 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:08 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:09 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:11

Re: RK3288 USB Issues

[ayaka]

On 09/23/2016 03:10 PM, Norbert Lange wrote:

Hi,

I wanted to reply to the Linux mailing List (your patch thread), I
dont know exactly where since the addresses are blanked out.
Just tell me where I should move this discussion.

The board can use both USB peripherals (haven`t tested the OTG Port).
The issue starts if the board has *no* USB peripherals attached
(either booting without any USB peripherals, or disconnecting all
peripherals).
I have checked my patches with kernel next-20160923, I didn't meet your 
problem. The firefly RK3288 release board works fine.

*Then* I cant connect a single peripheral, just getting read errors.

Seems like something is getting powered down if no USB peripheral is
connected, and can`t start up again.

Kind regard,
Norbert

2016-09-23 2:48 GMT+02:00 Ayaka :


從我的 iPad 傳送


Norbert Lange  於 2016年9月23日 上午7:37 寫道：

Hello Randi,
I am Randy
sorry for stalking you, but I have a problem with the USB Ports on

You have better CC to Linux-use as well

RK3288 and Heiko pointed me to your patch [1].

Firefly RK3288
Linux Kernel 4.8rc3 with multi_v7_defconfig and some additional
modules and mali drm driver
Your patch v7 applied [2]

[1] https://irclog.whitequark.org/linux-rockchip/2016-09-20
[2] https://www.spinics.net/lists/linux-usb/msg146496.html

I can easily reproduce the issue, if no USB Device is connected then
attaching USB Devices will produce Read Errors.
The only way around that is to always leave one device connected.


So the board could only connect to use one usb peripheral device?

# plug in an USB Stick
Sep 10 23:05:19 hipase2firefly kernel: usb 1-1: reset high-speed USB device numb
Sep 10 23:05:24 hipase2firefly kernel: usb 1-1: device descriptor read/64, error
Sep 10 23:05:40 hipase2firefly kernel: usb 1-1: device descriptor read/64, error
Sep 10 23:05:42 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:43 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:44 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:44 hipase2firefly kernel: usb 1-1: USB disconnect, device number 2
Sep 10 23:05:45 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:47 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:48 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:49 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:05:49 hipase2firefly kernel: usb usb1-port1: unable to enumerate USB d

# reset without disconnecting USB
# connecting a second USB Device (Logitech Receiver)

Sep 10 23:03:14 hipase2firefly kernel: usb 1-1.4: new full-speed USB device numb
Sep 10 23:03:14 hipase2firefly mtp-probe[2207]: checking bus 1, device 4: "/sys/
Sep 10 23:03:14 hipase2firefly mtp-probe[2207]: bus: 1, device: 4 was not an MTP
Sep 10 23:03:14 hipase2firefly kernel: logitech-djreceiver 0003:046D:C52B.0003:
Sep 10 23:03:14 hipase2firefly kernel: input: Logitech K400 as /devices/platform
Sep 10 23:03:14 hipase2firefly kernel: logitech-hidpp-device 0003:046D:4024.0004

# disconnectin 1 USB Device
Sep 10 23:04:00 hipase2firefly kernel: usb 1-1.4: USB disconnect, device number

#reconnecting the same device
Sep 10 23:05:49 hipase2firefly kernel: usb 1-1.4: new full-speed USB device numb
Sep 10 23:05:49 hipase2firefly kernel: logitech-djreceiver 0003:046D:C52B.0007:
Sep 10 23:05:49 hipase2firefly mtp-probe[2276]: checking bus 1, device 5: "/sys/
Sep 10 23:05:49 hipase2firefly mtp-probe[2276]: bus: 1, device: 5 was not an MTP
Sep 10 23:05:49 hipase2firefly kernel: input: Logitech K400 as /devices/platform
Sep 10 23:05:49 hipase2firefly kernel: logitech-hidpp-device 0003:046D:4024.0008

# disconnecting both USB Devices
Sep 10 23:06:45 hipase2firefly kernel: usb 1-1.4: USB disconnect, device number
Sep 10 23:06:49 hipase2firefly kernel: usb 1-1.1: USB disconnect, device number
Sep 10 23:06:49 hipase2firefly systemd-udevd[2339]:
inotify_add_watch(9, /dev/sdb, 10) failed: No such file or directory

# reconnecting the Logitech Receiver
Sep 10 23:08:40 hipase2firefly kernel: usb 1-1: reset high-speed USB
device number 2 using dwc2
Sep 10 23:08:46 hipase2firefly kernel: usb 1-1: device descriptor
read/64, error -110
Sep 10 23:09:01 hipase2firefly kernel: usb 1-1: device descriptor
read/64, error -110
Sep 10 23:09:03 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:04 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:05 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:05 hipase2firefly kernel: usb 1-1: USB disconnect, device number 2
Sep 10 23:09:07 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:08 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:09 hipase2firefly kernel: usb usb1-port1: Cannot enable. Maybe the
Sep 10 23:09:11 hipase2firefly kernel: usb usb1-port1: Cannot ena

Re: [RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite

[ayaka]

On 09/20/2016 03:12 AM, Fabio Estevam wrote:

On Mon, Sep 19, 2016 at 4:02 PM, Randy Li  wrote:


+   vcc_sys_lcd: sys-lcd {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;

Is this really active high? If so, you should add the
'enable-active-high' property.
I see, thank you. Btw, let me make it clearly, it is really an 
independentTransistor, not be controlled by PMIC.

Re: [RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite

[ayaka]

On 09/20/2016 03:12 AM, Fabio Estevam wrote:

On Mon, Sep 19, 2016 at 4:02 PM, Randy Li  wrote:


+   vcc_sys_lcd: sys-lcd {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;

Is this really active high? If so, you should add the
'enable-active-high' property.
I see, thank you. Btw, let me make it clearly, it is really an 
independentTransistor, not be controlled by PMIC.

Re: [PATCH] ASoC: samsung: make audio interface/controller explicitly

[Ayaka]

從我的 iPad 傳送

> Mark Brown  於 2016年9月19日 下午4:33 寫道：
> 
>> On Sun, Sep 18, 2016 at 10:09:11PM +0800, Randy Li wrote:
>> 
>> It is simple sound card time, we could assign different codec
>> to a interface without making a specific driver for it.
> 
>> config SND_SAMSUNG_AC97
>> -tristate
>> +tristate "Samsung AC97 controller support"
>>select SND_SOC_AC97_BUS
> 
> Are you *sure* simple-card works for AC'97?
Not sure. I could hardly find a AC97 device in embedded market. If it didn't I 
could disable it. I have only tested simple sound card for i2s and SPDIF.

Re: [PATCH] ASoC: samsung: make audio interface/controller explicitly

[Ayaka]

從我的 iPad 傳送

> Mark Brown  於 2016年9月19日 下午4:33 寫道：
> 
>> On Sun, Sep 18, 2016 at 10:09:11PM +0800, Randy Li wrote:
>> 
>> It is simple sound card time, we could assign different codec
>> to a interface without making a specific driver for it.
> 
>> config SND_SAMSUNG_AC97
>> -tristate
>> +tristate "Samsung AC97 controller support"
>>select SND_SOC_AC97_BUS
> 
> Are you *sure* simple-card works for AC'97?
Not sure. I could hardly find a AC97 device in embedded market. If it didn't I 
could disable it. I have only tested simple sound card for i2s and SPDIF.

Re: [PATCH] ASoC: samsung: make audio interface/controller explicitly

[Ayaka]

從我的 iPad 傳送

> Krzysztof Kozlowski <k...@kernel.org> 於 2016年9月19日 上午2:09 寫道：
> 
>> On Sun, Sep 18, 2016 at 11:12:34PM +0800, ayaka wrote:
>> 
>> 
>>> On 09/18/2016 10:42 PM, Krzysztof Kozlowski wrote:
>>>> On Sun, Sep 18, 2016 at 10:09:11PM +0800, Randy Li wrote:
>>>> It is simple sound card time, we could assign different codec
>>>> to a interface without making a specific driver for it.
>>> The description does not convince me and I do not see an example using
>>> this. Could you provide one?
>> Sorry, the board TOPEET iTop 4412 for exynos 4412 I posted supported codec
>> with I2S interface using the simple sound card. Anyway, it is no harm to
>> make them explicitly right?
> 
> kbuild gave you the answer...
Not sure how comes, even time I sent patches to you, I at lease build and run 
it once.
> 
>> Or I have to enabled those codec support for
>> SMDK, which is not needed for the other board.
> 
> If I understand correctly, the i2s/pcm etc are still needed but not
> built in config choosing only simple-audio-card? I tried now such
> configuration on Odroid XU and indeed the audio is missing.
> 
> The patch looks like needed but:
> 1. You need to describe the rationale in commit message, why it is
> needed.
Sorry about English.
> 2. You need to fix it... kbuild pointed build issues.
I would check that.
> 
> Other solution would be to add a user-selectable option for generic
> sound on Samsung using simple audio card. The option would then select
> appropriate SND_SAMSUNG* options, just like specific drivers do. I see
> that sh does like this. Personally this approach seems simpler to me -
> the defconfig could just choose this generic sound instead of many
> SND_SAMSUNG_* sub-options.
I would just what  Freescale did. It included those options entries in a 
sub-menu.
I don't those options should be bound either, as a board may only use one of 
interface or controller(like TOPEET iTOP would only use i2s. No place for 
SPDIF, AC97 nor PCM.)
> 
> Best regards,
> Krzysztof
> 
>>> 
>>> Best regards,
>>> Krzysztof
>>> 
>>> 
>>>> Signed-off-by: Randy Li <ay...@soulik.info>
>>>> ---
>>>> sound/soc/samsung/Kconfig | 8 
>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>> 
>>>> diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
>>>> index 7b722b0..b7b3a38 100644
>>>> --- a/sound/soc/samsung/Kconfig
>>>> +++ b/sound/soc/samsung/Kconfig
>>>> @@ -18,18 +18,18 @@ config SND_S3C2412_SOC_I2S
>>>>select SND_S3C_I2SV2_SOC
>>>> config SND_SAMSUNG_PCM
>>>> -tristate
>>>> +tristate "Samsung PCM interface support"
>>>> config SND_SAMSUNG_AC97
>>>> -tristate
>>>> +tristate "Samsung AC97 controller support"
>>>>select SND_SOC_AC97_BUS
>>>> config SND_SAMSUNG_SPDIF
>>>> -tristate
>>>> +tristate "Samsung SPDIF transmitter support"
>>>>select SND_SOC_SPDIF
>>>> config SND_SAMSUNG_I2S
>>>> -tristate
>>>> +tristate "Samsung I2S interface support"
>>>> config SND_SOC_SAMSUNG_NEO1973_WM8753
>>>>tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
>>>> -- 
>>>> 2.7.4
>> 

Re: [PATCH] ASoC: samsung: make audio interface/controller explicitly

[Ayaka]

從我的 iPad 傳送

> Krzysztof Kozlowski  於 2016年9月19日 上午2:09 寫道：
> 
>> On Sun, Sep 18, 2016 at 11:12:34PM +0800, ayaka wrote:
>> 
>> 
>>> On 09/18/2016 10:42 PM, Krzysztof Kozlowski wrote:
>>>> On Sun, Sep 18, 2016 at 10:09:11PM +0800, Randy Li wrote:
>>>> It is simple sound card time, we could assign different codec
>>>> to a interface without making a specific driver for it.
>>> The description does not convince me and I do not see an example using
>>> this. Could you provide one?
>> Sorry, the board TOPEET iTop 4412 for exynos 4412 I posted supported codec
>> with I2S interface using the simple sound card. Anyway, it is no harm to
>> make them explicitly right?
> 
> kbuild gave you the answer...
Not sure how comes, even time I sent patches to you, I at lease build and run 
it once.
> 
>> Or I have to enabled those codec support for
>> SMDK, which is not needed for the other board.
> 
> If I understand correctly, the i2s/pcm etc are still needed but not
> built in config choosing only simple-audio-card? I tried now such
> configuration on Odroid XU and indeed the audio is missing.
> 
> The patch looks like needed but:
> 1. You need to describe the rationale in commit message, why it is
> needed.
Sorry about English.
> 2. You need to fix it... kbuild pointed build issues.
I would check that.
> 
> Other solution would be to add a user-selectable option for generic
> sound on Samsung using simple audio card. The option would then select
> appropriate SND_SAMSUNG* options, just like specific drivers do. I see
> that sh does like this. Personally this approach seems simpler to me -
> the defconfig could just choose this generic sound instead of many
> SND_SAMSUNG_* sub-options.
I would just what  Freescale did. It included those options entries in a 
sub-menu.
I don't those options should be bound either, as a board may only use one of 
interface or controller(like TOPEET iTOP would only use i2s. No place for 
SPDIF, AC97 nor PCM.)
> 
> Best regards,
> Krzysztof
> 
>>> 
>>> Best regards,
>>> Krzysztof
>>> 
>>> 
>>>> Signed-off-by: Randy Li 
>>>> ---
>>>> sound/soc/samsung/Kconfig | 8 
>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>> 
>>>> diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
>>>> index 7b722b0..b7b3a38 100644
>>>> --- a/sound/soc/samsung/Kconfig
>>>> +++ b/sound/soc/samsung/Kconfig
>>>> @@ -18,18 +18,18 @@ config SND_S3C2412_SOC_I2S
>>>>select SND_S3C_I2SV2_SOC
>>>> config SND_SAMSUNG_PCM
>>>> -tristate
>>>> +tristate "Samsung PCM interface support"
>>>> config SND_SAMSUNG_AC97
>>>> -tristate
>>>> +tristate "Samsung AC97 controller support"
>>>>select SND_SOC_AC97_BUS
>>>> config SND_SAMSUNG_SPDIF
>>>> -tristate
>>>> +tristate "Samsung SPDIF transmitter support"
>>>>select SND_SOC_SPDIF
>>>> config SND_SAMSUNG_I2S
>>>> -tristate
>>>> +tristate "Samsung I2S interface support"
>>>> config SND_SOC_SAMSUNG_NEO1973_WM8753
>>>>tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
>>>> -- 
>>>> 2.7.4
>> 

Re: [PATCH] ASoC: samsung: make audio interface/controller explicitly

[ayaka]

On 09/18/2016 10:42 PM, Krzysztof Kozlowski wrote:

On Sun, Sep 18, 2016 at 10:09:11PM +0800, Randy Li wrote:

It is simple sound card time, we could assign different codec
to a interface without making a specific driver for it.

The description does not convince me and I do not see an example using
this. Could you provide one?
Sorry, the board TOPEET iTop 4412 for exynos 4412 I posted supported 
codec with I2S interface using the simple sound card. Anyway, it is no 
harm to make them explicitly right? Or I have to enabled those codec 
support for SMDK, which is not needed for the other board.


Best regards,
Krzysztof



Signed-off-by: Randy Li 
---
  sound/soc/samsung/Kconfig | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 7b722b0..b7b3a38 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -18,18 +18,18 @@ config SND_S3C2412_SOC_I2S
select SND_S3C_I2SV2_SOC
  
  config SND_SAMSUNG_PCM

-   tristate
+   tristate "Samsung PCM interface support"
  
  config SND_SAMSUNG_AC97

-   tristate
+   tristate "Samsung AC97 controller support"
select SND_SOC_AC97_BUS
  
  config SND_SAMSUNG_SPDIF

-   tristate
+   tristate "Samsung SPDIF transmitter support"
select SND_SOC_SPDIF
  
  config SND_SAMSUNG_I2S

-   tristate
+   tristate "Samsung I2S interface support"
  
  config SND_SOC_SAMSUNG_NEO1973_WM8753

tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
--
2.7.4

Re: [PATCH] ASoC: samsung: make audio interface/controller explicitly

[ayaka]

On 09/18/2016 10:42 PM, Krzysztof Kozlowski wrote:

On Sun, Sep 18, 2016 at 10:09:11PM +0800, Randy Li wrote:

It is simple sound card time, we could assign different codec
to a interface without making a specific driver for it.

The description does not convince me and I do not see an example using
this. Could you provide one?
Sorry, the board TOPEET iTop 4412 for exynos 4412 I posted supported 
codec with I2S interface using the simple sound card. Anyway, it is no 
harm to make them explicitly right? Or I have to enabled those codec 
support for SMDK, which is not needed for the other board.


Best regards,
Krzysztof



Signed-off-by: Randy Li 
---
  sound/soc/samsung/Kconfig | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 7b722b0..b7b3a38 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -18,18 +18,18 @@ config SND_S3C2412_SOC_I2S
select SND_S3C_I2SV2_SOC
  
  config SND_SAMSUNG_PCM

-   tristate
+   tristate "Samsung PCM interface support"
  
  config SND_SAMSUNG_AC97

-   tristate
+   tristate "Samsung AC97 controller support"
select SND_SOC_AC97_BUS
  
  config SND_SAMSUNG_SPDIF

-   tristate
+   tristate "Samsung SPDIF transmitter support"
select SND_SOC_SPDIF
  
  config SND_SAMSUNG_I2S

-   tristate
+   tristate "Samsung I2S interface support"
  
  config SND_SOC_SAMSUNG_NEO1973_WM8753

tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
--
2.7.4

Re: [PATCH v6 2/3] ARM: dts: add TOPEET itop elite based board

[ayaka]

On 09/17/2016 02:09 AM, Javier Martinez Canillas wrote:

Hello Randy,

On 09/16/2016 01:21 PM, Krzysztof Kozlowski wrote:

[snip]


+   
+   beep {
+   compatible = "pwm-beeper";
+   pwms = < 0 400 PWM_POLARITY_INVERTED>;

I have serious doubts that you run this code... if it does not even
compile. Sorry, I cannot accept code that does not compile and was not
tested.

Please, test your DTS on top of current Linux tree, which would be one of:
1. Linus' master branch: v4.8-rc6,
2. one of my branches (for-next, next/dt etc),

When I sent those patches, I tested in "Add linux-next specific files for
20160907"

OK, good, but please tell me why kbuild reported that build error?


I agree with Krzysztof, it doesn't seem that you tested the exact version

I am sure I does.

that was posted. You will need the following change to make the DTS build
in latest linux-next:
I didn't post the patch is WIP, which would adding the LCD panel support 
to this board.


diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index dd83689892ff..8559f891a740 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -14,6 +14,7 @@
  */
  
  /dts-v1/;

+#include 
  #include 
  #include "exynos4412-itop-scp-core.dtsi"

So please squash that change and resend.
I would, but I meet a problem in memory with the latest next-20160916, 
it seems that it can't access the memory while it never happened before.
MMC read: dev # 1, block # 2048, count 14336 ...14336 blocks read: 
OK [58/426]

Boot with zImage

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0xa00
[0.00] Linux version 4.8.0-rc6-next-20160916-4-gae92137 
(ayaka@ritsuko) (gcc version 6.1.0 (Buildroot 2016.05-6-g0

792d0d-dirty) ) #83 SMP PREEMPT Sun Sep 18 17:29:56 CST 2016
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), 
cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt:Machine model: TOPEET iTop 4412 Elite board based 
on Exynos4412

[0.00] bootconsole [earlycon0] enabled
[0.00] OF: reserved mem: failed to allocate memory for node 
'region_mfc_right'
[0.00] OF: reserved mem: failed to allocate memory for node 
'region_mfc_left'

[0.00] cma: Failed to reserve 32 MiB
[0.00] Memory policy: Data cache writealloc
[0.00] Kernel panic - not syncing: ERROR: Failed to allocate 
0x2000 bytes below 0x0.

[0.00]
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.8.0-rc6-next-20160916-4-gae92137 #83

[0.00] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[0.00] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from [] 
(dump_stack+0x70/0x8c)
[0.00] [] (dump_stack) from [] 
(panic+0xc4/0x244)
[0.00] [] (panic) from [] 
(memblock_alloc_base+0x2c/0x38)
[0.00] [] (memblock_alloc_base) from [] 
(early_alloc_aligned+0xc/0x2c)
[0.00] [] (early_alloc_aligned) from [] 
(paging_init+0x548/0xa70)
[0.00] [] (paging_init) from [] 
(setup_arch+0x50c/0xa28)
[0.00] [] (setup_arch) from [] 
(start_kernel+0x50/0x384)

[0.00] [] (start_kernel) from [<4000807c>] (0x4000807c)
[0.00] ---[ end Kernel panic - not syncing: ERROR: Failed to 
allocate 0x2000 bytes below 0x0.

[0.00



Best regards,

Re: [PATCH v6 2/3] ARM: dts: add TOPEET itop elite based board

[ayaka]

On 09/17/2016 02:09 AM, Javier Martinez Canillas wrote:

Hello Randy,

On 09/16/2016 01:21 PM, Krzysztof Kozlowski wrote:

[snip]


+   
+   beep {
+   compatible = "pwm-beeper";
+   pwms = < 0 400 PWM_POLARITY_INVERTED>;

I have serious doubts that you run this code... if it does not even
compile. Sorry, I cannot accept code that does not compile and was not
tested.

Please, test your DTS on top of current Linux tree, which would be one of:
1. Linus' master branch: v4.8-rc6,
2. one of my branches (for-next, next/dt etc),

When I sent those patches, I tested in "Add linux-next specific files for
20160907"

OK, good, but please tell me why kbuild reported that build error?


I agree with Krzysztof, it doesn't seem that you tested the exact version

I am sure I does.

that was posted. You will need the following change to make the DTS build
in latest linux-next:
I didn't post the patch is WIP, which would adding the LCD panel support 
to this board.


diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index dd83689892ff..8559f891a740 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -14,6 +14,7 @@
  */
  
  /dts-v1/;

+#include 
  #include 
  #include "exynos4412-itop-scp-core.dtsi"

So please squash that change and resend.
I would, but I meet a problem in memory with the latest next-20160916, 
it seems that it can't access the memory while it never happened before.
MMC read: dev # 1, block # 2048, count 14336 ...14336 blocks read: 
OK [58/426]

Boot with zImage

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0xa00
[0.00] Linux version 4.8.0-rc6-next-20160916-4-gae92137 
(ayaka@ritsuko) (gcc version 6.1.0 (Buildroot 2016.05-6-g0

792d0d-dirty) ) #83 SMP PREEMPT Sun Sep 18 17:29:56 CST 2016
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), 
cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt:Machine model: TOPEET iTop 4412 Elite board based 
on Exynos4412

[0.00] bootconsole [earlycon0] enabled
[0.00] OF: reserved mem: failed to allocate memory for node 
'region_mfc_right'
[0.00] OF: reserved mem: failed to allocate memory for node 
'region_mfc_left'

[0.00] cma: Failed to reserve 32 MiB
[0.00] Memory policy: Data cache writealloc
[0.00] Kernel panic - not syncing: ERROR: Failed to allocate 
0x2000 bytes below 0x0.

[0.00]
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.8.0-rc6-next-20160916-4-gae92137 #83

[0.00] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[0.00] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from [] 
(dump_stack+0x70/0x8c)
[0.00] [] (dump_stack) from [] 
(panic+0xc4/0x244)
[0.00] [] (panic) from [] 
(memblock_alloc_base+0x2c/0x38)
[0.00] [] (memblock_alloc_base) from [] 
(early_alloc_aligned+0xc/0x2c)
[0.00] [] (early_alloc_aligned) from [] 
(paging_init+0x548/0xa70)
[0.00] [] (paging_init) from [] 
(setup_arch+0x50c/0xa28)
[0.00] [] (setup_arch) from [] 
(start_kernel+0x50/0x384)

[0.00] [] (start_kernel) from [<4000807c>] (0x4000807c)
[0.00] ---[ end Kernel panic - not syncing: ERROR: Failed to 
allocate 0x2000 bytes below 0x0.

[0.00



Best regards,