Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On 05/26/2017 12:18 AM, Daniel Vetter wrote:
On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/Kconfig | 3 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_dp_cec.c | 196 +++
include/drm/drm_dp_helper.h | 24 ++
4 files changed, 224 insertions(+)
create mode 100644 drivers/gpu/drm/drm_dp_cec.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 78d7fc0ebb57..dd771ce8a3d0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE
default case is N. Details and instructions how to build your own
EDID data are given in Documentation/EDID/HOWTO.txt.
+config DRM_DP_CEC
+ bool
We generally don't bother with a Kconfig for every little bit in drm, not
worth the trouble (yes I know there's some exceptions, but somehow they're
all from soc people). Just smash this into the KMS_HELPER one and live is
much easier for drivers. Also allows you to drop the dummy inline
functions.
All of the functions like cec_register_adapter() require
CONFIG_MEDIA_CEC_SUPPORT.
This will add a new dependency to the DRM drivers. All instances of
CONFIG_DRM_DP_CEC should be changed to CONFIG_MEDIA_CEC_SUPPORT so drm
can still be used without the media CEC drivers.
-Clint
The other nitpick: Pls kernel-doc the functions exported to drivers, and
then pull them into Documentation/gpu/drm-kms-helpers.rst, next to the
existing DP helper section.
Thanks, Daniel
+
config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 59f0f9b696eb..22f1a17dfc8a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -34,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
drm_probe_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
drm_scdc_helper.o
+drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
new file mode 100644
index ..44c544ba53cb
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,196 @@
+/*
+ * DisplayPort CEC-Tunneling-over-AUX support
+ *
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+ struct drm_dp_aux *aux = cec_get_drvdata(adap);
+ ssize_t err = 0;
+
+ if (enable)
+ err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL,
+DP_CEC_TUNNELING_ENABLE);
+ else
+ err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, 0);
+ return (enable && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
+{
+ struct drm_dp_aux *aux = cec_get_drvdata(adap);
+ u8 mask[2] = { 0x00, 0x80 };
+ ssize_t err;
+
+ if (addr != CEC_LOG_ADDR_INVALID) {
+ u16 la_mask = adap->log_addrs.log_addr_mask;
+
+ la_mask |= 0x8000 | (1 << addr);
+ mask[0] = la_mask & 0xff;
+ mask[1] = la_mask >> 8;
+ }
+ err = drm_dp_dpcd_write(aux, DP_CEC_LOGICAL_ADDRESS_MASK, mask, 2);
+ return (addr != CEC_LOG_ADDR_INVALID && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
+ u32 signal_free_time, struct cec_msg *msg)
+{
+ struct drm_dp_aux *aux = cec_get_drvdata(adap);
+ unsigned in
Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/30/2017 02:29 PM, Hans Verkuil wrote: On 05/30/2017 10:32 PM, Clint Taylor wrote: On 05/30/2017 09:54 AM, Hans Verkuil wrote: On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring this up for dp mst chains? Isn't this sufficient? I have no way of testing mst chains. I think I need some pointers from you, since I am a complete newbie when it comes to mst. I don't really have more clue, but yeah if you don't have an mst thing (a simple dp port multiplexer is what I use for testing here, then plug in a converter dongle or cable into that) then probably better to not wire up the code for it. I think my NUC already uses mst internally. But I was planning on buying a dp multiplexer to make sure there is nothing special I need to do for mst. The CEC Tunneling is all in the branch device, so if I understand things correctly it is not affected by mst. BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they use a MegaChip MCDP2800 DP-to-HDMI converter which according to their datasheet is supposed to implement CEC Tunneling, but if they do it is not exposed as a capability. I'm not sure if it is a MegaChip firmware issue or something else. The BIOS is able to do some CEC, but whether they hook into the MegaChip or have the CEC pin connected to a GPIO or something and have their own controller is something I do not know. If anyone can clarify what Intel did on the NUC, then that would be very helpful. It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI 2.0. Currently we only use it in PCON mode, shows up as DP for us. It could be used in LS mode, showing up as HDMI 1.4, but we don't support that in i915. I don't know about the CEC on that. My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. The release notes for the NUC state that there is a BIOS configuration option for enabling support. My doesn't have the option but the LSPCON fully supports CEC. What is the output of: dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48 od -t x1 aux0 Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC. If the first byte is != 0x00, then it advertises CEC over Aux. For me it says 0x00. When you say "it does support CEC over Aux", does that mean you have actually tested it somehow? The only working solution I have seen mentioned for the NUC6i7KYK is a Pulse-Eight adapter. With the NUC7i Intel made BIOS support for CEC, but it is not at all clear to me if they used CEC tunneling or just hooked up the CEC pin to some microcontroller. The only working chipset I have seen is the Parade PS176. If it really is working on your NUC, then can you add the output of /sys/kernel/debug/dri/0/i915_display_info? [root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info Connector info -- connector 48: type DP-1, status: connected name: physical dimensions: 700x400mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: 175IB0 HW: 1.0 SW: 7.32 Max TMDS clock: 60 kHz Max bpc: 12 Huh. Based on this document: https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf this is the internal DP-to-HDMI adapter and it has the PS175. So it is a Parade chipset, and I have seen that work before (at least the PS176). This is the PS175 LSPCON on the NUC6. connector 55: type DP-2, status: connected name: physical dimensions: 620x340mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: BCTRC0 HW: 2.0 SW: 0.26 And is this from a USB-C to HDMI adapter? Which one? I don't recognize the ID. This is a LSPCON inside the Google USB-C->HDMI dongle. This is actually a MC2850 with what appears to be a custom ID. Datasheet claims CEC over Aux and the pin is wired, but FW has it currently disabled. -Clint For the record, this is the internal HDMI output of my NUC7i5BNK: connector 48: type DP-1, status: connected name: physical dimensions: 1050x590mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: MC2800 HW: 2.2 SW: 1.66 Max TMDS clock: 60 kHz Max bpc: 16 Clearly a Megachip. Regards, Hans
Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/30/2017 09:54 AM, Hans Verkuil wrote: On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring this up for dp mst chains? Isn't this sufficient? I have no way of testing mst chains. I think I need some pointers from you, since I am a complete newbie when it comes to mst. I don't really have more clue, but yeah if you don't have an mst thing (a simple dp port multiplexer is what I use for testing here, then plug in a converter dongle or cable into that) then probably better to not wire up the code for it. I think my NUC already uses mst internally. But I was planning on buying a dp multiplexer to make sure there is nothing special I need to do for mst. The CEC Tunneling is all in the branch device, so if I understand things correctly it is not affected by mst. BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they use a MegaChip MCDP2800 DP-to-HDMI converter which according to their datasheet is supposed to implement CEC Tunneling, but if they do it is not exposed as a capability. I'm not sure if it is a MegaChip firmware issue or something else. The BIOS is able to do some CEC, but whether they hook into the MegaChip or have the CEC pin connected to a GPIO or something and have their own controller is something I do not know. If anyone can clarify what Intel did on the NUC, then that would be very helpful. It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI 2.0. Currently we only use it in PCON mode, shows up as DP for us. It could be used in LS mode, showing up as HDMI 1.4, but we don't support that in i915. I don't know about the CEC on that. My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. The release notes for the NUC state that there is a BIOS configuration option for enabling support. My doesn't have the option but the LSPCON fully supports CEC. What is the output of: dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48 od -t x1 aux0 Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC. If the first byte is != 0x00, then it advertises CEC over Aux. For me it says 0x00. When you say "it does support CEC over Aux", does that mean you have actually tested it somehow? The only working solution I have seen mentioned for the NUC6i7KYK is a Pulse-Eight adapter. With the NUC7i Intel made BIOS support for CEC, but it is not at all clear to me if they used CEC tunneling or just hooked up the CEC pin to some microcontroller. The only working chipset I have seen is the Parade PS176. If it really is working on your NUC, then can you add the output of /sys/kernel/debug/dri/0/i915_display_info? [root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info CRTC info - CRTC 32: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24 fb: 115, pos: 0x0, size: 3840x2160 encoder 47: type: DDI B, connectors: connector 48: type: DP-1, status: connected, mode: id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5 cursor visible? no, position (0, 0), size 0x0, addr 0x num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0 --Plane id 26: type=PRI, crtc_pos= 0x 0, crtc_size=1920x1080, src_pos=0.x0., src_size=1920.x1080., format=XR24 little-endian (0x34325258), rotation=0 (0x0001) --Plane id 28: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 (0x0001) --Plane id 30: type=CUR, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 (0x0001) underrun reporting: cpu=yes pch=yes CRTC 39: pipe: B, active=yes, (size=3840x2160), dither=no, bpp=36 fb: 115, pos: 0x0, size: 3840x2160 encoder 54: type: DDI C, connectors: connector 55: type: DP-2, status: connected, mode: id 0:"3840x2160" freq 30 clock 296703 hdisp 3840 hss 4016 hse 4104 htot 4400 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x48 flags 0x5 cursor visible? no, position (0, 0), size 0x0, addr 0x num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0 --Plane id 33: type=PRI, crtc_pos= 0x 0, crtc_size=3840x2160, src_pos=0.x0., src_size=3840.x2160., format=XR24 little-endian (0x34325258), rotation=0 (0x0001) --Plane id 35: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.00
Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/30/2017 09:49 AM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
Did you look into also wiring this up for dp mst chains?
Isn't this sufficient? I have no way of testing mst chains.
I think I need some pointers from you, since I am a complete
newbie when it
comes to mst.
I don't really have more clue, but yeah if you don't have an mst
thing (a
simple dp port multiplexer is what I use for testing here, then
plug in a
converter dongle or cable into that) then probably better to not
wire up
the code for it.
I think my NUC already uses mst internally. But I was planning on
buying a
dp multiplexer to make sure there is nothing special I need to do
for mst.
The CEC Tunneling is all in the branch device, so if I understand
things
correctly it is not affected by mst.
BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output
they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it
is not
exposed as a capability. I'm not sure if it is a MegaChip firmware
issue
or something else. The BIOS is able to do some CEC, but whether
they hook
into the MegaChip or have the CEC pin connected to a GPIO or
something and
have their own controller is something I do not know.
If anyone can clarify what Intel did on the NUC, then that would be
very
helpful.
It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.
I don't know about the CEC on that.
My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.
What is the output of:
dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0
Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.
If the first byte is != 0x00, then it advertises CEC over Aux.
For me it says 0x00.
slightly different command, but it still dumps DPCD 0x3000 for 48 bytes.
sudo dd if=/dev/drm_dp_aux0 bs=1 skip=12288 count=48 | hexdump -C
07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
||
0010 f8 23 c4 8f 06 d8 59 7b 37 bb 1e 14 9c cb cd 88
|.#Y{7...|
0020 4e 84 10 00 04 00 f7 f5 e2 fa a3 30 ad 42 ed 19
|N..0.B..|
When you say "it does support CEC over Aux", does that mean you have
actually
tested it somehow? The only working solution I have seen mentioned for
the
NUC6i7KYK is a Pulse-Eight adapter.
With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.
The only working chipset I have seen is the Parade PS176.
I have a couple PS176 based devices that I purchased from Amazon that do
not work even though they advertise support at DPCD 0x3000.
Club 3D USB-C->HDMI 2.0 UHD
UptabUSB-C->HDMI 2.0
-Clint
Regards,
Hans
-Clint
BR,
Jani.
It would be so nice to get MegaChip CEC Tunneling working on the
NUC, because
then you have native CEC support without requiring any Pulse Eight
adapter.
And add a CEC-capable USB-C to HDMI adapter and you have it on the
USB-C
output as well.
Regards,
Hans
Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring this up for dp mst chains? Isn't this sufficient? I have no way of testing mst chains. I think I need some pointers from you, since I am a complete newbie when it comes to mst. I don't really have more clue, but yeah if you don't have an mst thing (a simple dp port multiplexer is what I use for testing here, then plug in a converter dongle or cable into that) then probably better to not wire up the code for it. I think my NUC already uses mst internally. But I was planning on buying a dp multiplexer to make sure there is nothing special I need to do for mst. The CEC Tunneling is all in the branch device, so if I understand things correctly it is not affected by mst. BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they use a MegaChip MCDP2800 DP-to-HDMI converter which according to their datasheet is supposed to implement CEC Tunneling, but if they do it is not exposed as a capability. I'm not sure if it is a MegaChip firmware issue or something else. The BIOS is able to do some CEC, but whether they hook into the MegaChip or have the CEC pin connected to a GPIO or something and have their own controller is something I do not know. If anyone can clarify what Intel did on the NUC, then that would be very helpful. It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI 2.0. Currently we only use it in PCON mode, shows up as DP for us. It could be used in LS mode, showing up as HDMI 1.4, but we don't support that in i915. I don't know about the CEC on that. My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. The release notes for the NUC state that there is a BIOS configuration option for enabling support. My doesn't have the option but the LSPCON fully supports CEC. -Clint BR, Jani. It would be so nice to get MegaChip CEC Tunneling working on the NUC, because then you have native CEC support without requiring any Pulse Eight adapter. And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C output as well. Regards, Hans
Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
On 03/26/2017 09:05 PM, Ayaka wrote:
從我的 iPad 傳送
Ander Conselvan De Oliveira 於 2017年3月14日 下午9:53 寫道：
On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
從我的 iPad 傳送
Ville Syrjälä 於 2017年3月7日 上午2:34 寫道：
On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
從我的 iPad 傳送
Ville Syrjälä 於 2017年3月6日 下午9:06 寫道：
On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format.
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.
V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.
What? Why? You just undid what Clint did in v6.
He missed a file also keeping the wrong description of rockchip.
I don't follow. Who missed what exactly?
What he sent is v5, I increase the order number twice in the message, it
confuse me as well.
I think Clint forgot the include/uapi/drm/drm_fourcc.h .
Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
https://patchwork.freedesktop.org/patch/141342/
Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
since I think the V is after the U.
From the MSDN fourcc website:
"If the combined U-V array is addressed as an array of DWORDs, the least
significant word (LSW) contains the U value and the most significant
word (MSW) contains the V value. The stride of the combined U-V plane is
equal to the stride of the Y plane. The U-V plane has half as many lines
as the Y plane."
The LSW contains U and the MSW contains V, hence the Cr:Cb in the
comments of the V6 patch.
-Clint
Ander
Cc: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Randy Li
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0, .num_planes = 1, .cpp = {
2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0, .num_planes = 1, .cpp = {
2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0, .num_planes = 1, .cpp = {
4, 0, 0 }, .hsub = 1, .vsub = 1 },
+{ .format = DRM_FORMAT_P010,.depth = 0, .num_planes = 2, .cpp
= { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+{ .format = DRM_FORMAT_P012,.depth = 0, .num_planes = 2, .cpp
= { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+{ .format = DRM_FORMAT_P016,.depth = 0, .num_planes = 2, .cpp
= { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@ extern "C" {
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4
--
Ville Syrjälä
Intel OTC
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
