Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine

[ayaka]

Sorry, the previous one contains html data.

> On Aug 2, 2022, at 3:33 PM, Tomasz Figa  wrote:
> 
> On Mon, Aug 1, 2022 at 8:43 PM ayaka  wrote:
>> Sent from my iPad
>>>> On Aug 1, 2022, at 5:46 PM, Tomasz Figa  wrote:
>>> CAUTION: Email originated externally, do not click links or open 
>>> attachments unless you recognize the sender and know the content is safe.
>>>> On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li  wrote:
>>>>> On 8/1/22 14:19, Tomasz Figa wrote:
>>>> Hello Tomasz
>>>>> ?Hi Randy,
>>>>> On Mon, Aug 1, 2022 at 5:21 AM  wrote:
>>>>>> From: Randy Li 
>>>>>> This module is still at a early stage, I wrote this for showing what
>>>>>> APIs we need here.
>>>>>> Let me explain why we need such a module here.
>>>>>> If you won't allocate buffers from a V4L2 M2M device, this module
>>>>>> may not be very useful. I am sure the most of users won't know a
>>>>>> device would require them allocate buffers from a DMA-Heap then
>>>>>> import those buffers into a V4L2's queue.
>>>>>> Then the question goes back to why DMA-Heap. From the Android's
>>>>>> description, we know it is about the copyright's DRM.
>>>>>> When we allocate a buffer in a DMA-Heap, it may register that buffer
>>>>>> in the trusted execution environment so the firmware which is running
>>>>>> or could only be acccesed from there could use that buffer later.
>>>>>> The answer above leads to another thing which is not done in this
>>>>>> version, the DMA mapping. Although in some platforms, a DMA-Heap
>>>>>> responses a IOMMU device as well. For the genernal purpose, we would
>>>>>> be better assuming the device mapping should be done for each device
>>>>>> itself. The problem here we only know alloc_devs in those DMAbuf
>>>>>> methods, which are DMA-heaps in my design, the device from the queue
>>>>>> is not enough, a plane may requests another IOMMU device or table
>>>>>> for mapping.
>>>>>> Signed-off-by: Randy Li 
>>>>>> ---
>>>>>> drivers/media/common/videobuf2/Kconfig|   6 +
>>>>>> drivers/media/common/videobuf2/Makefile   |   1 +
>>>>>> .../common/videobuf2/videobuf2-dma-heap.c | 350 ++
>>>>>> include/media/videobuf2-dma-heap.h|  30 ++
>>>>>> 4 files changed, 387 insertions(+)
>>>>>> create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c
>>>>>> create mode 100644 include/media/videobuf2-dma-heap.h
>>>>> First of all, thanks for the series.
>>>>> Possibly a stupid question, but why not just allocate the DMA-bufs
>>>>> directly from the DMA-buf heap device in the userspace and just import
>>>>> the buffers to the V4L2 device using V4L2_MEMORY_DMABUF?
>>>> Sometimes the allocation policy could be very complex, let's suppose a
>>>> multiple planes pixel format enabling with frame buffer compression.
>>>> Its luma, chroma data could be allocated from a pool which is delegated
>>>> for large buffers while its metadata would come from a pool which many
>>>> users could take some few slices from it(likes system pool).
>>>> Then when we have a new users knowing nothing about this platform, if we
>>>> just configure the alloc_devs in each queues well. The user won't need
>>>> to know those complex rules.
>>>> The real situation could be more complex, Samsung MFC's left and right
>>>> banks could be regarded as two pools, many devices would benefit from
>>>> this either from the allocation times or the security buffers policy.
>>>> In our design, when we need to do some security decoding(DRM video),
>>>> codecs2 would allocate buffers from the pool delegated for that. While
>>>> the non-DRM video, users could not care about this.
>>> I'm a little bit surprised about this, because on Android all the
>>> graphics buffers are allocated from the system IAllocator and imported
>>> to the specific devices.
>> In the non-tunnel mode, yes it is. While the tunnel mode is completely 
>> vendor defined. Neither HWC nor codec2 cares about where the buffers coming 
>> from, you could do what ever you want.
>> Besides there are DRM video in GNU Linux platform, I heard the webkit 

Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine

[ayaka]

Sent from my iPad

> On Aug 2, 2022, at 3:33 PM, Tomasz Figa  wrote:
> 
> On Mon, Aug 1, 2022 at 8:43 PM ayaka  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>>> On Aug 1, 2022, at 5:46 PM, Tomasz Figa  wrote:
>>> 
>>> CAUTION: Email originated externally, do not click links or open 
>>> attachments unless you recognize the sender and know the content is safe.
>>> 
>>> 
>>>> On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li  wrote:
>>>>> On 8/1/22 14:19, Tomasz Figa wrote:
>>>> Hello Tomasz
>>>>> ?Hi Randy,
>>>>> On Mon, Aug 1, 2022 at 5:21 AM  wrote:
>>>>>> From: Randy Li 
>>>>>> This module is still at a early stage, I wrote this for showing what
>>>>>> APIs we need here.
>>>>>> Let me explain why we need such a module here.
>>>>>> If you won't allocate buffers from a V4L2 M2M device, this module
>>>>>> may not be very useful. I am sure the most of users won't know a
>>>>>> device would require them allocate buffers from a DMA-Heap then
>>>>>> import those buffers into a V4L2's queue.
>>>>>> Then the question goes back to why DMA-Heap. From the Android's
>>>>>> description, we know it is about the copyright's DRM.
>>>>>> When we allocate a buffer in a DMA-Heap, it may register that buffer
>>>>>> in the trusted execution environment so the firmware which is running
>>>>>> or could only be acccesed from there could use that buffer later.
>>>>>> The answer above leads to another thing which is not done in this
>>>>>> version, the DMA mapping. Although in some platforms, a DMA-Heap
>>>>>> responses a IOMMU device as well. For the genernal purpose, we would
>>>>>> be better assuming the device mapping should be done for each device
>>>>>> itself. The problem here we only know alloc_devs in those DMAbuf
>>>>>> methods, which are DMA-heaps in my design, the device from the queue
>>>>>> is not enough, a plane may requests another IOMMU device or table
>>>>>> for mapping.
>>>>>> Signed-off-by: Randy Li 
>>>>>> ---
>>>>>> drivers/media/common/videobuf2/Kconfig|   6 +
>>>>>> drivers/media/common/videobuf2/Makefile   |   1 +
>>>>>> .../common/videobuf2/videobuf2-dma-heap.c | 350 ++
>>>>>> include/media/videobuf2-dma-heap.h|  30 ++
>>>>>> 4 files changed, 387 insertions(+)
>>>>>> create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c
>>>>>> create mode 100644 include/media/videobuf2-dma-heap.h
>>>>> First of all, thanks for the series.
>>>>> Possibly a stupid question, but why not just allocate the DMA-bufs
>>>>> directly from the DMA-buf heap device in the userspace and just import
>>>>> the buffers to the V4L2 device using V4L2_MEMORY_DMABUF?
>>>> Sometimes the allocation policy could be very complex, let's suppose a
>>>> multiple planes pixel format enabling with frame buffer compression.
>>>> Its luma, chroma data could be allocated from a pool which is delegated
>>>> for large buffers while its metadata would come from a pool which many
>>>> users could take some few slices from it(likes system pool).
>>>> Then when we have a new users knowing nothing about this platform, if we
>>>> just configure the alloc_devs in each queues well. The user won't need
>>>> to know those complex rules.
>>>> The real situation could be more complex, Samsung MFC's left and right
>>>> banks could be regarded as two pools, many devices would benefit from
>>>> this either from the allocation times or the security buffers policy.
>>>> In our design, when we need to do some security decoding(DRM video),
>>>> codecs2 would allocate buffers from the pool delegated for that. While
>>>> the non-DRM video, users could not care about this.
>>> 
>>> I'm a little bit surprised about this, because on Android all the
>>> graphics buffers are allocated from the system IAllocator and imported
>>> to the specific devices.
>> In the non-tunnel mode, yes it is. While the tunnel mode is completely 
>> vendor defined. Neither HWC nor codec2 cares about where the buffers coming 
>> from, you could do what ever you want.
>> 

Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine

[ayaka]

Sent from my iPad

> On Aug 1, 2022, at 5:46 PM, Tomasz Figa  wrote:
> 
> CAUTION: Email originated externally, do not click links or open attachments 
> unless you recognize the sender and know the content is safe.
> 
> 
>> On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li  wrote:
>> 
>> 
>> 
>>> On 8/1/22 14:19, Tomasz Figa wrote:
>>> 
>> Hello Tomasz
>>> 
>>> ?Hi Randy,
>>> 
>>> On Mon, Aug 1, 2022 at 5:21 AM  wrote:
 
 From: Randy Li 
 
 This module is still at a early stage, I wrote this for showing what
 APIs we need here.
 
 Let me explain why we need such a module here.
 If you won't allocate buffers from a V4L2 M2M device, this module
 may not be very useful. I am sure the most of users won't know a
 device would require them allocate buffers from a DMA-Heap then
 import those buffers into a V4L2's queue.
 
 Then the question goes back to why DMA-Heap. From the Android's
 description, we know it is about the copyright's DRM.
 When we allocate a buffer in a DMA-Heap, it may register that buffer
 in the trusted execution environment so the firmware which is running
 or could only be acccesed from there could use that buffer later.
 
 The answer above leads to another thing which is not done in this
 version, the DMA mapping. Although in some platforms, a DMA-Heap
 responses a IOMMU device as well. For the genernal purpose, we would
 be better assuming the device mapping should be done for each device
 itself. The problem here we only know alloc_devs in those DMAbuf
 methods, which are DMA-heaps in my design, the device from the queue
 is not enough, a plane may requests another IOMMU device or table
 for mapping.
 
 Signed-off-by: Randy Li 
 ---
  drivers/media/common/videobuf2/Kconfig|   6 +
  drivers/media/common/videobuf2/Makefile   |   1 +
  .../common/videobuf2/videobuf2-dma-heap.c | 350 ++
  include/media/videobuf2-dma-heap.h|  30 ++
  4 files changed, 387 insertions(+)
  create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c
  create mode 100644 include/media/videobuf2-dma-heap.h
 
>>> 
>>> First of all, thanks for the series.
>>> 
>>> Possibly a stupid question, but why not just allocate the DMA-bufs
>>> directly from the DMA-buf heap device in the userspace and just import
>>> the buffers to the V4L2 device using V4L2_MEMORY_DMABUF?
>> Sometimes the allocation policy could be very complex, let's suppose a
>> multiple planes pixel format enabling with frame buffer compression.
>> Its luma, chroma data could be allocated from a pool which is delegated
>> for large buffers while its metadata would come from a pool which many
>> users could take some few slices from it(likes system pool).
>> 
>> Then when we have a new users knowing nothing about this platform, if we
>> just configure the alloc_devs in each queues well. The user won't need
>> to know those complex rules.
>> 
>> The real situation could be more complex, Samsung MFC's left and right
>> banks could be regarded as two pools, many devices would benefit from
>> this either from the allocation times or the security buffers policy.
>> 
>> In our design, when we need to do some security decoding(DRM video),
>> codecs2 would allocate buffers from the pool delegated for that. While
>> the non-DRM video, users could not care about this.
> 
> I'm a little bit surprised about this, because on Android all the
> graphics buffers are allocated from the system IAllocator and imported
> to the specific devices.
> 
In the non-tunnel mode, yes it is. While the tunnel mode is completely vendor 
defined. Neither HWC nor codec2 cares about where the buffers coming from, you 
could do what ever you want.

Besides there are DRM video in GNU Linux platform, I heard the webkit has made 
huge effort here and Playready is one could work in non-Android Linux.
> Would it make sense to instead extend the UAPI to expose enough
> information about the allocation requirements to the userspace, so it
> can allocate correctly?
Yes, it could. But as I said it would need the users to do more works.
> My reasoning here is that it's not a driver's decision to allocate
> from a DMA-buf heap (and which one) or not. It's the userspace which
> knows that, based on the specific use case that it wants to fulfill.
> 
Although I would like to let the users decide that, users just can’t do that 
which would violate the security rules in some platforms.
For example,  video codec and display device could only access a region of 
memory, any other device or trusted apps can’t access it. Users have to 
allocate the buffer from the pool the vendor decided.

So why not we offer a quick way that users don’t need to try and error.
> Also, FWIW, dma_heap_ioctl_allocate() is a static function not exposed
> to other kernel modules:
> 

Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine

[ayaka]



Sent from my iPad

> On Aug 1, 2022, at 5:46 PM, Tomasz Figa  wrote:
> 
> CAUTION: Email originated externally, do not click links or open attachments 
> unless you recognize the sender and know the content is safe.
> 
> 
>> On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li  wrote:
>>> On 8/1/22 14:19, Tomasz Figa wrote:
>> Hello Tomasz
>>> ?Hi Randy,
>>> On Mon, Aug 1, 2022 at 5:21 AM  wrote:
 From: Randy Li 
 This module is still at a early stage, I wrote this for showing what
 APIs we need here.
 Let me explain why we need such a module here.
 If you won't allocate buffers from a V4L2 M2M device, this module
 may not be very useful. I am sure the most of users won't know a
 device would require them allocate buffers from a DMA-Heap then
 import those buffers into a V4L2's queue.
 Then the question goes back to why DMA-Heap. From the Android's
 description, we know it is about the copyright's DRM.
 When we allocate a buffer in a DMA-Heap, it may register that buffer
 in the trusted execution environment so the firmware which is running
 or could only be acccesed from there could use that buffer later.
 The answer above leads to another thing which is not done in this
 version, the DMA mapping. Although in some platforms, a DMA-Heap
 responses a IOMMU device as well. For the genernal purpose, we would
 be better assuming the device mapping should be done for each device
 itself. The problem here we only know alloc_devs in those DMAbuf
 methods, which are DMA-heaps in my design, the device from the queue
 is not enough, a plane may requests another IOMMU device or table
 for mapping.
 Signed-off-by: Randy Li 
 ---
 drivers/media/common/videobuf2/Kconfig|   6 +
 drivers/media/common/videobuf2/Makefile   |   1 +
 .../common/videobuf2/videobuf2-dma-heap.c | 350 ++
 include/media/videobuf2-dma-heap.h|  30 ++
 4 files changed, 387 insertions(+)
 create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c
 create mode 100644 include/media/videobuf2-dma-heap.h
>>> First of all, thanks for the series.
>>> Possibly a stupid question, but why not just allocate the DMA-bufs
>>> directly from the DMA-buf heap device in the userspace and just import
>>> the buffers to the V4L2 device using V4L2_MEMORY_DMABUF?
>> Sometimes the allocation policy could be very complex, let's suppose a
>> multiple planes pixel format enabling with frame buffer compression.
>> Its luma, chroma data could be allocated from a pool which is delegated
>> for large buffers while its metadata would come from a pool which many
>> users could take some few slices from it(likes system pool).
>> Then when we have a new users knowing nothing about this platform, if we
>> just configure the alloc_devs in each queues well. The user won't need
>> to know those complex rules.
>> The real situation could be more complex, Samsung MFC's left and right
>> banks could be regarded as two pools, many devices would benefit from
>> this either from the allocation times or the security buffers policy.
>> In our design, when we need to do some security decoding(DRM video),
>> codecs2 would allocate buffers from the pool delegated for that. While
>> the non-DRM video, users could not care about this.
> 
> I'm a little bit surprised about this, because on Android all the
> graphics buffers are allocated from the system IAllocator and imported
> to the specific devices.
In the non-tunnel mode, yes it is. While the tunnel mode is completely vendor 
defined. Neither HWC nor codec2 cares about where the buffers coming from, you 
could do what ever you want.

Besides there are DRM video in GNU Linux platform, I heard the webkit has made 
huge effort here and Playready is one could work in non-Android Linux.
> Would it make sense to instead extend the UAPI to expose enough
> information about the allocation requirements to the userspace, so it
> can allocate correctly?
Yes, it could. But as I said it would need the users to do more works.
> My reasoning here is that it's not a driver's decision to allocate
> from a DMA-buf heap (and which one) or not. It's the userspace which
> knows that, based on the specific use case that it wants to fulfill.
Although I would like to let the users decide that, users just can’t do that 
which would violate the security rules in some platforms.
For example,  video codec and display device could only access a region of 
memory, any other device or trusted apps can’t access it. Users have to 
allocate the buffer from the pool the vendor decided.

So why not we offer a quick way that users don’t need to try and error.
> Also, FWIW, dma_heap_ioctl_allocate() is a static function not exposed
> to other kernel modules:
> 

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

[ayaka]

On 10/12/2017 07:56 PM, Tapani Pälli wrote:
Is this one going to land soon? The discussion was a bit hard to read 
but it looks like in the end consensus was that everything looks good 
in this patch.

I am very sorry, I am too busy with  the other dma problem in rockchip.
The main problem is that none of the driver have used those format. 
Although the rockchip vop supports 10 bit pixel format but not the p010.


Thanks;


On 03/01/2017 01:21 AM, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.

P016 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments

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..762646d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@
  #define DRM_FORMAT_NV42    fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */

    /*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010    fourcc_code('P', '0', '1', '0') /* 
2x2 subsampled Cr:Cb plane 10 bits per channel */

+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012    fourcc_code('P', '0', '1', '2') /* 
2x2 subsampled Cr:Cb plane 12 bits per channel */

+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
+ */
+#define DRM_FORMAT_P016    fourcc_code('P', '0', '1', '6') /* 
2x2 subsampled Cr:Cb plane 16 bits per channel */

+
+/*
   * 3 plane YCbCr
   * index 0: Y plane, [7:0] Y
   * index 1: Cb plane, [7:0] Cb



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

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 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 傳送

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

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

___
dri-devel mailing list
dri-devel@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ä  於 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

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

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

[ayaka]

On 02/28/2017 06:57 AM, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.

P016 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format

Cc: Daniel Stone 
Cc: Ville Syrjälä 

Signed-off-by: Randy Li 
Signed-off-by: Clint Taylor 
---
  drivers/gpu/drm/drm_fourcc.c  |4 
  include/uapi/drm/drm_fourcc.h |   21 +
  2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..5494764 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,10 @@ 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 */

  You may remove this line, I misunderstand the P010 that time.
What I want is adding a new pixel format never be defined before, may it 
should be called P010_PACK

or something else.

+   { .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 @@
  #define DRM_FORMAT_NV42   fourcc_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


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

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

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

Re: Request API: stateless VPU: the buffer mechanism and DPB management

[ayaka]

On 01/17/2017 10:59 PM, Nicolas Dufresne wrote:

Le mardi 17 janvier 2017 à 20:46 +0800, herman.c...@rock-chips.com a
écrit :

If we move parser or part of DPB management mechanism into kernel we
will face a issue as follows:
One customer requires dpb management do a flush when stream occurs in
order to keep output frame clean.
While another one requires output frame with error to keep output
frame smooth.
And when only one field has a error one customer wants to do a simple
field copy to recover.

The driver should send all frames and simply mark the corrupted frames
using V4L2_BUF_FLAG_ERROR. This way, the userspace can then make their
own decision. It is also important to keep track and cleanup the
buffers meta's (which are application specific). If the driver silently
drops frame, it makes that management much harder.

About flushing and draining operation, they are respectively signalled
to the driver using STREAMOFF and CMD_STOP.


These are some operation related to strategy rather then mechanism.
I think it is not a good idea to bring such kind of flexible process
to kernel driver.

So here is the ultimate challenge that how to reasonably move the
parser and flexible process
which is encapsuled in firmware to a userspace - kernel stateless
driver model.

Moving the parsers in the kernel (on the main CPU) is not acceptable.
No, what is not what I said. What I want to do is "The whole plan in 
userspace is just injecting a parsing operation and set those v4l2 
control in kernel before enqueue a buffer into OUTPUT, which would keep 
the most compatible with those stateful video IP(those with a firmware). "

This is too much of a security threat. Userspace should parse the data
into structures, doing any validation required before end.

My main question and that should have an impact decision, is if those
structures can be made generic. PDB handling is not that trivial (my
reference is VAAPI here, maybe they are doing it wrong) and with driver
specific structures, we would have this code copy-pasted over and over.
So with driver specific structures, it's probably better to keep all
the parsing and reordering logic outside (hence together).

The result to keep DPB and re-order inside the kernel is want
to be compatible with the original buffer operation.
Anyway the DPB structure could be common.


That remains, that some driver will deal with reordering on the
firmware side (even the if they don't parse), hence we need to take
this into consideration.

No sure what do you mean, I think all those driver with firmware
would do that.


regards,
Nicolas


Hello all:
  I have recently finish the learning of the H.264 codec and ready to 
write the driver. Although I have not get deep in syntax of H.264 but I 
think I just need to reuse and extended the VA-API H264 Parser from 
gstreamer. The whole plan in userspace is just injecting a parsing 
operation and set those v4l2 control in kernel before enqueue a buffer 
into OUTPUT, which would keep the most compatible with those stateful 
video IP(those with a firmware).
  But in order to do that, I can't avoid the management of DPB. I 
decided to moving the DPB management job from userspace in kernel. Also 
the video IP(On2 on rk3288 and the transition video IP on those future 
SoC than rk3288, rkv don't have this problem) would a special way to 
manage the DPB, which requests the same reference frame is storing in 
the same reference index in the runtime(actually it is its Motion Vector 
data appended in decoded YUV data would not be moved). I would suggest 
to keep those job in kernel, the userspace just to need update the list0 
and list1 of DPB. DPB is self managed in kernel the userspace don't need 
to even dequeue the buffer from CAPTURE until the re-order is done.
  The kernel driver would also re-order the CAPTURE buffer into display 
order, and blocking the operation on CAPTURE until a buffer is ready to 
place in the very display order. If I don't do that, I have to get the 
buffer once it is decoded, and marking its result with the poc, I could 
only begin the processing of the next frame only after those thing are 
done. Which would effect the performance badly. That is what chromebook 
did(I hear that from the other staff, I didn't get invoke in chromium 
project yet). So I would suggest that doing the re-order job in kernel, 
and inform the the userspace the buffers are ready when the new I 
frame(key frame) is pushed into the video IP.
  Although moving those job into kernel would increase the loading, but 
I think it is worth to do that, but I don't know whether all those 
thought are correct and high performance(It is more important than API 
compatible especially for those 4K video). And I want to know more ideas 
about this topic.
  I would begin the writing the new driver after the coming culture new 
year vacation(I would go to the Europe), I wish we can decide the final 
mechanism before I begin this job.

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!

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

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

[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

[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_NV61fourcc_code('N', 'V', '6', '1') /* 2x1 
>> subsampled Cb:Cr plane */
>>   #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /* 
>> non-subsampled Cr:Cb plane */
>>   #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
>> non-subsampled Cb:Cr plane */
>> +#define DRM_FORMAT_P010 fourcc_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-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

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

[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

[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

[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);
>>>
>>
>>
>

[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);
>>>
>>
>>
>

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

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

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

[PATCH RFC] ARM: dts: samsung: add rga-lvds panel in itop elite

[Ayaka]

從我的 iPad 傳送
Thank you
> Andrzej Hajda  於 2016年9月1日 下午3:04 
> 寫道：
> 
>> On 08/31/2016 07:55 PM, ayaka wrote:
>> 
>>> On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
>>> Hi,
>>> 
>>> 
>>>> On 08/30/2016 12:50 AM, Randy Li wrote:
>>>> It is actually a lvds panel connected through a rga-lvds bridge.
>>>> But I really have no idea about what does a port mean in fimd node.
>>>> 
>>>> Also how should I configure this panel size? I think the i2c found
>>>> on the panel schematic, but it more likely to be used a touch screen
>>>> touth. Also the touch screen is not supported in currently driver.
>>>> 
>>>> Signed-off-by: Randy Li 
>>>> ---
>>>>  arch/arm/boot/dts/exynos4412-itop-elite.dts | 35 
>>>> ++---
>>>>  1 file changed, 32 insertions(+), 3 deletions(-)
>>>> 
>>>> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
>>>> b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>>> index e1cda54..2d67385 100644
>>>> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>>> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>>> @@ -139,6 +139,20 @@
>>>>  assigned-clocks = < CLK_MOUT_CAM0>;
>>>>  assigned-clock-parents = < CLK_XUSBXTI>;
>>>>  };
>>>> +
>>>> +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>;
>>>> +};
>>>> +
>>>> +panel: panel {
>>>> +ddc-i2c-bus = <_3>;
>>>> +power-supply = <_sys_lcd>;
>>>> +enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
>>>> +};
>>> Panel has no compatible string, which driver will handle this node?
>> The problem is that, it is panel not supported by kernel. 
> 
> For simple panel you can take a look at [1][2]. Ie. if the panel needs
> only power supply and enable gpio, you just need to add few lines to [2].
But I still don't know which compatible string I should use, "simple-dpi" ?
> 
> 
> [1]: Documentation/devicetree/bindings/display/panel/simple-panel.txt
> [2]: drivers/gpu/drm/panel/panel-simple.c
> 
>> Is it possible 
>> to support without adding a new driver for it ? I know there is a 
>> simple-dpi for MIPI, but what is for parallel video or lvds?
> 
> simple-dpi is just parallel output. LVDS is not supported by Exynos4412 but
> boards usually have RGB/LVDS bridge for such panels, I have no access to
> itop
> board schematics, but I suppose it has such bridge. LVDS bridges often
> do not
> need Linux driver, so from developer point of view LVDS panels with such
> bridge
Yes it is.
> are handled the same way as RGB panels. Example fimd bindings for RGB panels
> are in [3].
> 
> [3]: arch/arm/boot/dts/exynos4210-universal_c210.dts
> 
Would it appear as a frame buffer device in Linux ? Regard of display timings, 
I could solve it later. If the frame buffer node is created, I could know I 
have a way to test.
>>> Regards
>>> Andrzej
>> The other problem is that I don't how to configure the display-times, 
>> the datasheet for CLAA070WP03XG only talk about total time, active time 
>> and blank time for both Horizontal an Vertical time. Does it mean the 
>> front-porch and sync-len for horizontal and vertical are zero ?
> 
> You can look at vendor's code.
It is a very old kernel. But it seems that they didn't configure the fimd but 
the frame buffer.
> Or just experiment with different values.
> The equation is: total=active+back_porch+blank+front_porch.
> So if htotal=864, hactive=800, hblank=64, then hporches are 0.
> In case of vtotal=1288, vactive=1200, vblank=8 you have left 80 for porches,
> you can try to split them equally for front and back for starters.
But timings diagram in data sheet doesn't look like that, I have asked the 
vendor for some help, I hope I could get a reply from the vendor.
> 
> Regards
> Andrzej
> 
>> 
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   port at 3 {
>> +   reg = <3>;
>> +   rga_lvds: endpoint {
>> +

[PATCH RFC] ARM: dts: samsung: add rga-lvds panel in itop elite

[ayaka]

On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
> Hi,
>
>
> On 08/30/2016 12:50 AM, Randy Li wrote:
>> It is actually a lvds panel connected through a rga-lvds bridge.
>> But I really have no idea about what does a port mean in fimd node.
>>
>> Also how should I configure this panel size? I think the i2c found
>> on the panel schematic, but it more likely to be used a touch screen
>> touth. Also the touch screen is not supported in currently driver.
>>
>> Signed-off-by: Randy Li 
>> ---
>>   arch/arm/boot/dts/exynos4412-itop-elite.dts | 35 
>> ++---
>>   1 file changed, 32 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
>> b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>> index e1cda54..2d67385 100644
>> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
>> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>> @@ -139,6 +139,20 @@
>>  assigned-clocks = < CLK_MOUT_CAM0>;
>>  assigned-clock-parents = < CLK_XUSBXTI>;
>>  };
>> +
>> +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>;
>> +};
>> +
>> +panel: panel {
>> +ddc-i2c-bus = <_3>;
>> +power-supply = <_sys_lcd>;
>> +enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
>> +};
> Panel has no compatible string, which driver will handle this node?
The problem is that, it is panel not supported by kernel. Is it possible 
to support without adding a new driver for it ? I know there is a 
simple-dpi for MIPI, but what is for parallel video or lvds?
> Regards
> Andrzej
The other problem is that I don't how to configure the display-times, 
the datasheet for CLAA070WP03XG only talk about total time, active time 
and blank time for both Horizontal an Vertical time. Does it mean the 
front-porch and sync-len for horizontal and vertical are zero ?

+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 3 {
+   reg = <3>;
+   rga_lvds: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
+
+   panel: panel at 0 {
+   compatible = "panel-simple";
+
+   power-supply = <_sys_lcd>;
+   enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   display-timings {
+   timing-0 {
+   clock-frequency = <6677>;
+   hactive = <800>;
+   vactive = <1280>;
+   hfront-porch = <0>;
+   hback-porch = <64>;
+   hsync-len = <0>;
+   vfront-porch = <0>;
+   vback-porch = <8>;
+   vsync-len = <0>;
+   };
+  };

[PATCH RFC] ARM: dts: samsung: add rga-lvds panel in itop elite

[ayaka]

On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
> Hi,
>
>
> On 08/30/2016 12:50 AM, Randy Li wrote:
>> It is actually a lvds panel connected through a rga-lvds bridge.
>> But I really have no idea about what does a port mean in fimd node.
>>
>> Also how should I configure this panel size? I think the i2c found
>> on the panel schematic, but it more likely to be used a touch screen
>> touth. Also the touch screen is not supported in currently driver.
>>
>> Signed-off-by: Randy Li 
>> ---
>>   arch/arm/boot/dts/exynos4412-itop-elite.dts | 35 
>> ++---
>>   1 file changed, 32 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
>> b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>> index e1cda54..2d67385 100644
>> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
>> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>> @@ -139,6 +139,20 @@
>>  assigned-clocks = < CLK_MOUT_CAM0>;
>>  assigned-clock-parents = < CLK_XUSBXTI>;
>>  };
>> +
>> +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>;
>> +};
>> +
>> +panel: panel {
>> +ddc-i2c-bus = <_3>;
>> +power-supply = <_sys_lcd>;
>> +enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
>> +};
> Panel has no compatible string, which driver will handle this node?
The problem is that, it is panel not supported by kernel. Is it possible 
to support without adding a new driver for it ? I know there is a 
simple-dpi for MIPI, but what is for parallel video or lvds?
> Regards
> Andrzej
The other problem is that I don't how to configure the display-times, 
the datasheet for CLAA070WP03XG should talk about total time, active 
time and blank time for both Horizontal an Vertical time. Does it mean 
the front-porch and sync-len for horizontal and vertical are zero ?

+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 3 {
+   reg = <3>;
+   rga_lvds: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
+
+   panel: panel at 0 {
+   compatible = "panel-simple";
+
+   power-supply = <_sys_lcd>;
+   enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   display-timings {
+   timing-0 {
+   clock-frequency = <6677>;
+   hactive = <800>;
+   vactive = <1280>;
+   hfront-porch = <0>;
+   hback-porch = <64>;
+   hsync-len = <0>;
+   vfront-porch = <0>;
+   vback-porch = <8>;
+   vsync-len = <0>;
+   };