Allocation Constraints
Hello emersion Since you told me the presentation in XDC 2020, I was thinking what we need for the video codec hardware, I don't have much experience with the situation that presentation addressed, sharing between GPU. I think we must cover the case with and without IOMMU attached to the device, besides some page layout information. I would talk it later. About the pitch(in v4l2, it is bytesperline, or stride in some hardware), I think it would indicate three types, one is the menu(a menu of N choices), one is integer(ranging from minimum to maximum inclusive). The menu type could cover the most of cases with a fixed cache line(likes 16, 64, 256 bytes alignment). While the integer type covers those do no care about cache line, the restriction is about hardware desired size, codec hardware could hardly meet this, usually they need to meet the requirement of CU or MB from a codec. This also enables the padding for vertical direction which could be regarded as the padding bytes behinds a plane. Still it can ___not _ describe the case happening in Rockchip vdpu34x for HEVC and VP9, which requests an odd cache line. For example, if the width is 256 (8bit depth) and cache line is 256 bytes as well, the pitch would be 256 bytes, when width becomes 512, the pitch should be 768 bytes. You could learn this from Rockchip MPP rkv_hor_align*(); In study 2, Local memory, codec has the similar requirement but difference. Is it GPU internal having different regions for 2d texture, 3d texture and shader? The non-cache or cached memory (coherence) is also cared by codec sometimes, while the most cases the user could decide that by whether CPU need to access that buffer. While, the constraint need to tell its capability about whether it supports accessing an secure buffer. Let's back the IOMMU topic, this feature is not mandatory for the codec. And we would like to get rid of M variant pixel formats from V4L2. For the hardware doesn't support scatter list, it may have delegated registers for each plane. address type: scatter list or one address relationship with the previous plane: compact(right after the last byte of the previous plane), new page(plane would start in the beginning of a page), or None(it has a delegated register) page size: this only applied for sgl address type, hardware may need a larger contiguous page. To make a summary what I think we need here: 1. Alignment requirement for vertical direction 2. whether the device supports scatter list 3. what is the page size if the device would support iommu 4. plane layout in memory Sincerely Randy Li
[PATCH v7 1/2] drm/fourcc: Add Synaptics VideoSmart tiled modifiers
From: "Hsia-Jun(Randy) Li"
Those modifiers only record the parameters would effort pixel
layout or memory layout. Whether physical memory page mapping
is used is not a part of format.
Signed-off-by: Hsia-Jun(Randy) Li
---
include/uapi/drm/drm_fourcc.h | 75 +++
1 file changed, 75 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index de703c6be969..ee13250f06f4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -419,6 +419,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
+#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b
/* add more to the end as needed */
@@ -1519,6 +1520,80 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
#define AMD_FMT_MOD_CLEAR(field) \
(~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
+/*
+ * Synaptics VideoSmart modifiers
+ *
+ * Tiles could be arranged in Groups of Tiles (GOTs), it is a small tile
+ * within a tile. GOT size and layout varies based on platform and
+ * performance concern. When the compression is applied, it is possible
+ * that we would have two tile type in the GOT, these parameters can't
+ * tell the secondary tile type.
+ *
+ * Besides, an 8 size 4 bytes arrary (32 bytes) would be need to store
+ * some compression parameters for a compression meta data plane.
+ *
+ * Macro
+ * Bits Param Description
+ * -
-
+ *
+ * 7:0 f Scan direction description.
+ *
+ * 0 = Invalid
+ * 1 = V4, the scan would always start from vertical for 4 pixel
+ * then move back to the start pixel of the next horizontal
+ * direction.
+ * 2 = Reserved for future use.
+ *
+ * 15:8 m The times of pattern repeat in the right angle direction from
+ * the first scan direction.
+ *
+ * 19:16 p The padding bits after the whole scan, could be zero.
+ *
+ * 20:20 g GOT packing flag.
+ *
+ * 23:21 - Reserved for future use. Must be zero.
+ *
+ * 27:24 h log2(horizontal) of bytes, in GOTs.
+ *
+ * 31:28 v log2(vertical) of bytes, in GOTs.
+ *
+ * 35:32 - Reserved for future use. Must be zero.
+ *
+ * 36:36 c Compression flag.
+ *
+ * 55:37 - Reserved for future use. Must be zero.
+ *
+ */
+
+#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1)
+
+#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, g, h, v, c) \
+ fourcc_mod_code(SYNAPTICS, ((__u64)((f) & 0xff) | \
+((__u64)((m) & 0xff) << 8) | \
+((__u64)((p) & 0xf) << 16) | \
+((__u64)((g) & 0x1) << 20) | \
+((__u64)((h) & 0xf) << 24) | \
+((__u64)((v) & 0xf) << 28) | \
+((__u64)((c) & 0x1) << 36)))
+
+#define DRM_FORMAT_MOD_SYNA_V4H1 \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0, 0, 0, 0)
+
+#define DRM_FORMAT_MOD_SYNA_V4H3P8 \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0, 0, 0, 0)
+
+#define DRM_FORMAT_MOD_SYNA_V4H1_64L4_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1, 6, 2, 1)
+
+#define DRM_FORMAT_MOD_SYNA_V4H3P8_64L4_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1, 6, 2, 1)
+
+#define DRM_FORMAT_MOD_SYNA_V4H1_128L128_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1, 7, 7, 1)
+
+#define DRM_FORMAT_MOD_SYNA_V4H3P8_128L128_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1, 7, 7, 1)
+
#if defined(__cplusplus)
}
#endif
--
2.39.2
[PATCH v7 0/2] Add pixel formats used in Synatpics SoC
Those pixel formats are used in Synaptics's VideoSmart series SoCs, likes VS640, VS680. I just disclose the pixel formats used in the video codecs and display pipeline this time. Actually any device connected to the MTR module could support those tiling and compressed pixel formats. https://synaptics.com/products/multimedia-solutions Changelog: v7: Fixed all warnings and errors for its document. Add its document to GPU tree. v6: Refresh and fix warnings in its document. v5: Moving back the document and rewriting the description. v4: Removed the patches for V4L2, V4L2 would use the drm_fourcc.h . Moving the documents to the mesa project. v3: There was a mistake in format macro. Correcting the description of 64L4 variant modifiers. v2: The DRM modifiers in the first draft is too simple, it can't tell the tiles in group attribute in memory layout. Removing the v4l2 fourcc. Adding a document for the future v4l2 extended fmt. v1: first draft of DRM modifiers Try to put basic tile formats into v4l2 fourcc Hsia-Jun(Randy) Li (1): drm/fourcc: Add Synaptics VideoSmart tiled modifiers Randy Li (1): Documentation/gpu: Add Synaptics tiling formats documentation Documentation/gpu/drivers.rst | 1 + Documentation/gpu/synaptics.rst | 81 + include/uapi/drm/drm_fourcc.h | 75 ++ 3 files changed, 157 insertions(+) create mode 100644 Documentation/gpu/synaptics.rst -- 2.39.2
[PATCH v7 2/2] Documentation/gpu: Add Synaptics tiling formats documentation
Signed-off-by: Randy Li Signed-off-by: Hsia-Jun(Randy) Li --- Documentation/gpu/drivers.rst | 1 + Documentation/gpu/synaptics.rst | 81 + 2 files changed, 82 insertions(+) create mode 100644 Documentation/gpu/synaptics.rst diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index 3a52f48215a3..7e820c93d994 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -18,6 +18,7 @@ GPU Driver Documentation xen-front afbc komeda-kms + synaptics .. only:: subproject and html diff --git a/Documentation/gpu/synaptics.rst b/Documentation/gpu/synaptics.rst new file mode 100644 index ..a3b24c297186 --- /dev/null +++ b/Documentation/gpu/synaptics.rst @@ -0,0 +1,81 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later + + +Synaptics Tiling + + +The tiling pixel formats in Synpatics Video Smart platform have +many variants. Tiles could form the group of tiles, pixels within +the group (nearest) width and height are stored into tile. +Meanwhile, the tile in a group may not follow dimension layout, +tile could form a small group of tiles, then that (sub)group +of tiles would form a bigger group. We won't describe the dimension +layout inside the group of tiles here. The layout of the group +of tiles is fixed with the group width and height parameters +in the same generation of the platform. + +Compression +=== +The proprietary lossless image compression protocol in Synaptics +could minimizes the amount of data transferred (less memory bandwidth +consumption) between devices. It would usually apply to the tiling +pixel format. + +Each component would request an extra page aligned length buffer +for storing the compression meta data. Also a 32 bytes parameters +set would come with a compression meta data buffer. + +The component here corresponds to a signal type (i.e. Luma, chroma). +They could be encoded into one or multiple metadata planes, but +their compression parameters still would be individual. + +Pixel format modifiers +== +Addition alignment requirement for stride and size of a memory plane +could apply beyond what has been mentioned below. Remember always +negotiating with all the devices in pipeline before allocation. + +.. flat-table:: Synpatics Image Format Modifiers + + * - Identifier +- Fourcc +- Details + + * - DRM_FORMAT_MOD_SYNA_V4H1 +- DRM_FORMAT_NV12 +- The plain uncompressed 8 bits tile format. It sounds similar to + Intel's Y-tile. but it won't take any pixel from the next X direction + in a tile group. The line stride and image height must be aligned to + a multiple of 16. The height of chrominance plane would plus 8. + + * - DRM_FORMAT_MOD_SYNA_V4H3P8 +- DRM_FORMAT_NV15 +- The plain uncompressed 10 bits tile format. It stores pixel in 2D + 3x4 tiles with a 8bits padding to each of tile. Then a tile is in a + 128 bits cache line. + + * - DRM_FORMAT_MOD_SYNA_V4H1_64L4_COMPRESSED +- DRM_FORMAT_NV12 +- Group of tiles and compressed variant of ``DRM_FORMAT_MOD_SYNA_V4H1``. + A group of tiles would contain 64x4 pixels, where a tile has 1x4 + pixel. + + * - DRM_FORMAT_MOD_SYNA_V4H3P8_64L4_COMPRESSED +- DRM_FORMAT_NV15 +- Group of tiles and compressed variant of ``DRM_FORMAT_MOD_SYNA_V4H3P8``. + A group of tiles would contains 48x4 pixels, where a tile has 3x4 pixels + and a 8 bits padding in the end of a tile. A group of tiles would + be 256 bytes. + + * - ``DRM_FORMAT_MOD_SYNA_V4H1_128L128_COMPRESSED`` +- DRM_FORMAT_NV12 +- Group of tiles and compressed variant of ``DRM_FORMAT_MOD_SYNA_V4H1``. + A group of tiles would contain 128x32 pixels, where a tile has 1x4 + pixel. + + * - ``DRM_FORMAT_MOD_SYNA_V4H3P8_128L128_COMPRESSED`` +- DRM_FORMAT_NV15 +- Group of tiles and compressed variant of ``DRM_FORMAT_MOD_SYNA_V4H3P8``. + A group of tiles would contains 96x128 pixels, where a tile has 3x4 pixels + and a 8 bits padding in the end of a tile. A group of tiles would + be 16 KiB. -- 2.39.2
Re: [PATCH v5 1/2] drm/fourcc: Add Synaptics VideoSmart tiled modifiers
Sent from my iPad
> On Dec 1, 2022, at 5:39 PM, Daniel Vetter wrote:
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
>> On Thu, Dec 01, 2022 at 12:49:16AM +0800, Randy Li wrote:
>>
>>
>> Sent from my iPad
>>
>>>> On Nov 30, 2022, at 7:30 PM, Daniel Vetter wrote:
>>> CAUTION: Email originated externally, do not click links or open
>>> attachments unless you recognize the sender and know the content is safe.
>>>> On Wed, Nov 30, 2022 at 05:21:48PM +0800, Hsia-Jun Li wrote:
>>>> From: "Hsia-Jun(Randy) Li"
>>>> Those modifiers only record the parameters would effort pixel
>>>> layout or memory layout. Whether physical memory page mapping
>>>> is used is not a part of format.
>>>> Signed-off-by: Hsia-Jun(Randy) Li
>>>> ---
>>>> include/uapi/drm/drm_fourcc.h | 76 +++
>>>> 1 file changed, 76 insertions(+)
>>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>>>> index bc056f2d537d..e0905f573f43 100644
>>>> --- a/include/uapi/drm/drm_fourcc.h
>>>> +++ b/include/uapi/drm/drm_fourcc.h
>>>> @@ -407,6 +407,7 @@ extern "C" {
>>>> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
>>>> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
>>>> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
>>>> +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b
>>>> /* add more to the end as needed */
>>>> @@ -1507,6 +1508,81 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
>>>> modifier)
>>>> #define AMD_FMT_MOD_CLEAR(field) \
>>>> (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
>>>> +/*
>>>> + * Synaptics VideoSmart modifiers
>>>> + *
>>>> + * Tiles could be arranged in Groups of Tiles (GOTs), it is a small tile
>>>> + * within a tile. GOT size and layout varies based on platform and
>>>> + * performance concern.
>>>> + *
>>>> + * Besides, an 8 length 4 bytes arrary (32 bytes) would be need to store
>>>> + * some compression parameters for a compression metadata plane.
>>>> + *
>>>> + * Further information can be found in
>>>> + * Documentation/gpu/synaptics.rst
>>>> + *
>>>> + * Macro
>>>> + * Bits Param Description
>>>> + * -
>>>> -
>>>> + *
>>>> + * 7:0 f Scan direction description.
>>>> + *
>>>> + * 0 = Invalid
>>>> + * 1 = V4, the scan would always start from vertical for 4
>>>> pixel
>>>> + * then move back to the start pixel of the next
>>>> horizontal
>>>> + * direction.
>>>> + * 2 = Reserved for future use.
>>>> + *
>>>> + * 15:8 m The times of pattern repeat in the right angle direction
>>>> from
>>>> + * the first scan direction.
>>>> + *
>>>> + * 19:16 p The padding bits after the whole scan, could be zero.
>>>> + *
>>>> + * 20:20 g GOT packing flag.
>>>> + *
>>>> + * 23:21 - Reserved for future use. Must be zero.
>>> Can you pls fold all the future use reservations into the top end?
>> You see we could put more related flag in each of reserved area.
>> Here is for the group of tiles flag.
>> Bit 35 to 32 could be used for describing the dimension of the group of
>> tiles.
>
> Oh also on the dimension thing, this is the tile size and has nothing to
> do with the overall buffer size, right?
I don’t think you could have a insufficient tile, that applies to the group of
tile.
> Because the overall buffer size is
> meant to be carried in separate metadata (like the drm_framebuffer
> structure or ADDFB2 ioctl data). drm fourcc/modifier assume that height,
> width, offset and stride are specified per plane already (unless the
> auxiary plane has a fixed layout and is not tracked as a separate plane
> for this format).
One thing I noticed here, there is no way to tell the buffer size that user
should request/allocate from the drm API. It needs to be calculated in the
userspace unless you would use the custom ioctl.
>
>>> Also I
>>> think it'd be good to at le
Re: [PATCH v5 1/2] drm/fourcc: Add Synaptics VideoSmart tiled modifiers
Sent from my iPad
> On Nov 30, 2022, at 7:30 PM, Daniel Vetter wrote:
>
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
>> On Wed, Nov 30, 2022 at 05:21:48PM +0800, Hsia-Jun Li wrote:
>> From: "Hsia-Jun(Randy) Li"
>>
>> Those modifiers only record the parameters would effort pixel
>> layout or memory layout. Whether physical memory page mapping
>> is used is not a part of format.
>>
>> Signed-off-by: Hsia-Jun(Randy) Li
>> ---
>> include/uapi/drm/drm_fourcc.h | 76 +++
>> 1 file changed, 76 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index bc056f2d537d..e0905f573f43 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -407,6 +407,7 @@ extern "C" {
>> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
>> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
>> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
>> +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b
>>
>> /* add more to the end as needed */
>>
>> @@ -1507,6 +1508,81 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
>> modifier)
>> #define AMD_FMT_MOD_CLEAR(field) \
>> (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
>>
>> +/*
>> + * Synaptics VideoSmart modifiers
>> + *
>> + * Tiles could be arranged in Groups of Tiles (GOTs), it is a small tile
>> + * within a tile. GOT size and layout varies based on platform and
>> + * performance concern.
>> + *
>> + * Besides, an 8 length 4 bytes arrary (32 bytes) would be need to store
>> + * some compression parameters for a compression metadata plane.
>> + *
>> + * Further information can be found in
>> + * Documentation/gpu/synaptics.rst
>> + *
>> + * Macro
>> + * Bits Param Description
>> + * -
>> -
>> + *
>> + * 7:0 f Scan direction description.
>> + *
>> + * 0 = Invalid
>> + * 1 = V4, the scan would always start from vertical for 4
>> pixel
>> + * then move back to the start pixel of the next
>> horizontal
>> + * direction.
>> + * 2 = Reserved for future use.
>> + *
>> + * 15:8 m The times of pattern repeat in the right angle direction from
>> + * the first scan direction.
>> + *
>> + * 19:16 p The padding bits after the whole scan, could be zero.
>> + *
>> + * 20:20 g GOT packing flag.
>> + *
>> + * 23:21 - Reserved for future use. Must be zero.
>
> Can you pls fold all the future use reservations into the top end?
You see we could put more related flag in each of reserved area.
Here is for the group of tiles flag.
Bit 35 to 32 could be used for describing the dimension of the group of tiles.
> Also I
> think it'd be good to at least reserve maybe the top 8 bits or so for a
> synaptics specific format indicator, so that it's easier to extend this in
> the future ...
I think the bit 56 to 63 are used for storing the vendor id. That is why I
didn’t include them below. Or you mean the bit 7 to 0?
Do yo
> -Daniel
>
>
>> + *
>> + * 27:24 h log2(horizontal) of pixels, in GOTs.
>> + *
>> + * 31:28 v log2(vertical) of pixels, in GOTs.
>> + *
>> + * 35:32 - Reserved for future use. Must be zero.
>> + *
>> + * 36:36 c Compression flag.
>> + *
>> + * 55:37 - Reserved for future use. Must be zero.
>> + *
>> + */
>> +
>> +#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1)
>> +
>> +#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, g, h, v, c) \
>> + fourcc_mod_code(SYNAPTICS, ((__u64)((f) & 0xff) | \
>> + ((__u64)((m) & 0xff) << 8) | \
>> + ((__u64)((p) & 0xf) << 16) | \
>> + ((__u64)((g) & 0x1) << 20) | \
>> + ((__u64)((h) & 0xf) << 24) | \
>> + ((__u64)((v) & 0xf) << 28) | \
>> + ((__u64)((c) & 0x1) << 36)))
>> +
>> +#define DRM_FORMAT_MOD_SYNA_V4H1 \
>> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0, 0, 0, 0)
>> +
>> +#define DRM_FORMAT_MOD_SYNA_V4H3P8 \
>> +
Re: [PATCH v4] drm/fourcc: Add Synaptics VideoSmart tiled modifiers
> On Nov 24, 2022, at 12:42 AM, Daniel Vetter wrote:
>
> On Wed, Nov 23, 2022 at 10:58:11PM +0800, Jisheng Zhang wrote:
>>> On Wed, Nov 23, 2022 at 05:19:57PM +0800, Hsia-Jun Li wrote:
>>> From: "Hsia-Jun(Randy) Li"
>>> Memory Traffic Reduction(MTR) is a module in Synaptics
>>> VideoSmart platform could process lossless compression image
>>> and cache the tile memory line.
>>> Those modifiers only record the parameters would effort pixel
>>> layout or memory layout. Whether physical memory page mapping
>>> is used is not a part of format.
>>> We would allocate the same size of memory for uncompressed
>>> and compressed luma and chroma data, while the compressed buffer
>>> would request two extra planes holding the metadata for
>>> the decompression.
>>> Signed-off-by: Hsia-Jun(Randy) Li
>>> ---
>>> include/uapi/drm/drm_fourcc.h | 75 +++
>>> 1 file changed, 75 insertions(+)
>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>>> index bc056f2d537d..ca0b4ca70b36 100644
>>> --- a/include/uapi/drm/drm_fourcc.h
>>> +++ b/include/uapi/drm/drm_fourcc.h
>>> @@ -407,6 +407,7 @@ extern "C" {
>>> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
>>> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
>>> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
>>> +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b
>> Any users in the mainline tree?
Not yet. I believe a V4L2 codec would be the first one.
Still there are many patches are requested for v4l2 which currently does not
support format modifier. You could find discussion in linux media list.
This does need the agreement from drm maintainers, three of us tend to drop the
pixel formats in video4linux2.h only keeping those codec formats in new
extended v4l2 format negotiation interface. All the pixel formats should go to
drm_fourcc.h while we can’t decide how to present those hardware requests
contiguous memory.
We don’t bring those NV12M into drm_fourcc.h, we hate that.
> Note that drm_fourcc.h serves as the vendor-neutral registry for these
> numbers, and they're referenced in both gl and vk extensions. So this is
> the one case where we do _not_ require in-kernel users or open source
> userspace.
>
The first user for these pixel formats would be the software pixel reader for
Gstreamer, I am planning to add the unpacker for the two uncompressed pixel
formats.
> If there is someone interested in an in-kernel or open userspace driver
> though it would be really great to have their acks before merging. Just to
> make sure that the modifiers will work with both upstream and downstream
> driver stacks.
This patch have been reviewed internally, it is good enough to describe our
pixel formats.
>
> I just realized that we've failed to document this, I'll type up a patch.
About the format itself, I have sent the document to the mesa, you could find a
MR there.
> -Daniel
>
>
>>> /* add more to the end as needed */
>>> @@ -1507,6 +1508,80 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
>>> modifier)
>>> #define AMD_FMT_MOD_CLEAR(field) \
>>> (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
>>> +/*
>>> + * Synaptics VideoSmart modifiers
>>> + *
>>> + * Tiles could be arranged in Groups of Tiles (GOTs), it is a small tile
>>> + * within a tile. GOT size and layout varies based on platform and
>>> + * performance concern. When the compression is applied, it is possible
>>> + * that we would have two tile type in the GOT, these parameters can't
>>> + * tell the secondary tile type.
>>> + *
>>> + * Besides, an 8 size 4 bytes arrary (32 bytes) would be need to store
>>> + * some compression parameters for a compression meta data plane.
>>> + *
>>> + * Macro
>>> + * Bits Param Description
>>> + * -
>>> -
>>> + *
>>> + * 7:0 f Scan direction description.
>>> + *
>>> + * 0 = Invalid
>>> + * 1 = V4, the scan would always start from vertical for 4
>>> pixel
>>> + * then move back to the start pixel of the next
>>> horizontal
>>> + * direction.
>>> + * 2 = Reserved for future use.
>>> + *
>>> + * 15:8 m The times of pattern repeat in the right angle direction
>>> from
>>> + * the first scan direction.
&
Re: [PATCH v4] drm/fourcc: Add Synaptics VideoSmart tiled modifiers
> On Nov 24, 2022, at 1:27 AM, Daniel Vetter wrote:
>
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
>> On Thu, Nov 24, 2022 at 01:14:48AM +0800, Randy Li wrote:
>>
>>>> On Nov 24, 2022, at 12:42 AM, Daniel Vetter wrote:
>>>
>>> On Wed, Nov 23, 2022 at 10:58:11PM +0800, Jisheng Zhang wrote:
>>>>> On Wed, Nov 23, 2022 at 05:19:57PM +0800, Hsia-Jun Li wrote:
>>>>> From: "Hsia-Jun(Randy) Li"
>>>>> Memory Traffic Reduction(MTR) is a module in Synaptics
>>>>> VideoSmart platform could process lossless compression image
>>>>> and cache the tile memory line.
>>>>> Those modifiers only record the parameters would effort pixel
>>>>> layout or memory layout. Whether physical memory page mapping
>>>>> is used is not a part of format.
>>>>> We would allocate the same size of memory for uncompressed
>>>>> and compressed luma and chroma data, while the compressed buffer
>>>>> would request two extra planes holding the metadata for
>>>>> the decompression.
>>>>> Signed-off-by: Hsia-Jun(Randy) Li
>>>>> ---
>>>>> include/uapi/drm/drm_fourcc.h | 75 +++
>>>>> 1 file changed, 75 insertions(+)
>>>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>>>>> index bc056f2d537d..ca0b4ca70b36 100644
>>>>> --- a/include/uapi/drm/drm_fourcc.h
>>>>> +++ b/include/uapi/drm/drm_fourcc.h
>>>>> @@ -407,6 +407,7 @@ extern "C" {
>>>>> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
>>>>> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
>>>>> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
>>>>> +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b
>>>> Any users in the mainline tree?
>> Not yet. I believe a V4L2 codec would be the first one.
>> Still there are many patches are requested for v4l2 which currently does
>> not support format modifier. You could find discussion in linux media
>> list.
>>
>> This does need the agreement from drm maintainers, three of us tend to
>> drop the pixel formats in video4linux2.h only keeping those codec
>> formats in new extended v4l2 format negotiation interface. All the pixel
>> formats should go to drm_fourcc.h while we can’t decide how to present
>> those hardware requests contiguous memory.
>
> Uh no.
>
> These enums are maintained in drm_fourcc.h, by drm maintainers. You
> _cannot_ mix them up with the fourcc enums that video4linux2.h has, that's
> a completely different enum space because fourcc codes are _not_ a
> standard.
>
Things we try to solve is the those non contiguous memory planes in v4l2, we
don’t want to increase them anymore. Besides the values for pixel formats are
the same between V4L2 and drm.
> Please do not ever mix up drm_fourcc format modifiers with v4l2 fourcc
> codes, that will result in complete chaos. There's a reason why there's
> only one authoritative source for these.
>
In the previous version, it would fail in building, because a driver’s
header(ipu-v3) would included both v4l2 and drm. I can’t add another format
modifier macro to v4l2.
If drm doesn’t like the idea that v4l2 use the fourcc from drm, I should inform
people about that.
>> We don’t bring those NV12M into drm_fourcc.h, we hate that.
>>> Note that drm_fourcc.h serves as the vendor-neutral registry for these
>>> numbers, and they're referenced in both gl and vk extensions. So this is
>>> the one case where we do _not_ require in-kernel users or open source
>>> userspace.
>>>
>> The first user for these pixel formats would be the software pixel reader
>> for Gstreamer, I am planning to add the unpacker for the two uncompressed
>> pixel formats.
>>> If there is someone interested in an in-kernel or open userspace driver
>>> though it would be really great to have their acks before merging. Just to
>>> make sure that the modifiers will work with both upstream and downstream
>>> driver stacks.
>> This patch have been reviewed internally, it is good enough to describe our
>> pixel formats.
>>>
>>> I just realized that we've failed to document this, I'll type up a patch.
>>
>> About the format itself, I have sent the document to the mesa, you could
>> find a MR there.
>
> Please include the link to that MR in the patch description.
me
[PATCH v10 1/2] drm/fourcc: Add new P010, P016 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format.
P012 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.
V3: Added P012 and fixed cpp for P010.
V4: format definition refined per review.
V5: Format comment block for each new pixel format.
V6: reversed Cb/Cr order in comments.
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.
V8: reversed V7 changes except commit message and rebased.
v9: used the new properties to describe those format and
rebased.
Cc: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Randy Li
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_fourcc.c | 9 +
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d90ee03a84c6..ba7e19d4336c 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -238,6 +238,15 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0b44260a5ee9..8dd1328bc8d6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -195,6 +195,27 @@ extern "C" {
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane 16 bits per channel */
+
/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 0/2] Add pixel format for 10 bits YUV video
As the requirement from: P010 fourcc format support - Was: Re: Kernel error "Unknown pixelformat 0x" occurs when I start capture video I don't know which device would support the P010, P012, P016 video pixel format, but Rockchip would support that NV12_10LE40 and a patch for that driver is sent before. Randy Li (2): drm/fourcc: Add new P010, P016 video format drm/fourcc: add a 10bits fully packed variant of NV12 drivers/gpu/drm/drm_fourcc.c | 13 + include/uapi/drm/drm_fourcc.h | 29 + 2 files changed, 42 insertions(+) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 2/2] drm/fourcc: add a 10bits fully packed variant of NV12
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 4
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index ba7e19d4336c..16d3be8278f1 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -247,6 +247,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2,
.char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2,
+ .char_per_block = { 5, 5, 0 }, .block_w = { 4, 2, 0 },
.block_h = { 1, 1, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
+ },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8dd1328bc8d6..4985fb19b4ce 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -194,6 +194,14 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * A fully packed 2 plane YCbCr
+ * Y1 0-9, Y2 10-19, Y3 20-29, Y4 20-39
+ *
+ * U1V1: 0-19, U2V2: 20-39
+ */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 2 plane YCbCr MSB aligned
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/rockchip: support hwc layer
From: ayaka
The Windows 2/3 or a RGB UI layer is a high performance flexibly
plane. It is too waste to use it as a cursor plane.
I have verified this patch with weston git version, I am not
sure whether X would meet with this patch. As the previous
author is gone, I can't confirm this problem with him.
Also the weston only use the only two achors with a same
size and pixel format, I need more users to verify this
patch.
changelog:
v2: the previous version is mixed with the code for the other
patches, I forget to remove it.
v3: fix the error for the rk3399 vop little.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++---
2 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb70fb486fbf..1a3b72391ee8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -751,6 +751,26 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_info = (drm_rect_height(dest) - 1) << 16;
dsp_info |= (drm_rect_width(dest) - 1) & 0x;
+ /* HWC layer only supports various of square icon */
+ if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ switch (actual_w) {
+ case 32:
+ dsp_info = 0;
+ break;
+ case 64:
+ dsp_info = 0x1;
+ break;
+ case 94:
+ dsp_info = 0x10;
+ break;
+ case 128:
+ dsp_info = 0x11;
+ break;
+ /* Unsupported pixel resolution */
+ default:
+ return;
+ }
+ }
dsp_stx = dest->x1 + crtc->mode.htotal - crtc->mode.hsync_start;
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08fc40af52c8..694f43fdeb23 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -63,6 +63,15 @@ static const uint32_t formats_win_lite[] = {
DRM_FORMAT_BGR565,
};
+static const uint32_t formats_win_hwc[] = {
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+};
+
static const struct vop_scl_regs rk3036_win_scl = {
.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
@@ -456,6 +465,19 @@ static const struct vop_win_phy rk3288_win23_data = {
.dst_alpha_ctl = VOP_REG(RK3288_WIN2_DST_ALPHA_CTRL, 0xff, 0),
};
+static const struct vop_win_phy rk3288_winhwc_data = {
+ .data_formats = formats_win_hwc,
+ .nformats = ARRAY_SIZE(formats_win_hwc),
+ .enable = VOP_REG(RK3288_HWC_CTRL0, 0x1, 0),
+ .format = VOP_REG(RK3288_HWC_CTRL0, 0x7, 1),
+ .rb_swap = VOP_REG(RK3288_HWC_CTRL0, 0x1, 12),
+ .dsp_info = VOP_REG(RK3288_HWC_CTRL0, 0x3, 5),
+ .dsp_st = VOP_REG(RK3288_HWC_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3288_HWC_MST, 0x, 0),
+ .src_alpha_ctl = VOP_REG(RK3288_HWC_SRC_ALPHA_CTRL, 0x, 0),
+ .dst_alpha_ctl = VOP_REG(RK3288_HWC_DST_ALPHA_CTRL, 0x, 0),
+};
+
static const struct vop_modeset rk3288_modeset = {
.htotal_pw = VOP_REG(RK3288_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
.hact_st_end = VOP_REG(RK3288_DSP_HACT_ST_END, 0x1fff1fff, 0),
@@ -500,7 +522,10 @@ static const struct vop_win_data rk3288_vop_win_data[] = {
{ .base = 0x00, .phy = _win23_data,
.type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x50, .phy = _win23_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
+ { .base = 0x00, .phy = _winhwc_data,
+ .type = DRM_PLANE_TYPE_CURSOR,
+ },
};
static const int rk3288_vop_intrs[] = {
@@ -573,7 +598,10 @@ static const struct vop_win_data rk3368_vop_win_data[] = {
{ .base = 0x00, .phy = _win23_data,
.type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x50, .phy = _win23_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
+ { .base = 0x00, .phy = _winhwc_data,
+ .type = DRM_PLANE_TYPE_CURSOR,
+ },
};
static const struct vop_output rk3368_output = {
@@ -653,7 +681,10 @@ static const struct vop_win_data rk3399_vop_lit_win_data[]
= {
{ .base = 0x00, .phy = _win01_data,
.type = DRM_PLANE_TYPE_PRIMARY },
{ .base = 0x00, .phy = _win23_data,
- .type = DRM_PLAN
[PATCH] drm/rockchip: support hwc layer
From: ayaka
The Windows 2/3 or a RGB UI layer is a high performance flexibly
plane. It is too waste to use it as a cursor plane.
I have verified this patch with weston git version, I am not
sure whether X would meet with this patch. As the previous
author is gone, I can't confirm this problem with him.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 30 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++---
2 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9301006329e8..1103049da91f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -223,6 +223,16 @@ static bool has_rb_swapped(uint32_t format)
}
}
+static bool is_yuv_10bit (uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV12_10LE40:
+ return true;
+ default:
+ return false;
+ };
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -755,6 +765,26 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_info = (drm_rect_height(dest) - 1) << 16;
dsp_info |= (drm_rect_width(dest) - 1) & 0x;
+ /* HWC layer only supports various of square icon */
+ if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ switch (actual_w) {
+ case 32:
+ dsp_info = 0;
+ break;
+ case 64:
+ dsp_info = 0x1;
+ break;
+ case 94:
+ dsp_info = 0x10;
+ break;
+ case 128:
+ dsp_info = 0x11;
+ break;
+ /* Unsupported pixel resolution */
+ default:
+ return;
+ }
+ }
dsp_stx = dest->x1 + crtc->mode.htotal - crtc->mode.hsync_start;
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 6370f7d33273..0f7809511388 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -64,6 +64,15 @@ static const uint32_t formats_win_lite[] = {
DRM_FORMAT_BGR565,
};
+static const uint32_t formats_win_hwc[] = {
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+};
+
static const struct vop_scl_regs rk3036_win_scl = {
.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
@@ -458,6 +467,19 @@ static const struct vop_win_phy rk3288_win23_data = {
.dst_alpha_ctl = VOP_REG(RK3288_WIN2_DST_ALPHA_CTRL, 0xff, 0),
};
+static const struct vop_win_phy rk3288_winhwc_data = {
+ .data_formats = formats_win_hwc,
+ .nformats = ARRAY_SIZE(formats_win_hwc),
+ .enable = VOP_REG(RK3288_HWC_CTRL0, 0x1, 0),
+ .format = VOP_REG(RK3288_HWC_CTRL0, 0x7, 1),
+ .rb_swap = VOP_REG(RK3288_HWC_CTRL0, 0x1, 12),
+ .dsp_info = VOP_REG(RK3288_HWC_CTRL0, 0x3, 5),
+ .dsp_st = VOP_REG(RK3288_HWC_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3288_HWC_MST, 0x, 0),
+ .src_alpha_ctl = VOP_REG(RK3288_HWC_SRC_ALPHA_CTRL, 0x, 0),
+ .dst_alpha_ctl = VOP_REG(RK3288_HWC_DST_ALPHA_CTRL, 0x, 0),
+};
+
static const struct vop_modeset rk3288_modeset = {
.htotal_pw = VOP_REG(RK3288_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
.hact_st_end = VOP_REG(RK3288_DSP_HACT_ST_END, 0x1fff1fff, 0),
@@ -502,7 +524,10 @@ static const struct vop_win_data rk3288_vop_win_data[] = {
{ .base = 0x00, .phy = _win23_data,
.type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x50, .phy = _win23_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
+ { .base = 0x00, .phy = _winhwc_data,
+ .type = DRM_PLANE_TYPE_CURSOR,
+ },
};
static const int rk3288_vop_intrs[] = {
@@ -575,7 +600,10 @@ static const struct vop_win_data rk3368_vop_win_data[] = {
{ .base = 0x00, .phy = _win23_data,
.type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x50, .phy = _win23_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
+ { .base = 0x00, .phy = _winhwc_data,
+ .type = DRM_PLANE_TYPE_CURSOR,
+ },
};
static const struct vop_output rk3368_output = {
@@ -655,7 +683,10 @@ static const struct vop_win_data rk3399_vop_lit_win_data[]
= {
{ .base = 0x00, .phy = _win01_data,
[PATCH v2] drm/rockchip: support hwc layer
The Windows 2/3 or a RGB UI layer is a high performance flexibly
plane. It is too waste to use it as a cursor plane.
I have verified this patch with weston git version, I am not
sure whether X would meet with this patch. As the previous
author is gone, I can't confirm this problem with him.
Also the weston only use the only two achors with a same
size and pixel format, I need more users to verify this
patch.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 44 ++---
2 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 51bdc55b4b9c..1fa88000fab7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -765,6 +765,26 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_info = (drm_rect_height(dest) - 1) << 16;
dsp_info |= (drm_rect_width(dest) - 1) & 0x;
+ /* HWC layer only supports various of square icon */
+ if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ switch (actual_w) {
+ case 32:
+ dsp_info = 0;
+ break;
+ case 64:
+ dsp_info = 0x1;
+ break;
+ case 94:
+ dsp_info = 0x10;
+ break;
+ case 128:
+ dsp_info = 0x11;
+ break;
+ /* Unsupported pixel resolution */
+ default:
+ return;
+ }
+ }
dsp_stx = dest->x1 + crtc->mode.htotal - crtc->mode.hsync_start;
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 6370f7d33273..6eba9ef78865 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -64,6 +64,15 @@ static const uint32_t formats_win_lite[] = {
DRM_FORMAT_BGR565,
};
+static const uint32_t formats_win_hwc[] = {
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+};
+
static const struct vop_scl_regs rk3036_win_scl = {
.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
@@ -458,6 +467,19 @@ static const struct vop_win_phy rk3288_win23_data = {
.dst_alpha_ctl = VOP_REG(RK3288_WIN2_DST_ALPHA_CTRL, 0xff, 0),
};
+static const struct vop_win_phy rk3288_winhwc_data = {
+ .data_formats = formats_win_hwc,
+ .nformats = ARRAY_SIZE(formats_win_hwc),
+ .enable = VOP_REG(RK3288_HWC_CTRL0, 0x1, 0),
+ .format = VOP_REG(RK3288_HWC_CTRL0, 0x7, 1),
+ .rb_swap = VOP_REG(RK3288_HWC_CTRL0, 0x1, 12),
+ .dsp_info = VOP_REG(RK3288_HWC_CTRL0, 0x3, 5),
+ .dsp_st = VOP_REG(RK3288_HWC_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3288_HWC_MST, 0x, 0),
+ .src_alpha_ctl = VOP_REG(RK3288_HWC_SRC_ALPHA_CTRL, 0x, 0),
+ .dst_alpha_ctl = VOP_REG(RK3288_HWC_DST_ALPHA_CTRL, 0x, 0),
+};
+
static const struct vop_modeset rk3288_modeset = {
.htotal_pw = VOP_REG(RK3288_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
.hact_st_end = VOP_REG(RK3288_DSP_HACT_ST_END, 0x1fff1fff, 0),
@@ -502,7 +524,10 @@ static const struct vop_win_data rk3288_vop_win_data[] = {
{ .base = 0x00, .phy = _win23_data,
.type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x50, .phy = _win23_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
+ { .base = 0x00, .phy = _winhwc_data,
+ .type = DRM_PLANE_TYPE_CURSOR,
+ },
};
static const int rk3288_vop_intrs[] = {
@@ -575,7 +600,10 @@ static const struct vop_win_data rk3368_vop_win_data[] = {
{ .base = 0x00, .phy = _win23_data,
.type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x50, .phy = _win23_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
+ { .base = 0x00, .phy = _winhwc_data,
+ .type = DRM_PLANE_TYPE_CURSOR,
+ },
};
static const struct vop_output rk3368_output = {
@@ -654,8 +682,13 @@ static const struct vop_data rk3399_vop_big = {
static const struct vop_win_data rk3399_vop_lit_win_data[] = {
{ .base = 0x00, .phy = _win01_data,
.type = DRM_PLANE_TYPE_PRIMARY },
+ { .phy = NULL},
{ .base = 0x00, .phy = _win23_data,
- .type = DRM_PLANE_TYPE_CURSOR},
+ .type = DRM_PLANE_TYPE_OVERLAY},
+ { .phy = NULL},
+ { .base = 0x00, .phy
[PATCH v4 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index f523948c82b1..76d3ce314f31 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -237,6 +237,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e7e48f1f4a74..5de5aff83d85 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -193,6 +193,14 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * A fully packed 2 plane YCbCr
+ * Y1 0-9, Y2 10-19, Y3 20-29, Y4 20-39
+ *
+ * U1V1: 0-19, U2V2: 20-39
+ */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] Add support for a YUV 10bits pixel format
I wonder why this patches are still not merged and well review. So I just re-send them. I wish it is merged in a short time, or I can't add a new pixel format to weston. You can use the Gstreamer to verify this patch. Randy Li (2): drm/fourcc: add a 10bits fully packed variant of NV12 drm/rockchip: Support 10 bits yuv format in vop drivers/gpu/drm/drm_fourcc.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 ++-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++ include/uapi/drm/drm_fourcc.h | 8 5 files changed, 26 insertions(+), 2 deletions(-) -- 2.14.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/rockchip: Support 10 bits yuv format in vop
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 ++--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb70fb486fbf..9301006329e8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -238,6 +238,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV12_10LE40:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -725,6 +726,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
@@ -743,6 +745,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
obj = fb->obj[0];
+ is_10_bits = is_yuv_10bit(fb->format->format);
+
rk_obj = to_rockchip_obj(obj);
actual_w = drm_rect_width(src) >> 16;
@@ -756,7 +760,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (fb->format->cpp[0] * 5 / 4);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -767,6 +775,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (fb->format->is_yuv) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -775,7 +784,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (bpp * 5 / 4) / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 0fe40e1983d9..1ab32d8be599 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -132,6 +132,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08fc40af52c8..6370f7d33273 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,7 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV12_10LE40,
};
static const uint32_t formats_win_lite[] = {
@@ -428,6 +429,7 @@ static const struct vop_win_phy rk3288_win01_data = {
.nformats = ARRAY_SIZE(formats_win_full),
.enable = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 0),
.format = VOP_REG(RK3288_WIN0_CTRL0, 0x7, 1),
+ .fmt_10 = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 4),
.rb_swap = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 12),
.act_info = VOP_REG(RK3288_WIN0_ACT_INFO, 0x1fff1fff, 0),
.dsp_info = VOP_REG(RK3288_WIN0_DSP_INFO, 0x0fff0fff, 0),
--
2.14.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/rockchip: Support 10 bits yuv format in vop
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..6a54b20501ac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV12_10LE40:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,6 +250,17 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV12_10LE40:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool is_yuv_10bit(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV12_10LE40:
return true;
default:
return false;
@@ -711,6 +723,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
@@ -728,6 +741,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ is_10_bits = is_yuv_10bit(fb->format->format);
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -742,7 +757,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (fb->format->cpp[0] * 5 / 4);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -753,6 +772,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -761,7 +781,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (bpp * 5 / 4) / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084acdd0019a..d9ec993f420a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -131,6 +131,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08023d3ecb76..5393886ddd95 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,7 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV12_10LE40,
};
static const uint32_t formats_win_lite[] = {
@@ -215,6 +216,7 @@ static const struct vop_win_phy rk3288_win01_data = {
.nformats = ARRAY_SIZE(formats_win_full),
.enable = VOP_RE
[PATCH v2 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride. The color gamut
follows the BT.2020 standard.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] Add support for a YUV 10bits pixel format
In the last time, I got some feedback and not a clear guide on what I should do. So just give more comment on describing this 10bits format. Whether I should add bpp instead cpp in drm_format_info and update a numbers of functions is up to you guys. And I don't any other driver would request 10bits yuv format support, so I can't add the pixel format they don't use as I did a year ago. You would ignore those patches. v3: I put a code comment in a wrong commit in the previous commit, move it back. v2: add more comment to describe this pixel format Randy Li (2): drm/fourcc: add a 10bits fully packed variant of NV12 drm/rockchip: Support 10 bits yuv format in vop drivers/gpu/drm/drm_fourcc.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++ include/uapi/drm/drm_fourcc.h | 8 5 files changed, 37 insertions(+), 2 deletions(-) -- 2.14.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..14bee94a12d9 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,14 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * A fully packed 2 plane YCbCr
+ * Y1 0-9, Y2 10-19, Y3 20-29, Y4 20-39
+ *
+ * U1V1: 0-19, U2V2: 20-39
+ */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/rockchip: Support 10 bits yuv format in vop
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
include/uapi/drm/drm_fourcc.h | 6 +-
4 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..6a54b20501ac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV12_10LE40:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,6 +250,17 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV12_10LE40:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool is_yuv_10bit(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV12_10LE40:
return true;
default:
return false;
@@ -711,6 +723,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
@@ -728,6 +741,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ is_10_bits = is_yuv_10bit(fb->format->format);
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -742,7 +757,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (fb->format->cpp[0] * 5 / 4);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -753,6 +772,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -761,7 +781,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (bpp * 5 / 4) / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084acdd0019a..d9ec993f420a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -131,6 +131,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08023d3ecb76..5393886ddd95 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,7 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV12_10LE40,
};
static const uint32_t formats_win_lite[] = {
@@ -215,6 +216,7 @@ static const struct vop_win_phy rk3288_win01_data = {
.nformats =
[PATCH v2 0/2] Add support for a YUV 10bits pixel format
In the last time, I got some feedback and not a clear guide on what I should do. So just give more comment on describing this 10bits format. Whether I should add bpp instead cpp in drm_format_info and update a numbers of functions is up to you guys. And I don't any other driver would request 10bits yuv format support, so I can't add the pixel format they don't use as I did a year ago. You would ignore those patches. Randy Li (2): drm/fourcc: add a 10bits fully packed variant of NV12 drm/rockchip: Support 10 bits yuv format in vop drivers/gpu/drm/drm_fourcc.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++ include/uapi/drm/drm_fourcc.h | 7 +++ 5 files changed, 36 insertions(+), 2 deletions(-) -- 2.14.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
On 05/22/2018 05:26 PM, Maarten Lankhorst wrote:
Op 20-05-18 om 19:17 schreef Randy Li:
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride. The color gamut
follows the BT.2020 standard.
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
Hm, the cpp value might give problems because it rounds down, not sure how we
should handle that? Set to zero?
It is default behavior that using the filed "cpp" to calculate the
pixel in many drivers. I would suggest use a new filed called bits per
pixel (bpp) instead of the old cpp.
The one used in the Gstreamer is more complex:
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-GstVideoAlignment.html#GstVideoFormatInfo
As the struct drm_format_info only a kernel internal data structure, it
doesn't need to update the user-space interface like libdrm.
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Add support for a YUV 10bits pixel format
This pixel format is current used in the rockchip platform. I think any model higher than rk322x would support this pixel format. Xilinx may support it but I am not sure. More than a year ago, I post the patch Add pixel formats for 10/16 bits YUV video to the mail list, it has been update to version 8, but they are not merged yet. So I decide to submit these independent patches, I hope that they would be reviewed and merged in a short time. I have added a patch to Gstreamer and it is merged now. Any future information can be found on the bugzilla of the Gstreamer: https://bugzilla.gnome.org/show_bug.cgi?id=795462 I have verified this patch on the rk3288, with the following command: gst-launch-1.0 filesrc location=conv_3840_2160.nv12_10le40 ! \ rawvideoparse format=81 width=3840 height=2160 ! imagefreeze ! kmssink Also you can find video sample video on above page, but you may need to set the plane offset and stride when you are using the other files. Randy Li (2): drm/fourcc: add a 10bits fully packed variant of NV12 drm/rockchip: Support 10 bits yuv format in vop drivers/gpu/drm/drm_fourcc.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++ include/uapi/drm/drm_fourcc.h | 3 +++ 5 files changed, 32 insertions(+), 2 deletions(-) -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride. The color gamut
follows the BT.2020 standard.
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395cd4d3..1f43967c4013 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..8eabf01e966f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -140,6 +140,9 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/* A fully packed variant of NV12_10LE32 */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2
subsampled Cr:Cb plane */
+
/*
* 3 plane YCbCr
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/rockchip: Support 10 bits yuv format in vop
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2121345a61af..6a54b20501ac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV12_10LE40:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,6 +250,17 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV12_10LE40:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool is_yuv_10bit(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV12_10LE40:
return true;
default:
return false;
@@ -711,6 +723,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
@@ -728,6 +741,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ is_10_bits = is_yuv_10bit(fb->format->format);
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -742,7 +757,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (fb->format->cpp[0] * 5 / 4);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -753,6 +772,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -761,7 +781,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * (bpp * 5 / 4) / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084acdd0019a..d9ec993f420a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -131,6 +131,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 08023d3ecb76..5393886ddd95 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,7 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV12_10LE40,
};
static const uint32_t formats_win_lite[] = {
@@ -215,6 +216,7 @@ static const struct vop_win_phy rk3288_win01_data = {
.nformats = ARRAY_SIZE(formats_win_full),
[PATCH v2] drm/rockchip: analogix_dp: add supports for regulators in edp IP
I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first.
The eDP_AVDD_1V8 is used for eDP phy, and the eDP_AVDD_1V0 are used
both for eDP phy and controller.
Change-Id: I4e8a34609d5b292d7da77385ff15bebbf258090c
Signed-off-by: Randy Li <ay...@soulik.info>
Signed-off-by: Randy Li <randy...@rock-chips.com>
---
.../display/rockchip/analogix_dp-rockchip.txt | 4 ++
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 52 ++
2 files changed, 56 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 47665a1..0dbbfb3 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -34,6 +34,10 @@ Optional property for different chips:
- clock-names: from common clock binding:
Required elements: "grf"
+- vcc-supply: Regulator for eDP_AVDD_1V0.
+
+- vccio-supply: Regulator for eDP_AVDD_1V8.
+
For the below properties, please refer to Analogix DP binding document:
* Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
- phys (required)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d8fa7a9..2dad625 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,8 @@ struct rockchip_dp_device {
struct clk *grfclk;
struct regmap*grf;
struct reset_control *rst;
+ struct regulator *vcc_supply;
+ struct regulator *vccio_supply;
struct work_struct psr_work;
spinlock_t psr_lock;
@@ -146,6 +149,24 @@ static int rockchip_dp_poweron(struct
analogix_dp_plat_data *plat_data)
cancel_work_sync(>psr_work);
+ if (!IS_ERR(dp->vcc_supply)) {
+ ret = regulator_enable(dp->vcc_supply);
+ if (ret) {
+ dev_err(dp->dev,
+ "failed to enable vcc regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
+ if (!IS_ERR(dp->vccio_supply)) {
+ ret = regulator_enable(dp->vccio_supply);
+ if (ret) {
+ dev_err(dp->dev,
+ "failed to enable vccio regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
dev_err(dp->dev, "failed to enable pclk %d\n", ret);
@@ -168,6 +189,11 @@ static int rockchip_dp_powerdown(struct
analogix_dp_plat_data *plat_data)
clk_disable_unprepare(dp->pclk);
+ if (!IS_ERR(dp->vccio_supply))
+ regulator_disable(dp->vccio_supply);
+ if (!IS_ERR(dp->vcc_supply))
+ regulator_disable(dp->vcc_supply);
+
return 0;
}
@@ -323,6 +349,32 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
return PTR_ERR(dp->rst);
}
+ dp->vcc_supply = devm_regulator_get_optional(dev, "vcc");
+ dp->vccio_supply = devm_regulator_get_optional(dev, "vccio");
+
+ if (IS_ERR(dp->vcc_supply)) {
+ dev_err(dev, "failed to get vcc regulator: %ld\n",
+ PTR_ERR(dp->vcc_supply));
+ } else {
+ ret = regulator_enable(dp->vcc_supply);
+ if (ret) {
+ dev_err(dev,
+ "failed to enable vcc regulator: %d\n", ret);
+ return ret;
+ }
+ }
+ if (IS_ERR(dp->vccio_supply)) {
+ dev_err(dev, "failed to get vccio regulator: %ld\n",
+ PTR_ERR(dp->vccio_supply));
+ } else {
+ ret = regulator_enable(dp->vccio_supply);
+ if (ret) {
+ dev_err(dev,
+ "failed to enable vccio regulator: %d\n", ret);
+ return ret;
+ }
+ }
+
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
dev_err(dp->dev, "failed to enable pclk %d\n", ret);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/3] Add pixel format for 10 bits YUV video
Thanks to Clint's work, this version just correct some wrong info in the comment. I also offer a driver sample here, but it have been verified with the 10 bits properly. I lacks of the userspace tool. And I am not sure whether it is a properly way to support the pixel format used in rockchip, although it is not common used pixel format, but it could save lots of memory, it may be welcome by the other vendor, also I think the 3GR serial from Intel would use the same pixel format as the video IP comes from rockchip. Randy Li (3): drm_fourcc: Add new P010, P016 video format v4l: Add 10/16-bits per channel YUV pixel formats drm/rockchip: Support 10 bits yuv format in vop Documentation/media/uapi/v4l/pixfmt-p010.rst | 126 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++ Documentation/media/uapi/v4l/pixfmt-p016.rst | 125 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 + Documentation/media/uapi/v4l/yuv-formats.rst | 4 + drivers/gpu/drm/drm_fourcc.c | 3 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + include/uapi/drm/drm_fourcc.h | 32 ++ include/uapi/linux/videodev2.h| 5 + 12 files changed, 599 insertions(+), 3 deletions(-) create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format.
Also a variant of V4L2_PIX_FMT_P010M pixel format is added.
The V4L2_PIX_FMT_P010CM is a compat variant of the V4L2_PIX_FMT_P010,
which uses the unused 6 bits to store the next pixel. And with
the alignment requirement of the hardware, it usually would be
some extra space left at the end of a stride.
Signed-off-by: Randy Li <ay...@soulik.info>
---
Documentation/media/uapi/v4l/pixfmt-p010.rst | 126
Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++
Documentation/media/uapi/v4l/pixfmt-p016.rst | 125
Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
Documentation/media/uapi/v4l/yuv-formats.rst | 4 +
include/uapi/linux/videodev2.h| 5 +
6 files changed, 529 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..59ed118
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,126 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 16 bits per pixel, but only 10 bits are used with the
+rest 6 bits set to zero. For ``V4L2_PIX_FMT_P010``, a combined CbCr plane
+immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Byte Order.**
+Each cell is two bytes.
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+* - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+* - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+* - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+* - start + 16:
+ - Cb\ :sub:`00`
+ - Cr\ :sub:`00`
+ - Cb\ :sub:`01`
+ - Cr\ :sub:`01`
+* - start + 20:
+ - Cb\ :sub:`10`
+ - Cr\ :sub:`10`
+ - Cb\ :sub:`11`
+ - Cr\ :sub:`11`
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+* - 2
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 3
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 000..6697d15
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,135 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***
+V4L2_PIX_FMT_P010M ('PM10')
+***
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminanc
[PATCH v6 3/3] drm/rockchip: Support 10 bits yuv format in vop
The rockchip use a special pixel format for those yuv pixel
format with 10 bits color depth.
Signed-off-by: Randy Li <ay...@soulik.info>
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
include/uapi/drm/drm_fourcc.h | 11 ++
5 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index c9ccdf8..250fd29 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -230,6 +230,7 @@ void rockchip_drm_mode_config_init(struct drm_device *dev)
*/
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
+ dev->mode_config.allow_fb_modifiers = true;
dev->mode_config.funcs = _drm_mode_config_funcs;
dev->mode_config.helper_private = _mode_config_helpers;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..45da270 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_P010:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,12 +250,28 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_P010:
return true;
default:
return false;
}
}
+static bool is_support_fb(struct drm_framebuffer *fb)
+{
+ switch (fb->format->format) {
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV24:
+ return true;
+ case DRM_FORMAT_P010:
+ if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+ return true;
+ default:
+ return false;
+ }
+
+}
static bool is_alpha_support(uint32_t format)
{
switch (format) {
@@ -680,7 +697,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
* Src.x1 can be odd when do clip, but yuv plane start point
* need align with 2 pixel.
*/
- if (is_yuv_support(fb->format->format) && ((state->src.x1 >> 16) % 2))
+ if (is_support_fb(fb) && ((state->src.x1 >> 16) % 2))
return -EINVAL;
return 0;
@@ -723,6 +740,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+ bool is_10_bits = false;
int format;
/*
@@ -739,6 +757,9 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
+ if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+ is_10_bits = true;
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -753,7 +774,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * 10 / 8;
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -764,6 +788,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, fb->pitches[0] >> 2);
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+ VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub =
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -772,7 +797,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (is_10_bits)
+ offset = (src->x1 >> 16) * 10 / 8 / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
[PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format.
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.
V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.
Cc: Daniel Stone <dan...@fooishbar.org>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Randy Li <ay...@soulik.info>
Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com>
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@ extern "C" {
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: rockchip: CONFIG_DRM_FBDEV_EMULATION will crash the HDMI down sometimes
-[ end trace 92447684af807ac2 ]--- [ 11.481977] vop active 1, state 1 [ 11.481985] [ cut here ] [ 11.482021] WARNING: CPU: 3 PID: 167 at /home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/rockchip/rockchip_drm_ vop.c:1023 vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm] [ 11.482030] Modules linked in: rockchip_vop_reg dw_hdmi_rockchip dw_hdmi rockchipdrm drm_kms_helper mali_kbase cfbfillrect sysc opyarea rk_crypto gpio_ir_recv cfbimgblt panel_simple sysfillrect rc_core sysimgblt nvmem_rockchip_efuse fb_sys_fops cfbcopyarea d rm des_generic dwc2 pwm_rockchip phy_rockchip_usb udc_core fb pwm_bl backlight [ 11.482119] CPU: 3 PID: 167 Comm: kworker/3:2 Tainted: GW 4.10.0-rc3-next-20170111+ #149 [ 11.482122] Hardware name: Rockchip (Device Tree) [ 11.482200] Workqueue: events output_poll_execute [drm_kms_helper] [ 11.482227] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 11.482242] [] (show_stack) from [] (dump_stack+0x8c/0xa0) [ 11.482259] [] (dump_stack) from [] (__warn+0xf8/0x110) [ 11.482275] [] (__warn) from [] (warn_slowpath_null+0x30/0x38) [ 11.482308] [] (warn_slowpath_null) from [] (vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm]) [ 11.482416] [] (vop_crtc_atomic_flush [rockchipdrm]) from [] (drm_atomic_helper_commit_planes+0x1d0/0x2b8 [ drm_kms_helper]) [ 11.482522] [] (drm_atomic_helper_commit_planes [drm_kms_helper]) from [] (rockchip_atomic_commit_tail+0x44 /0x68 [rockchipdrm]) [ 11.482623] [] (rockchip_atomic_commit_tail [rockchipdrm]) from [] (commit_tail+0x50/0xb8 [drm_kms_helper]) [ 11.482779] [] (commit_tail [drm_kms_helper]) from [] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper] ) [ 11.483024] [] (drm_atomic_helper_commit [drm_kms_helper]) from [] (drm_atomic_commit+0x5c/0x68 [drm]) [ 11.483270] [] (drm_atomic_commit [drm]) from [] (restore_fbdev_mode+0x160/0x300 [drm_kms_helper]) [ 11.483422] [] (restore_fbdev_mode [drm_kms_helper]) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4 0/0x84 [drm_kms_helper]) [ 11.483569] [] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [] (drm_fb_helper_set_par+ 0x40/0x70 [drm_kms_helper]) [ 11.483715] [] (drm_fb_helper_set_par [drm_kms_helper]) from [] (drm_fb_helper_hotplug_event+0xb4/0xbc [drm _kms_helper]) [ 11.483821] [] (drm_fb_helper_hotplug_event [drm_kms_helper]) from [] (rockchip_drm_output_poll_changed+0x2 4/0x28 [rockchipdrm]) Thanks. On 2017年01月17日 15:58, Randy Li wrote: Hello: I want to enable the video output at RK3288 Firefly board, but I found if I enable CONFIG_DRM_FBDEV_EMULATION, the HDMI would crash down sometimes but sometimes it works. After disable that opinion, I never meet a problem. I have not verified it with eDP as I meet a big problem in there. [..] [ 34.464856] ---[ end trace 95ed2c3f167607d5 ]--- -- Randy Li ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm: rockchip: CONFIG_DRM_FBDEV_EMULATION will crash the HDMI down sometimes
[drm_kms_helper]) from [] (drm_atomic_helper_wait _for_vblanks+0x24/0x28 [drm_kms_helper]) [ 34.321176] [] (drm_atomic_helper_wait_for_vblanks [drm_kms_helper]) from [] (rockchip_atomic_commit_tail+0 x58/0x68 [rockchipdrm]) [ 34.334725] [] (rockchip_atomic_commit_tail [rockchipdrm]) from [] (commit_tail+0x50/0xb8 [drm_kms_helper]) [ 34.346330] [] (commit_tail [drm_kms_helper]) from [] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper] ) [ 34.358117] [] (drm_atomic_helper_commit [drm_kms_helper]) from [] (drm_atomic_commit+0x5c/0x68 [drm]) [ 34.369386] [] (drm_atomic_commit [drm]) from [] (restore_fbdev_mode+0x160/0x300 [drm_kms_helper]) [ 34.380209] [] (restore_fbdev_mode [drm_kms_helper]) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4 0/0x84 [drm_kms_helper]) [ 34.393845] [] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [] (rockchip_drm_lastclose +0x1c/0x20 [rockchipdrm]) [ 34.407664] [] (rockchip_drm_lastclose [rockchipdrm]) from [] (drm_lastclose+0x48/0xd8 [drm]) [ 34.418237] [] (drm_lastclose [drm]) from [] (drm_release+0x2c4/0x36c [drm]) [ 34.427179] [] (drm_release [drm]) from [] (__fput+0x9c/0x1e8) [ 34.434754] [] (__fput) from [] (fput+0x18/0x1c) [ 34.441458] [] (fput) from [] (task_work_run+0xcc/0xf0) [ 34.448769] [] (task_work_run) from [] (do_work_pending+0xd0/0xd4) [ 34.456688] [] (do_work_pending) from [] (slow_work_pending+0xc/0x20) [ 34.464856] ---[ end trace 95ed2c3f167607d5 ]--- -- Randy Li The third produce department === This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] === ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Request API: stateless VPU: the buffer mechanism and DPB management
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. -- Randy Li The third produce department ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Request API: stateless VPU: the buffer mechanism and DPB management
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. ___ 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
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those 10 bits format for
profile_10 HEVC/AVC video.
Signed-off-by: Randy Li
v4l2
---
Documentation/media/uapi/v4l/pixfmt-p010.rst | 86
Documentation/media/uapi/v4l/pixfmt-p010m.rst | 94 ++
Documentation/media/uapi/v4l/pixfmt-p016.rst | 126
Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++
include/uapi/linux/videodev2.h| 4 +
5 files changed, 446 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..82b300c
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,86 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 10 bits per pixel. For ``V4L2_PIX_FMT_P010``, a
+combined CbCr plane immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+* - 2
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 3
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 000..80194a1
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,94 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***
+V4L2_PIX_FMT_P010 ('P010')
+***
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminance data
+occupies the first plane. The Y plane has one byte per pixel. In the
+second plane there is a chrominance data with alternating chroma
+samples. The CbCr plane is the same width, in bytes, as the Y plane (and
+of the image), but is half as tall in pixels. Each CbCr pair belongs to
+four pixels. For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to
+Y'\ :sub:`00`, Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+
+``V4L2_PIX_FMT_P010M`` is intended to be used only in drivers and
+applications that support the multi-planar API, described in
+:ref:`planar-apis`.
+
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Color Sample Location..**
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* -
+ - 0
+ -
+ - 1
+ - 2
+ -
+ - 3
+* - 0
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
+* -
+ -
+ - C
+ -
+ -
+ - C
+ -
+* - 1
+ - Y
+ -
+ - Y
+ - Y
+ -
+ - Y
[PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.
Signed-off-by: Randy Li
drm
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..23c8e99 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ /* FIXME a pixel in Y for P010 is 10 bits */
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..ecc2e05e5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,8 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane 16 bits per channel */
/*
* 3 plane YCbCr
--
2.7.4
[PATCH v2 0/2] Add pixel formats for 10/16 bits YUV video
Those pixel formats mainly comes from Gstreamer and ffmpeg. Currently, the VOP(video output mixer) found on RK3288 and future support those 10 bits pixel formats are input. Also the decoder on RK3288 could use them as output. The fourcc is not enough to store the endian information for those pixel formats in v4l2, as it doesn't have a flag like drm does. I have not met the usage of those 16 bits per-channel format, it is a very large color range, even the DSLR only use 12 bits. Randy Li (2): drm_fourcc: Add new P010, P016 video format [media] v4l: Add 10/16-bits per channel YUV pixel formats Documentation/media/uapi/v4l/pixfmt-p010.rst | 86 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 94 ++ Documentation/media/uapi/v4l/pixfmt-p016.rst | 126 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 ++ drivers/gpu/drm/drm_fourcc.c | 3 + include/uapi/drm/drm_fourcc.h | 2 + include/uapi/linux/videodev2.h| 4 + 7 files changed, 451 insertions(+) create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst -- 2.7.4
Is drmWaitVBlank() or drmModePageFlip necessary after drmModeSetPlane()
Hello all, Recently, I meet a performance problem with drmModeSetPlane(), it works quite slow with drm_atomic_commit(), I have to force it use drm_atomic_async_commit() for drmModeSetPlane() which modifies the drm base system. I want to optimize the performance in standard way, so I think I could move those sync job to one of drmWaitVBlank() or drmModePageFlip. But I found most of atomic_commit() would have a sync internal, waiting vbank. So those functions like drmWaitVBlank() or drmModePageFlip are not necessary after drmModeSetPlane()? -- Randy Li The third produce department
[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC video.
Signed-off-by: Randy Li
---
include/uapi/linux/videodev2.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..9e03f20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
4:2:2 */
#define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
4:4:4 */
#define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb
4:4:4 */
+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr
4:2:0, 10 bits per channel */
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb
4:2:2 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 64x32 macroblocks */
#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr
4:2:0, 10 bits per channel */
/* three planes - Y Cb, Cr */
#define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV 4:1:0
*/
--
2.7.4
[PATCH 1/2] drm_fourcc: Add new P010 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.
Signed-off-by: Randy Li
---
include/uapi/drm/drm_fourcc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..d2721da 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,7 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
/*
* 3 plane YCbCr
--
2.7.4
[PATCH 0/2] Add pixel format for 10 bits YUV video
Those pixel formats comes from Gstreamer and ffmpeg. Currently, the VOP(video output mixer) found on RK3288 and future support those pixel formats are input. Also the decoder on RK3288 could use them as output. Randy Li (2): drm_fourcc: Add new P010 video format [media] v4l: Add 10-bits per channel YUV pixel formats include/uapi/drm/drm_fourcc.h | 1 + include/uapi/linux/videodev2.h | 2 ++ 2 files changed, 3 insertions(+) -- 2.7.4
[PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
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.
>
> 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);
>>
>
>
--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===
How to implement a EGL or DRM display in VA-API driver
On 10/27/2016 11:03 PM, Xiang, Haihao wrote: >> -Original Message- >> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf >> Of Randy Li >> Sent: Monday, October 24, 2016 3:59 PM >> To: libva at lists.freedesktop.org >> Cc: gwenole.beauchesne at intel.com; dri-devel at lists.freedesktop.org; >> linux- >> rockchip at lists.infradead.org; Jaquez, VictorX > intel.com>; >> eddie.cai ; æéå > rock-chips.com>; >> herman.chen at rock-chips.com; vjaquez at igalia.com >> Subject: How to implement a EGL or DRM display in VA-API driver >> >> Hello: >> I am going to implement a EGL and DRM display for Rockchip VA-API driver. >> We do have a EGL implementation in Rockchip VA-API driver, but it is >> implemented in the standard way, we did that as a X11 display. >> I didn't see the usage of struct VADriverVTableEGL in gstreamer, and I have >> no idea about where should I implement something functions like >> eglExportDRMImageMESA(). > > VADriverVTableEGL is deprecated in libva, we has a more efficient way to use > vaapi and egl. > You can refer to the examples in libyami-utils > (https://github.com/01org/libyami-utils.git) for > how to use vaapi and egl. I see, thank you. > >> The DRM seems more complex, the reason I want to use the DRM is that, >> GPU would not work with the 4K video rendering, so the DRM means that >> directly output the video into video controller in our platform. But still >> have no >> idea what kind of thing I should implement in the VA-API driver. It seems >> that >> the VA-API base library would open a DRM instance for the driver, but leaving >> those configure for connector, encoder, planes to VA-API driver? About the DRM, I have implemented a version which pretends a X output, I would like to know a better way. > > configure for connector, encoder, planes aren't a part of va-api driver. You > should check libdrm and drm/i915. > You can refer to the test case of modetest in libdrm > (git.freedesktop.org/git/mesa/drm) > > >> Could you guys give me same sample code or example of those kind of >> display in VA-API or the documents would help(I would not image there is a >> VA-API documents) >> >> -- >> Randy Li >> The third produce department >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Randy Li The third produce department === This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
How to implement a EGL or DRM display in VA-API driver
Hello: I am going to implement a EGL and DRM display for Rockchip VA-API driver. We do have a EGL implementation in Rockchip VA-API driver, but it is implemented in the standard way, we did that as a X11 display. I didn't see the usage of struct VADriverVTableEGL in gstreamer, and I have no idea about where should I implement something functions like eglExportDRMImageMESA(). The DRM seems more complex, the reason I want to use the DRM is that, GPU would not work with the 4K video rendering, so the DRM means that directly output the video into video controller in our platform. But still have no idea what kind of thing I should implement in the VA-API driver. It seems that the VA-API base library would open a DRM instance for the driver, but leaving those configure for connector, encoder, planes to VA-API driver? Could you guys give me same sample code or example of those kind of display in VA-API or the documents would help(I would not image there is a VA-API documents) -- Randy Li The third produce department
[PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first. The eDP_AVDD_1V8 more
likely to be applied to eDP phy, but I have no time to confirmed
it yet.
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);
--
2.7.4
the dp helper would try to enable the i2c channel for rockchip-edp
On 10/20/2016 03:18 PM, Tomeu Vizoso wrote: > On 19 October 2016 at 15:52, Randy Li wrote: >> Hello, >> >> Recently, I want to use a eDP panel in my RK3288 platform, but I got the >> following message: >> >> [8.935918] i2c i2c-6: of_i2c: modalias failure on /dp at ff97/ports >> [8.936018] rockchip-drm display-subsystem: bound ff97.dp (ops >> rockchip_dp_component_ops [analogix_dp_rockchip]) >> It try to enable the eDP aux channel and add a new I2C controller, but it >> failed then the whole display subsystem is broken, the panel doesn't power >> on either. >> >> I hope somebody could figure out what is wrong with it. > > Hi Randy, > > you want to debug why the call to of_modalias_node fails. > But I didn't know who register that I2C controller, as the system only have 6 I2C controller(0-5). > Good luck, > > Tomeu > > >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Randy Li The third produce department === This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
the dp helper would try to enable the i2c channel for rockchip-edp
Hello, Recently, I want to use a eDP panel in my RK3288 platform, but I got the following message: [8.935918] i2c i2c-6: of_i2c: modalias failure on /dp at ff97/ports [8.936018] rockchip-drm display-subsystem: bound ff97.dp (ops rockchip_dp_component_ops [analogix_dp_rockchip]) It try to enable the eDP aux channel and add a new I2C controller, but it failed then the whole display subsystem is broken, the panel doesn't power on either. I hope somebody could figure out what is wrong with it.
About the Xserver for rockchip
On 10/17/2016 04:02 PM, Mark yao wrote: > On 2016å¹´10æ17æ¥ 15:12, Heiko Stuebner wrote: >> Am Montag, 17. Oktober 2016, 14:45:30 CEST schrieb Randy Li: >>> Hello Tomasz: >>>Heiko told me you are in charge of the graphics part of chromium, I >>> think I had better told you the developing status of the xorg xserver in >>> rockchip. >> What I actually said was that Tomasz did the original VPU driver used on >> veyron chromebooks, so may be interested in your current work on that >> :-) . Yes, I am rewriting the VPU driver. The last topic is something different ideas from chromium's decoder settings API in linux-media >> >> Also ChromeOS moved from X11 to use Freon instead, so I'm not sure if >> ChromeOS >> cares about that anymore. And Mark is thinking about moving forward to wayland. >> >>> Currently the graphics department released a modification >>> version of xserver which would support the libMali, but the way to >>> support it is some kind of hacker which disabled the original mesa gl >>> support. >>> https://github.com/rockchip-linux/xserver/commit/bae12718e76d50d7388a93a251e >>> >>> f6777f6ca4850#diff-92a9ba7d51895d2d69c5c893fa0f658dL792 >>> >>> Since the code base of that is really a mess, I rebase the branch >>> rockchip with the xserver branch 1.18 from upstream, it is there >>> https://github.com/rockchip-linux/xserver/tree/rockchip-1.18 >>> But the version I made would omit some pixels when it is drawing, I have >>> not found out why. >> Didn't Mark do a lot of changes on your xserver, so maybe he knows >> what might >> be going wrong? > > I don't what the problem it's, I haven't a chance to try Randy's issue yet. > > Hi Randy > > Did you re-test it with this patch: > https://github.com/rockchip-linux/xserver/commit/bfee8067608b9dcbf6dae0ed897ae1295fdef7f2 No, I have merged that patch in my branch, just forget to push it recently it. Your branch works fine now, it may be caused some mistakes when I was rebasing. It is not serious problem for now. > > > Thanks. > >> >> >> Heiko >> >> >> > > -- Randy Li The third produce department === This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
About the Xserver for rockchip
Hello Tomasz: Heiko told me you are in charge of the graphics part of chromium, I think I had better told you the developing status of the xorg xserver in rockchip. Currently the graphics department released a modification version of xserver which would support the libMali, but the way to support it is some kind of hacker which disabled the original mesa gl support. https://github.com/rockchip-linux/xserver/commit/bae12718e76d50d7388a93a251ef6777f6ca4850#diff-92a9ba7d51895d2d69c5c893fa0f658dL792 Since the code base of that is really a mess, I rebase the branch rockchip with the xserver branch 1.18 from upstream, it is there https://github.com/rockchip-linux/xserver/tree/rockchip-1.18 But the version I made would omit some pixels when it is drawing, I have not found out why. -- Randy Li The third produce department === This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
rockchip: drm: analogix_dp-rockchip would stock the kernel
On 10/17/2016 08:57 AM, Mark yao wrote: > On 2016å¹´10æ16æ¥ 02:03, ayaka wrote: >> 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]) > > Hi ayaka > > This log seems no problem. I found the problem, it is the eDP_AVDD_1V0 and eDP_AVDD_1V8 must have a proper power supply. I would submit a patch to enable the regulator at DP driver. > > How about tested it with build-in? we had test it with build-in. > > Maybe this patch can help you, you can have a try. > https://patchwork.kernel.org/patch/9374135 > > Thanks. > >> 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 >> >> >> > > -- Randy Li The third produce department === This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
[RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
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"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f178998..3204e6b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -583,6 +583,30 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
+ .clock = 66770,
+ .hdisplay = 800,
+ .hsync_start = 800 + 49,
+ .hsync_end = 800 + 49 + 33,
+ .htotal = 800 + 49 + 33 + 17,
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 1,
+ .vsync_end = 1280 + 1 + 7,
+ .vtotal = 1280 + 1 + 7 + 15,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc chunghwa_claa070wp03xg = {
+ .modes = _claa070wp03xg_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 94,
+ .height = 150,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -1544,6 +1568,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+ .compatible = "chunghwa,claa070wp03xg",
+ .data = _claa070wp03xg,
+ }, {
.compatible = "chunghwa,claa101wa01a",
.data = _claa101wa01a
}, {
--
2.7.4
[RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
It is actually a lvds panel connected through a rga-lvds bridge.
The touchscreen is communicated with i2c bus but the driver is not
support now.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++--
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts
b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index b08705e..5153522 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -138,6 +138,36 @@
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 at 0 {
+ compatible = "chunghwa,claa070wp03xg";
+
+ power-supply = <_sys_lcd>;
+ enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ backlight = <>;
+
+ port {
+ lcd_ep: endpoint {
+ remote-endpoint = <_lvds>;
+ };
+ };
+ };
+
+ bl: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 1 500 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 5 12 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <_sys_lcd>;
+ };
};
{
@@ -171,11 +201,31 @@
assigned-clock-rates = <0>, <17600>;
};
+ {
+ pinctrl-0 = <_clk _data24>;
+ pinctrl-names = "default";
+ status = "okay";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 3 {
+ reg = <3>;
+ rga_lvds: endpoint {
+ remote-endpoint = <_ep>;
+ };
+ };
+ };
+};
+
{
dr_mode = "peripheral";
status = "okay";
};
+_3 {
+ status = "okay";
+};
+
_4 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -215,9 +265,9 @@
{
status = "okay";
- pinctrl-0 = <_out>;
+ pinctrl-0 = <_out _out>;
pinctrl-names = "default";
- samsung,pwm-outputs = <0>;
+ samsung,pwm-outputs = <0>, <1>;
};
_2 {
--
2.7.4
[RFC PATCH v3 0/2] adding panel claa070wp03xg support for exynos
The timings issue is still here, this version is just some modifications in dts file. Randy Li (2): ARM: dts: samsung: add rga-lvds panel in itop elite drm/panel: Add support for Chunghwa CLAA070WP03XG panel .../display/panel/chunghwa,claa070wp03xg.txt | 7 +++ arch/arm/boot/dts/exynos4412-itop-elite.dts| 54 +- drivers/gpu/drm/panel/panel-simple.c | 27 +++ 3 files changed, 86 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt -- 2.7.4
[RFC PATCH v2 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
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"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f178998..3204e6b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -583,6 +583,30 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
+ .clock = 66770,
+ .hdisplay = 800,
+ .hsync_start = 800 + 49,
+ .hsync_end = 800 + 49 + 33,
+ .htotal = 800 + 49 + 33 + 17,
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 1,
+ .vsync_end = 1280 + 1 + 7,
+ .vtotal = 1280 + 1 + 7 + 15,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc chunghwa_claa070wp03xg = {
+ .modes = _claa070wp03xg_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 94,
+ .height = 150,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -1544,6 +1568,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+ .compatible = "chunghwa,claa070wp03xg",
+ .data = _claa070wp03xg,
+ }, {
.compatible = "chunghwa,claa101wa01a",
.data = _claa101wa01a
}, {
--
2.7.4
[RFC PATCH v2 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
It is actually a lvds panel connected through a rga-lvds bridge.
The touchscreen is communicated with i2c bus but the driver is not
support now.
Signed-off-by: Randy Li
---
arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++--
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts
b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index b08705e..9ef0505 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -138,6 +138,36 @@
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 at 0 {
+ compatible = "chunghwa,claa070wp03xg";
+
+ power-supply = <_sys_lcd>;
+ enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ backlight = <>;
+
+ port {
+ lcd_ep: endpoint {
+ remote-endpoint = <_lvds>;
+ };
+ };
+ };
+
+ bl: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 1 500 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 5 12 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <_sys_lcd>;
+ };
};
{
@@ -215,9 +245,9 @@
{
status = "okay";
- pinctrl-0 = <_out>;
+ pinctrl-0 = <_out _out>;
pinctrl-names = "default";
- samsung,pwm-outputs = <0>;
+ samsung,pwm-outputs = <0>, <1>;
};
_2 {
@@ -238,3 +268,23 @@
_2 {
status = "okay";
};
+
+_3 {
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_clk _data24>;
+ pinctrl-names = "default";
+ status = "okay";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 3 {
+ reg = <3>;
+ rga_lvds: endpoint {
+ remote-endpoint = <_ep>;
+ };
+ };
+ };
+};
--
2.7.4
[RFC PATCH v2 0/2] adding panel claa070wp03xg support for exynos
I am trying to add LCD panel with LVDS interface for exynos 4412 topeet
itop. That board using a bridge chip to convert the parallel RGB signal
to LVDS signal. I could make a fb0 node appear in system now. But I can't
make it work yet. redirecting the urandom to fb0 won't make anything
change in panel.
The timing for this panel is calcuated from Hyundai T7, but it looks
different to the vendor's kernel. But those timings settings is disabled, so
I decided not to use it.
I attach them as references:
/* From Hyundai T7 */
static struct s3cfb_lcd hs101h = {
.width = 1280,
.height = 800,
.bpp = 24,
.freq = 60,
.timing = {
.h_fp = 49,
.h_bp = 17,
.h_sw = 33,
.v_fp = 4,
.v_fpe = 1,
.v_bp = 15,
.v_bpe = 1,
.v_sw = 6,
},
.polarity = {
.rise_vclk = 0,
.inv_hsync = 1,
.inv_vsync = 1,
.inv_vden = 0,
},
};
/* From vendor */
static struct s3cfb_lcd dummy_mipi_lcd = {
.width = 800,
.height = 1280,
.bpp = 24,
.freq = 60,
.timing = {
.h_fp = 16,
.h_bp = 140,
.h_sw = 14,
.v_fp = 8,
//.v_fpe = 2,
.v_bp = 4,
//.v_bpe = 1,
.v_sw = 4,
.cmd_allow_len = 4,
},
.polarity = {
.rise_vclk = 0,
.inv_hsync = 0,
.inv_vsync = 0,
.inv_vden = 0,
},
}
Randy Li (2):
ARM: dts: samsung: add rga-lvds panel in itop elite
drm/panel: Add support for Chunghwa CLAA070WP03XG panel
.../display/panel/chunghwa,claa070wp03xg.txt | 7 +++
arch/arm/boot/dts/exynos4412-itop-elite.dts| 54 +-
drivers/gpu/drm/panel/panel-simple.c | 27 +++
3 files changed, 86 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
--
2.7.4
[PATCH RFC] ARM: dts: samsung: add rga-lvds panel in itop elite
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>;
+ };
};
_1 {
@@ -221,9 +235,6 @@
};
{
- pinctrl-0 = <_out>;
- pinctrl-names = "default";
- samsung,pwm-outputs = <1>;
status = "okay";
};
@@ -239,3 +250,21 @@
assigned-clock-parents = < CLK_MOUT_MPLL_USER_T>;
assigned-clock-rates = <0>, <17600>;
};
+
+_3 {
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_clk _data24 _out>;
+ pinctrl-names = "default";
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 {
+ reg = <0>;
+ rga_lvds: endpoint {
+ remote-endpoint = <>;
+ };
+ };
+};
--
2.7.4
Plan to support Rockchip VPU in DRM, is it a good idea
On 08/26/2016 06:56 PM, Hans Verkuil wrote: > On 08/26/2016 12:05 PM, Randy Li wrote: >> >> On 08/26/2016 05:34 PM, Hans Verkuil wrote: >>> Hi Randi, >>> >>> On 08/26/2016 04:13 AM, Randy Li wrote: >>>> Hello, >>>> We always use some kind of hack work to make our Video Process >>>> Unit(Multi-format Video Encoder/Decoder) work in kernel. From a >>>> customize driver(vpu service) to the customize V4L2 driver. The V4L2 >>>> subsystem is really not suitable for the stateless Video process or it >>>> could make driver too fat. >>>> After talking to some kindness Intel guys and moving our userspace >>>> library to VA-API driver, I find the DRM may the good choice for us. >>>> But I don't know whether it is welcome to to submit a video driver in >>>> DRM subsystem? >>>> Also our VPU(Video process unit) is not just like the Intel's, we >>>> don't have VCS, we based on registers to set the encoder/decoder. I >>>> think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU >>>> but also not a isolated memory for VPU, I don't know I should use TT >>>> memory or GEM memory. >>>> I am actually not a member of the department in charge of VPU, and I >>>> am just beginning to learning DRM(thank the help from Intel again), I am >>>> not so good at memory part as well(I am more familiar with CMA not the >>>> IOMMU way), I may need know guide about the implementations when I am >>>> going to submit driver, I hope I could get help from someone. >>>> >>> It makes no sense to do this in the DRM subsystem IMHO. There are already >>> quite a few HW codecs implemented in the V4L2 subsystem and more are in the >>> pipeline. Putting codec support in different subsystems will just make >>> userspace software much harder to write. >>> >>> One of the codecs that was posted to linux-media was actually from Rockchip: >>> >>> https://lkml.org/lkml/2016/2/29/861 >>> >>> There is also a libVA driver (I think) that sits on top of it: >>> >>> https://github.com/rockchip-linux/rockchip-va-driver/tree/v4l2-libvpu >> It is old version, I am the author of this >> https://github.com/rockchip-linux/rockchip-va-driver >>> For the Allwinner a patch series was posted yesterday: >>> >>> https://lkml.org/lkml/2016/8/25/246 >>> >>> They created a pretty generic libVA userspace that looks very promising at >>> first glance. >>> >>> What these have in common is that they depend on the Request API and Frame >>> API, >>> neither of which has been merged. The problem is that the Request API >>> requires >>> more work since not only controls have to be part of a request, but also >>> formats, >>> selection rectangles, and even dynamic routing changes. While that is not >>> relevant >>> for codecs, it is relevant for Android CameraHAL in general and complex >>> devices >>> like Google's Project Ara. >> Actually just as the Intel did, our hardware decoder/encoder need full >> settings for them, most of them are relevant to the codec. You may >> notice that there is four extra control need to be set before. If the >> libvpu(a helper library we offered to parse each slice to generate >> decoder settings) is remove(in process now, only three decoder settings >> can't got from VA-API directly), it would be more clearly. >> We really a lots decoder settings information to make the decoder work. >>> This is being worked on, but it is simply not yet ready. The core V4L2 >>> developers >>> involved in this plan to discuss this on the Monday before the ELCE in >>> Berlin, >>> to see if we can fast track this work somehow so this support can be merged. >>> >> I am glad to hear that. I hope that I could have an opportunity to show >> our problems. >>> If there are missing features in V4L2 (other that the two APIs discussed >>> above) >>> that prevent you from creating a good driver, then please discuss that with >>> us. >>> We are always open to suggestions and improvements and want to work with >>> you on >>> that. >> I have a few experience with the s5p-mfc, and I do wrote a V4L2 encoder >> plugin for Gstreamer. I don't think the V4L2 is good place for us >> stateless video processor, unless it would break the present implementation. >> >> The stateful and stat
Plan to support Rockchip VPU in DRM, is it a good idea
On 08/26/2016 05:34 PM, Hans Verkuil wrote: > Hi Randi, > > On 08/26/2016 04:13 AM, Randy Li wrote: >> Hello, >>We always use some kind of hack work to make our Video Process >> Unit(Multi-format Video Encoder/Decoder) work in kernel. From a >> customize driver(vpu service) to the customize V4L2 driver. The V4L2 >> subsystem is really not suitable for the stateless Video process or it >> could make driver too fat. >>After talking to some kindness Intel guys and moving our userspace >> library to VA-API driver, I find the DRM may the good choice for us. >> But I don't know whether it is welcome to to submit a video driver in >> DRM subsystem? >>Also our VPU(Video process unit) is not just like the Intel's, we >> don't have VCS, we based on registers to set the encoder/decoder. I >> think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU >> but also not a isolated memory for VPU, I don't know I should use TT >> memory or GEM memory. >>I am actually not a member of the department in charge of VPU, and I >> am just beginning to learning DRM(thank the help from Intel again), I am >> not so good at memory part as well(I am more familiar with CMA not the >> IOMMU way), I may need know guide about the implementations when I am >> going to submit driver, I hope I could get help from someone. >> > > It makes no sense to do this in the DRM subsystem IMHO. There are already > quite a few HW codecs implemented in the V4L2 subsystem and more are in the > pipeline. Putting codec support in different subsystems will just make > userspace software much harder to write. > > One of the codecs that was posted to linux-media was actually from Rockchip: > > https://lkml.org/lkml/2016/2/29/861 > > There is also a libVA driver (I think) that sits on top of it: > > https://github.com/rockchip-linux/rockchip-va-driver/tree/v4l2-libvpu It is old version, I am the author of this https://github.com/rockchip-linux/rockchip-va-driver > > For the Allwinner a patch series was posted yesterday: > > https://lkml.org/lkml/2016/8/25/246 > > They created a pretty generic libVA userspace that looks very promising at > first glance. > > What these have in common is that they depend on the Request API and Frame > API, > neither of which has been merged. The problem is that the Request API requires > more work since not only controls have to be part of a request, but also > formats, > selection rectangles, and even dynamic routing changes. While that is not > relevant > for codecs, it is relevant for Android CameraHAL in general and complex > devices > like Google's Project Ara. Actually just as the Intel did, our hardware decoder/encoder need full settings for them, most of them are relevant to the codec. You may notice that there is four extra control need to be set before. If the libvpu(a helper library we offered to parse each slice to generate decoder settings) is remove(in process now, only three decoder settings can't got from VA-API directly), it would be more clearly. We really a lots decoder settings information to make the decoder work. > > This is being worked on, but it is simply not yet ready. The core V4L2 > developers > involved in this plan to discuss this on the Monday before the ELCE in Berlin, > to see if we can fast track this work somehow so this support can be merged. > I am glad to hear that. I hope that I could have an opportunity to show our problems. > If there are missing features in V4L2 (other that the two APIs discussed > above) > that prevent you from creating a good driver, then please discuss that with > us. > We are always open to suggestions and improvements and want to work with you > on > that. I have a few experience with the s5p-mfc, and I do wrote a V4L2 encoder plugin for Gstreamer. I don't think the V4L2 is good place for us stateless video processor, unless it would break the present implementation. The stateful and stateless are operated quite differently. The stateless must parse the header and set those settings for every frames. The request data may quite different from vendor to vendor, even chip to chip. It is impossible to make a common way to send those settings to driver.For the samsung MFC, you don't need to do any parse work at all. Anyway, I would like to follow what Intel does now, we are both stateless video processor. > > Regards, > > Hans > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Randy Li The third produce department
Plan to support Rockchip VPU in DRM, is it a good idea
Hello, We always use some kind of hack work to make our Video Process Unit(Multi-format Video Encoder/Decoder) work in kernel. From a customize driver(vpu service) to the customize V4L2 driver. The V4L2 subsystem is really not suitable for the stateless Video process or it could make driver too fat. After talking to some kindness Intel guys and moving our userspace library to VA-API driver, I find the DRM may the good choice for us. But I don't know whether it is welcome to to submit a video driver in DRM subsystem? Also our VPU(Video process unit) is not just like the Intel's, we don't have VCS, we based on registers to set the encoder/decoder. I think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU but also not a isolated memory for VPU, I don't know I should use TT memory or GEM memory. I am actually not a member of the department in charge of VPU, and I am just beginning to learning DRM(thank the help from Intel again), I am not so good at memory part as well(I am more familiar with CMA not the IOMMU way), I may need know guide about the implementations when I am going to submit driver, I hope I could get help from someone. -- Randy Li The third produce department
I want to use VA-API to support new platform, I want know something about Intel implementation
On 08/24/2016 11:35 PM, Xiang, Haihao wrote: > > >> -Original Message----- >> From: Randy Li [mailto:randy.li at rock-chips.com] >> Sent: Wednesday, August 24, 2016 6:30 PM >> To: Xiang, Haihao ; libva at lists.freedesktop.org >> Cc: nicolas.dufresne at collabora.co.uk; Balachandran, Sreerenj >> >> Subject: Re: I want to use VA-API to support new platform, I want know >> something about Intel implementation >> >> >> >> On 08/18/2016 10:31 AM, Xiang, Haihao wrote: >>> >>> Hi Randy, >>> >>> You can get lots of information / docs via internet. You may search for >>> dri, libdrm, drm, gem, i915 etc. >>> >>> dri wiki >>> https://dri.freedesktop.org/wiki/ >>> >>> drm: >>> https://en.wikipedia.org/wiki/Direct_Rendering_Manager >>> >>> libdrm: >>> https://01.org/linuxgraphics/community/libdrm >>> >>> intel graphics kernel >>> https://01.org/linuxgraphics/community/kernel >> I have read the documents you offered to me, I have a basic view of them >> and the relationship of them. >> >> But I want to know more about the detail of Intel implementation.I have >> read the Intel driver of VA-API before, I think the Intel video process >> video in this way. >> 1. Allocate the DRI buffer from the kernel driver using the libdrm. > > It is a GEM buffer object in intel driver. > >> 2. Intel DRM driver in kernel would allocate buffer throught the GEM. >> 3. Intel VA-API driver push the codec data and parameters to those buffers > > And setup the corresponding pipeline in a batch buffer which is also a gem > buffer object and submit this batch buffer > to i915 driver via libdrm. The batch buffer will be chained into a ring > buffer via MI_BATCH_BUFFER_START command > for execution. It seems that it is only used by MFC(video encoder)? I saw the MFD use MFX_IND_OBJ_BASE_ADDR_STATE followed with the OUT_BCS_RELOC which would render the slice data into MFD? You can refer to https://01.org/linuxgraphics/documentation/hardware-specification-prms (Programmer's > Reference Manuals) for how do ring buffer and batch buffer work. Intel implementation is really really complex to me. But After a quick read and read volume 8 deeply, I know that the MFX doesn't based on register at all. So you need to push and MFC codec commands and those decoding information to VCS, the VCS would decide and parse how to execute those data. Is that right? Our rockchip would still use the registers on a video IP to store the decoder settings for the picture to be process, we may not choose the same implementation, but I could still map the register range to the memory, using a buffer to set them at the same time. Anyway, that explains why I didn't see any register about video codec in Linux kernel DRM driver, becuase Intel MFX is not based on it. The Intel driver at kernel just need the allocate and manage the buffer for the VCS, then most of work could be move to libdrm and VA-API driver. That is really great for stateless video processor. > >> 4. Got result from DRI buffer. >> >> Is it correct ? >> >> If it is correct, does it mean that the registers(used for configure >> decoding parameters) at Intel video processing unit would be mapped as >> PRIME buffers to be used in DRI? >> And where is the kernel driver do that ? I know it is easy to find the >> DRM driver in linux kernel in drivers/gpu/drm/i915/ , but which file is >> doing the job for video processing part? They looks like the graphics >> to me. I think different Intel platform generation would have a >> different registers. >> >>> >>> Hope it can help you. >>> >>> Thanks >>> Haihao >>> >>> >>>> Hi all >>>>I am using VA-API to support the Video Process Unit in a ARM >>>> platform, but it didn't use the standard kernel interface. Without >>>> the >>>> help of DRI, I can't implement something like vaDeriveImage() leading >>>> a lose in performance. >>>> I read the Intel driver, it looks the Intel driver could access >>>> the >>>> the Memory of Video Unit of Intel Graphics card through the libdrm. >>>> If that is right, could somebody told me how does it implemented in >>>> linux kernel(which files?). >>>> And I am really newbies to this area(DRI), could somebody give me >>>> guide and documents about this? >>>>Thank you all very much. >> >> Thank you so much. >> -- >> Randy Li >> The third produce department > Thank you for help, it is really a great work what Intel have done. -- Randy Li The third produce department
