* [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
@ 2017-05-25 15:06 Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 1/7] cec: add CEC_CAP_NEEDS_HPD Hans Verkuil
` (8 more replies)
0 siblings, 9 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Jani Nikula, Daniel Vetter
From: Hans Verkuil <hans.verkuil@cisco.com>
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
protocol.
This patch series is based on v4.12-rc2.
The first four patches add support for a new CEC capability which is
needed for these devices and for two helper functions.
Then the DP CEC registers are added using Clint's patch.
The core CEC tunneling support is added to drm_dp_cec.c.
And finally this is hooked up in the i915 driver.
Ideally the cec driver is created and destroyed whenever the DP-to-HDMI
adapter is connected/disconnected, but I have not been a able to find
a way to distinguish between connecting/disconnecting the HDMI cable
and connecting/disconnecting the actual DP-to-HDMI adapter.
My current approach is to check the CEC tunneling support whenever a new
display is connected:
- if CEC tunneling is supported, but no CEC adapter exists, then create one.
- if CEC tunneling is not supported, then unregister the CEC adapter if one
was created earlier.
- if CEC tunneling is supported and the capabilities are identical to the
existing CEC adapter, then leave it be.
- if CEC tunneling is supported and the capabilities are different to the
existing CEC adapter, then unregister that CEC adapter and register a
new one.
This works well, but it would be much nicer if I would just know when the
DP adapter is disconnected as opposed to when the HDMI cable is disconnected
from the adapter. Suggestions are welcome.
The other remaining problem is that there are DP/USB-C to HDMI adapters that
support CEC tunneling in the chipset, but where the CEC pin is simply never
hooked up. From the point of view of the driver CEC is supported, but you'll
never see any other devices.
I am considering sending a CEC POLL message to logical address 0 (the TV)
to detect if the CEC pin is connected, but this is not 100% guaranteed to
work. This can be put under a kernel config option, though.
I think I need to do something for this since of the 5 USB-C to HDMI
adapters I've tested that set the CEC tunneling capability, only 2 have
the CEC pin hooked up. So this seems to be quite common.
I have tested this with my Intel NUC7i5BNK and with the two working
USB-C to HDMI adapters that I have found:
a Samsung EE-PW700 adapter and a Kramer ADC-U31C/HF adapter (I think that's
the model, I need to confirm this).
As usual the specifications of these adapters never, ever tell you whether
this is supported or not :-( It's trial and error to find one that works. In
fact, of the 10 USB-C to HDMI adapters I tested 5 didn't support CEC tunneling
at all, and of the remaining 5 only two had the CEC pin hooked up and so
actually worked.
BTW, all adapters that supported CEC tunneling used the Parade PS176 chip.
Output of cec-ctl -S (discovers the CEC topology):
$ cec-ctl -S
Driver Info:
Driver Name : i915
Adapter Name : DPDDC-C
Capabilities : 0x0000007e
Logical Addresses
Transmit
Passthrough
Remote Control Support
Monitor All
Driver version : 4.12.0
Available Logical Addresses: 4
Physical Address : 3.0.0.0
Logical Address Mask : 0x0010
CEC Version : 2.0
Vendor ID : 0x000c03 (HDMI)
OSD Name : 'Playback'
Logical Addresses : 1 (Allow RC Passthrough)
Logical Address : 4 (Playback Device 1)
Primary Device Type : Playback
Logical Address Type : Playback
All Device Types : Playback
RC TV Profile : None
Device Features :
None
System Information for device 0 (TV) from device 4 (Playback Device 1):
CEC Version : 1.4
Physical Address : 0.0.0.0
Primary Device Type : TV
Vendor ID : 0x0000f0 (Samsung)
OSD Name : TV
Menu Language : eng
Power Status : On
Topology:
0.0.0.0: TV
3.0.0.0: Playback Device 1
Regards,
Hans
Clint Taylor (1):
drm/cec: Add CEC over Aux register definitions
Hans Verkuil (6):
cec: add CEC_CAP_NEEDS_HPD
cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD
cec: add cec_s_phys_addr_from_edid helper function
cec: add cec_phys_addr_invalidate() helper function
drm: add support for DisplayPort CEC-Tunneling-over-AUX
drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
.../media/uapi/cec/cec-ioc-adap-g-caps.rst | 8 +
drivers/gpu/drm/Kconfig | 3 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_dp_cec.c | 196 +++++++++++++++++++++
drivers/gpu/drm/i915/Kconfig | 11 ++
drivers/gpu/drm/i915/intel_dp.c | 46 ++++-
drivers/media/cec/cec-adap.c | 34 +++-
drivers/media/cec/cec-api.c | 5 +-
drivers/media/cec/cec-core.c | 1 +
include/drm/drm_dp_helper.h | 83 +++++++++
include/media/cec.h | 15 ++
include/uapi/linux/cec.h | 2 +
12 files changed, 394 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/drm_dp_cec.c
--
2.11.0
^ permalink raw reply [flat|nested] 46+ messages in thread
* [RFC PATCH 1/7] cec: add CEC_CAP_NEEDS_HPD
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
@ 2017-05-25 15:06 ` Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD Hans Verkuil
` (7 subsequent siblings)
8 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Jani Nikula, Daniel Vetter,
Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Add a new capability CEC_CAP_NEEDS_HPD. If this capability is set
then the hardware can only use CEC if the HDMI Hotplug Detect pin
is high. Such hardware cannot handle the corner case in the CEC specification
where it is possible to transmit messages even if no hotplug signal is
present (needed for some displays that turn off the HPD when in standby,
but still have CEC enabled).
Typically hardware that needs this capability have the HPD wired to the CEC
block, often to a 'power' or 'active' pin.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/cec/cec-adap.c | 20 ++++++++++++++------
drivers/media/cec/cec-api.c | 5 ++++-
drivers/media/cec/cec-core.c | 1 +
include/media/cec.h | 1 +
include/uapi/linux/cec.h | 2 ++
5 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index f5fe01c9da8a..303de0d25d2b 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -366,6 +366,8 @@ int cec_thread_func(void *_adap)
* transmit should be canceled.
*/
err = wait_event_interruptible_timeout(adap->kthread_waitq,
+ (adap->needs_hpd &&
+ (!adap->is_configured && !adap->is_configuring)) ||
kthread_should_stop() ||
(!adap->transmitting &&
!list_empty(&adap->transmit_queue)),
@@ -381,7 +383,9 @@ int cec_thread_func(void *_adap)
mutex_lock(&adap->lock);
- if (kthread_should_stop()) {
+ if ((adap->needs_hpd &&
+ (!adap->is_configured && !adap->is_configuring)) ||
+ kthread_should_stop()) {
cec_flush(adap);
goto unlock;
}
@@ -647,7 +651,7 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct cec_msg *msg,
return -EINVAL;
}
if (!adap->is_configured && !adap->is_configuring) {
- if (msg->msg[0] != 0xf0) {
+ if (adap->needs_hpd || msg->msg[0] != 0xf0) {
dprintk(1, "%s: adapter is unconfigured\n", __func__);
return -ENONET;
}
@@ -1126,7 +1130,9 @@ static int cec_config_log_addr(struct cec_adapter *adap,
*/
static void cec_adap_unconfigure(struct cec_adapter *adap)
{
- WARN_ON(adap->ops->adap_log_addr(adap, CEC_LOG_ADDR_INVALID));
+ if (!adap->needs_hpd ||
+ adap->phys_addr != CEC_PHYS_ADDR_INVALID)
+ WARN_ON(adap->ops->adap_log_addr(adap, CEC_LOG_ADDR_INVALID));
adap->log_addrs.log_addr_mask = 0;
adap->is_configuring = false;
adap->is_configured = false;
@@ -1355,6 +1361,8 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, bool block)
if (phys_addr == adap->phys_addr || adap->devnode.unregistered)
return;
+ dprintk(1, "new physical address %x.%x.%x.%x\n",
+ cec_phys_addr_exp(phys_addr));
if (phys_addr == CEC_PHYS_ADDR_INVALID ||
adap->phys_addr != CEC_PHYS_ADDR_INVALID) {
adap->phys_addr = CEC_PHYS_ADDR_INVALID;
@@ -1364,7 +1372,7 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, bool block)
if (adap->monitor_all_cnt)
WARN_ON(call_op(adap, adap_monitor_all_enable, false));
mutex_lock(&adap->devnode.lock);
- if (list_empty(&adap->devnode.fhs))
+ if (adap->needs_hpd || list_empty(&adap->devnode.fhs))
WARN_ON(adap->ops->adap_enable(adap, false));
mutex_unlock(&adap->devnode.lock);
if (phys_addr == CEC_PHYS_ADDR_INVALID)
@@ -1372,7 +1380,7 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, bool block)
}
mutex_lock(&adap->devnode.lock);
- if (list_empty(&adap->devnode.fhs) &&
+ if ((adap->needs_hpd || list_empty(&adap->devnode.fhs)) &&
adap->ops->adap_enable(adap, true)) {
mutex_unlock(&adap->devnode.lock);
return;
@@ -1380,7 +1388,7 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, bool block)
if (adap->monitor_all_cnt &&
call_op(adap, adap_monitor_all_enable, true)) {
- if (list_empty(&adap->devnode.fhs))
+ if (adap->needs_hpd || list_empty(&adap->devnode.fhs))
WARN_ON(adap->ops->adap_enable(adap, false));
mutex_unlock(&adap->devnode.lock);
return;
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index 0860fb458757..1359c3977101 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -202,7 +202,8 @@ static long cec_transmit(struct cec_adapter *adap, struct cec_fh *fh,
err = -EPERM;
else if (adap->is_configuring)
err = -ENONET;
- else if (!adap->is_configured && msg.msg[0] != 0xf0)
+ else if (!adap->is_configured &&
+ (adap->needs_hpd || msg.msg[0] != 0xf0))
err = -ENONET;
else if (cec_is_busy(adap, fh))
err = -EBUSY;
@@ -521,6 +522,7 @@ static int cec_open(struct inode *inode, struct file *filp)
mutex_lock(&devnode->lock);
if (list_empty(&devnode->fhs) &&
+ !adap->needs_hpd &&
adap->phys_addr == CEC_PHYS_ADDR_INVALID) {
err = adap->ops->adap_enable(adap, true);
if (err) {
@@ -565,6 +567,7 @@ static int cec_release(struct inode *inode, struct file *filp)
mutex_lock(&devnode->lock);
list_del(&fh->list);
if (list_empty(&devnode->fhs) &&
+ !adap->needs_hpd &&
adap->phys_addr == CEC_PHYS_ADDR_INVALID) {
WARN_ON(adap->ops->adap_enable(adap, false));
}
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index f9ebff90f8eb..0d9a1f481b86 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -230,6 +230,7 @@ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
adap->log_addrs.cec_version = CEC_OP_CEC_VERSION_2_0;
adap->log_addrs.vendor_id = CEC_VENDOR_ID_NONE;
adap->capabilities = caps;
+ adap->needs_hpd = caps & CEC_CAP_NEEDS_HPD;
adap->available_log_addrs = available_las;
adap->sequence = 0;
adap->ops = ops;
diff --git a/include/media/cec.h b/include/media/cec.h
index b8eb895731d5..b08edb31508f 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -164,6 +164,7 @@ struct cec_adapter {
u8 available_log_addrs;
u16 phys_addr;
+ bool needs_hpd;
bool is_configuring;
bool is_configured;
u32 monitor_all_cnt;
diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
index a0dfe27bc6c7..44579a24f95d 100644
--- a/include/uapi/linux/cec.h
+++ b/include/uapi/linux/cec.h
@@ -336,6 +336,8 @@ static inline int cec_is_unconfigured(__u16 log_addr_mask)
#define CEC_CAP_RC (1 << 4)
/* Hardware can monitor all messages, not just directed and broadcast. */
#define CEC_CAP_MONITOR_ALL (1 << 5)
+/* Hardware can use CEC only if the HDMI HPD pin is high. */
+#define CEC_CAP_NEEDS_HPD (1 << 6)
/**
* struct cec_caps - CEC capabilities structure.
--
2.11.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 1/7] cec: add CEC_CAP_NEEDS_HPD Hans Verkuil
@ 2017-05-25 15:06 ` Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 3/7] cec: add cec_s_phys_addr_from_edid helper function Hans Verkuil
` (6 subsequent siblings)
8 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Jani Nikula, Daniel Vetter,
Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Document the new CEC_CAP_NEEDS_HPD capability.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
index a0e961f11017..6d7bf7bef3eb 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
@@ -113,6 +113,14 @@ returns the information to the application. The ioctl never fails.
- 0x00000020
- The CEC hardware can monitor all messages, not just directed and
broadcast messages.
+ * .. _`CEC-CAP-NEEDS-HPD`:
+
+ - ``CEC_CAP_NEEDS_HPD``
+ - 0x00000040
+ - The CEC hardware is only active if the HDMI Hotplug Detect pin is
+ high. This makes it impossible to use CEC to wake up displays that
+ set the HPD pin low when in standby mode, but keep the CEC bus
+ alive.
--
2.11.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 3/7] cec: add cec_s_phys_addr_from_edid helper function
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 1/7] cec: add CEC_CAP_NEEDS_HPD Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD Hans Verkuil
@ 2017-05-25 15:06 ` Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 4/7] cec: add cec_phys_addr_invalidate() " Hans Verkuil
` (5 subsequent siblings)
8 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Jani Nikula, Daniel Vetter,
Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
This function simplifies the integration of CEC in DRM drivers.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/cec/cec-adap.c | 14 ++++++++++++++
include/media/cec.h | 9 +++++++++
2 files changed, 23 insertions(+)
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 303de0d25d2b..1b9537d8d24b 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -28,6 +28,8 @@
#include <linux/string.h>
#include <linux/types.h>
+#include <drm/drm_edid.h>
+
#include "cec-priv.h"
static void cec_fill_msg_report_features(struct cec_adapter *adap,
@@ -1412,6 +1414,18 @@ void cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, bool block)
}
EXPORT_SYMBOL_GPL(cec_s_phys_addr);
+void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
+ const struct edid *edid)
+{
+ u16 pa = CEC_PHYS_ADDR_INVALID;
+
+ if (edid && edid->extensions)
+ pa = cec_get_edid_phys_addr((const u8 *)edid,
+ EDID_LENGTH * (edid->extensions + 1), NULL);
+ cec_s_phys_addr(adap, pa, false);
+}
+EXPORT_SYMBOL_GPL(cec_s_phys_addr_from_edid);
+
/*
* Called from either the ioctl or a driver to set the logical addresses.
*
diff --git a/include/media/cec.h b/include/media/cec.h
index b08edb31508f..9989cdb58bd8 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -207,6 +207,8 @@ static inline bool cec_is_sink(const struct cec_adapter *adap)
#define cec_phys_addr_exp(pa) \
((pa) >> 12), ((pa) >> 8) & 0xf, ((pa) >> 4) & 0xf, (pa) & 0xf
+struct edid;
+
#if IS_ENABLED(CONFIG_CEC_CORE)
struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
void *priv, const char *name, u32 caps, u8 available_las);
@@ -218,6 +220,8 @@ int cec_s_log_addrs(struct cec_adapter *adap, struct cec_log_addrs *log_addrs,
bool block);
void cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr,
bool block);
+void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
+ const struct edid *edid);
int cec_transmit_msg(struct cec_adapter *adap, struct cec_msg *msg,
bool block);
@@ -327,6 +331,11 @@ static inline void cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr,
{
}
+static inline void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
+ const struct edid *edid)
+{
+}
+
static inline u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
unsigned int *offset)
{
--
2.11.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 4/7] cec: add cec_phys_addr_invalidate() helper function
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
` (2 preceding siblings ...)
2017-05-25 15:06 ` [RFC PATCH 3/7] cec: add cec_s_phys_addr_from_edid helper function Hans Verkuil
@ 2017-05-25 15:06 ` Hans Verkuil
2017-05-25 15:06 ` Hans Verkuil
` (4 subsequent siblings)
8 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Jani Nikula, Daniel Vetter,
Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Simplifies setting the physical address to CEC_PHYS_ADDR_INVALID.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
include/media/cec.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/media/cec.h b/include/media/cec.h
index 9989cdb58bd8..6123a5eec540 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -361,4 +361,9 @@ static inline int cec_phys_addr_validate(u16 phys_addr, u16 *parent, u16 *port)
#endif
+static inline void cec_phys_addr_invalidate(struct cec_adapter *adap)
+{
+ cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
+}
+
#endif /* _MEDIA_CEC_H */
--
2.11.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
@ 2017-05-25 15:06 ` Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD Hans Verkuil
` (7 subsequent siblings)
8 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Jani Nikula, Daniel Vetter,
Jani Nikula
From: Clint Taylor <clinton.a.taylor@intel.com>
Adding DPCD register definitions from the DP 1.3 specification for CEC
over AUX support.
V2: Add DP_ prefix to all defines.
V3: missed prefixes from the ESI1 defines
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1492703263-11494-1-git-send-email-clinton.a.taylor@intel.com
---
include/drm/drm_dp_helper.h | 59 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7651a9..3f4ad709534e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -603,6 +603,9 @@
#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */
#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */
+# define DP_RX_GTC_MSTR_REQ_STATUS_CHANGE (1 << 0)
+# define DP_LOCK_ACQUISITION_REQUEST (1 << 1)
+# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
@@ -636,6 +639,62 @@
# define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */
# define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */
+/* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
+#define DP_CEC_TUNNELING_CAPABILITY 0x3000
+# define DP_CEC_TUNNELING_CAPABLE (1 << 0)
+# define DP_CEC_SNOOPING_CAPABLE (1 << 1)
+# define DP_CEC_MULTIPLE_LA_CAPABLE (1 << 2)
+
+#define DP_CEC_TUNNELING_CONTROL 0x3001
+# define DP_CEC_TUNNELING_ENABLE (1 << 0)
+# define DP_CEC_SNOOPING_ENABLE (1 << 1)
+
+#define DP_CEC_RX_MESSAGE_INFO 0x3002
+# define DP_CEC_RX_MESSAGE_LEN_MASK (0xf << 0)
+# define DP_CEC_RX_MESSAGE_LEN_SHIFT 0
+# define DP_CEC_RX_MESSAGE_HPD_STATE (1 << 4)
+# define DP_CEC_RX_MESSAGE_HPD_LOST (1 << 5)
+# define DP_CEC_RX_MESSAGE_ACKED (1 << 6)
+# define DP_CEC_RX_MESSAGE_ENDED (1 << 7)
+
+#define DP_CEC_TX_MESSAGE_INFO 0x3003
+# define DP_CEC_TX_MESSAGE_LEN_MASK (0xf << 0)
+# define DP_CEC_TX_MESSAGE_LEN_SHIFT 0
+# define DP_CEC_TX_RETRY_COUNT_MASK (0x7 << 4)
+# define DP_CEC_TX_RETRY_COUNT_SHIFT 4
+# define DP_CEC_TX_MESSAGE_SEND (1 << 7)
+
+#define DP_CEC_TUNNELING_IRQ_FLAGS 0x3004
+# define DP_CEC_RX_MESSAGE_INFO_VALID (1 << 0)
+# define DP_CEC_RX_MESSAGE_OVERFLOW (1 << 1)
+# define DP_CEC_TX_MESSAGE_SENT (1 << 4)
+# define DP_CEC_TX_LINE_ERROR (1 << 5)
+# define DP_CEC_TX_ADDRESS_NACK_ERROR (1 << 6)
+# define DP_CEC_TX_DATA_NACK_ERROR (1 << 7)
+
+#define DP_CEC_LOGICAL_ADDRESS_MASK 0x300E /* 0x300F word */
+# define DP_CEC_LOGICAL_ADDRESS_0 (1 << 0)
+# define DP_CEC_LOGICAL_ADDRESS_1 (1 << 1)
+# define DP_CEC_LOGICAL_ADDRESS_2 (1 << 2)
+# define DP_CEC_LOGICAL_ADDRESS_3 (1 << 3)
+# define DP_CEC_LOGICAL_ADDRESS_4 (1 << 4)
+# define DP_CEC_LOGICAL_ADDRESS_5 (1 << 5)
+# define DP_CEC_LOGICAL_ADDRESS_6 (1 << 6)
+# define DP_CEC_LOGICAL_ADDRESS_7 (1 << 7)
+#define DP_CEC_LOGICAL_ADDRESS_MASK_2 0x300F /* 0x300E word */
+# define DP_CEC_LOGICAL_ADDRESS_8 (1 << 0)
+# define DP_CEC_LOGICAL_ADDRESS_9 (1 << 1)
+# define DP_CEC_LOGICAL_ADDRESS_10 (1 << 2)
+# define DP_CEC_LOGICAL_ADDRESS_11 (1 << 3)
+# define DP_CEC_LOGICAL_ADDRESS_12 (1 << 4)
+# define DP_CEC_LOGICAL_ADDRESS_13 (1 << 5)
+# define DP_CEC_LOGICAL_ADDRESS_14 (1 << 6)
+# define DP_CEC_LOGICAL_ADDRESS_15 (1 << 7)
+
+#define DP_CEC_RX_MESSAGE_BUFFER 0x3010
+#define DP_CEC_TX_MESSAGE_BUFFER 0x3020
+#define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
+
/* DP 1.2 Sideband message defines */
/* peer device type - DP 1.2a Table 2-92 */
#define DP_PEER_DEVICE_NONE 0x0
--
2.11.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions
@ 2017-05-25 15:06 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media; +Cc: Jani Nikula, intel-gfx, dri-devel
From: Clint Taylor <clinton.a.taylor@intel.com>
Adding DPCD register definitions from the DP 1.3 specification for CEC
over AUX support.
V2: Add DP_ prefix to all defines.
V3: missed prefixes from the ESI1 defines
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1492703263-11494-1-git-send-email-clinton.a.taylor@intel.com
---
include/drm/drm_dp_helper.h | 59 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7651a9..3f4ad709534e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -603,6 +603,9 @@
#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */
#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */
+# define DP_RX_GTC_MSTR_REQ_STATUS_CHANGE (1 << 0)
+# define DP_LOCK_ACQUISITION_REQUEST (1 << 1)
+# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
@@ -636,6 +639,62 @@
# define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */
# define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */
+/* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
+#define DP_CEC_TUNNELING_CAPABILITY 0x3000
+# define DP_CEC_TUNNELING_CAPABLE (1 << 0)
+# define DP_CEC_SNOOPING_CAPABLE (1 << 1)
+# define DP_CEC_MULTIPLE_LA_CAPABLE (1 << 2)
+
+#define DP_CEC_TUNNELING_CONTROL 0x3001
+# define DP_CEC_TUNNELING_ENABLE (1 << 0)
+# define DP_CEC_SNOOPING_ENABLE (1 << 1)
+
+#define DP_CEC_RX_MESSAGE_INFO 0x3002
+# define DP_CEC_RX_MESSAGE_LEN_MASK (0xf << 0)
+# define DP_CEC_RX_MESSAGE_LEN_SHIFT 0
+# define DP_CEC_RX_MESSAGE_HPD_STATE (1 << 4)
+# define DP_CEC_RX_MESSAGE_HPD_LOST (1 << 5)
+# define DP_CEC_RX_MESSAGE_ACKED (1 << 6)
+# define DP_CEC_RX_MESSAGE_ENDED (1 << 7)
+
+#define DP_CEC_TX_MESSAGE_INFO 0x3003
+# define DP_CEC_TX_MESSAGE_LEN_MASK (0xf << 0)
+# define DP_CEC_TX_MESSAGE_LEN_SHIFT 0
+# define DP_CEC_TX_RETRY_COUNT_MASK (0x7 << 4)
+# define DP_CEC_TX_RETRY_COUNT_SHIFT 4
+# define DP_CEC_TX_MESSAGE_SEND (1 << 7)
+
+#define DP_CEC_TUNNELING_IRQ_FLAGS 0x3004
+# define DP_CEC_RX_MESSAGE_INFO_VALID (1 << 0)
+# define DP_CEC_RX_MESSAGE_OVERFLOW (1 << 1)
+# define DP_CEC_TX_MESSAGE_SENT (1 << 4)
+# define DP_CEC_TX_LINE_ERROR (1 << 5)
+# define DP_CEC_TX_ADDRESS_NACK_ERROR (1 << 6)
+# define DP_CEC_TX_DATA_NACK_ERROR (1 << 7)
+
+#define DP_CEC_LOGICAL_ADDRESS_MASK 0x300E /* 0x300F word */
+# define DP_CEC_LOGICAL_ADDRESS_0 (1 << 0)
+# define DP_CEC_LOGICAL_ADDRESS_1 (1 << 1)
+# define DP_CEC_LOGICAL_ADDRESS_2 (1 << 2)
+# define DP_CEC_LOGICAL_ADDRESS_3 (1 << 3)
+# define DP_CEC_LOGICAL_ADDRESS_4 (1 << 4)
+# define DP_CEC_LOGICAL_ADDRESS_5 (1 << 5)
+# define DP_CEC_LOGICAL_ADDRESS_6 (1 << 6)
+# define DP_CEC_LOGICAL_ADDRESS_7 (1 << 7)
+#define DP_CEC_LOGICAL_ADDRESS_MASK_2 0x300F /* 0x300E word */
+# define DP_CEC_LOGICAL_ADDRESS_8 (1 << 0)
+# define DP_CEC_LOGICAL_ADDRESS_9 (1 << 1)
+# define DP_CEC_LOGICAL_ADDRESS_10 (1 << 2)
+# define DP_CEC_LOGICAL_ADDRESS_11 (1 << 3)
+# define DP_CEC_LOGICAL_ADDRESS_12 (1 << 4)
+# define DP_CEC_LOGICAL_ADDRESS_13 (1 << 5)
+# define DP_CEC_LOGICAL_ADDRESS_14 (1 << 6)
+# define DP_CEC_LOGICAL_ADDRESS_15 (1 << 7)
+
+#define DP_CEC_RX_MESSAGE_BUFFER 0x3010
+#define DP_CEC_TX_MESSAGE_BUFFER 0x3020
+#define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
+
/* DP 1.2 Sideband message defines */
/* peer device type - DP 1.2a Table 2-92 */
#define DP_PEER_DEVICE_NONE 0x0
--
2.11.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
@ 2017-05-25 15:06 ` Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD Hans Verkuil
` (7 subsequent siblings)
8 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Jani Nikula, Daniel Vetter,
Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
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 <hans.verkuil@cisco.com>
---
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
+
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 000000000000..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 <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <drm/drm_dp_helper.h>
+#include <media/cec.h>
+
+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 int retries = attempts - 1;
+ ssize_t err;
+
+ err = drm_dp_dpcd_write(aux, DP_CEC_TX_MESSAGE_BUFFER,
+ msg->msg, msg->len);
+ if (err < 0)
+ return err;
+
+ if (retries > 5)
+ retries = 5;
+ err = drm_dp_dpcd_writeb(aux, DP_CEC_TX_MESSAGE_INFO,
+ (msg->len - 1) | (retries << 4) |
+ DP_CEC_TX_MESSAGE_SEND);
+ return err < 0 ? err : 0;
+}
+
+static int drm_dp_cec_adap_monitor_all_enable(struct cec_adapter *adap,
+ bool enable)
+{
+ struct drm_dp_aux *aux = cec_get_drvdata(adap);
+ ssize_t err;
+ u8 val;
+
+ if (!(adap->capabilities & CEC_CAP_MONITOR_ALL))
+ return 0;
+
+ err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CONTROL, &val);
+ if (err >= 0) {
+ if (enable)
+ val |= DP_CEC_SNOOPING_ENABLE;
+ else
+ val &= ~DP_CEC_SNOOPING_ENABLE;
+ err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
+ }
+ return (enable && err < 0) ? err : 0;
+}
+
+static const struct cec_adap_ops drm_dp_cec_adap_ops = {
+ .adap_enable = drm_dp_cec_adap_enable,
+ .adap_log_addr = drm_dp_cec_adap_log_addr,
+ .adap_transmit = drm_dp_cec_adap_transmit,
+ .adap_monitor_all_enable = drm_dp_cec_adap_monitor_all_enable,
+};
+
+static int drm_dp_cec_received(struct drm_dp_aux *aux)
+{
+ struct cec_adapter *adap = aux->cec_adap;
+ struct cec_msg msg;
+ u8 rx_msg_info;
+ ssize_t err;
+
+ err = drm_dp_dpcd_readb(aux, DP_CEC_RX_MESSAGE_INFO, &rx_msg_info);
+ if (err < 0)
+ return err;
+ if (!(rx_msg_info & DP_CEC_RX_MESSAGE_ENDED))
+ return 0;
+ msg.len = (rx_msg_info & DP_CEC_RX_MESSAGE_LEN_MASK) + 1;
+ err = drm_dp_dpcd_read(aux, DP_CEC_RX_MESSAGE_BUFFER, msg.msg, msg.len);
+ if (err < 0)
+ return err;
+ cec_received_msg(adap, &msg);
+ return 0;
+}
+
+int drm_dp_cec_irq(struct drm_dp_aux *aux)
+{
+ struct cec_adapter *adap = aux->cec_adap;
+ u8 flags;
+ ssize_t err;
+
+ if (!aux->cec_adap)
+ return 0;
+
+ err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, &flags);
+ if (err < 0)
+ return err;
+
+ if (flags & DP_CEC_RX_MESSAGE_INFO_VALID)
+ drm_dp_cec_received(aux);
+
+ if (flags & DP_CEC_TX_MESSAGE_SENT)
+ cec_transmit_done(adap, CEC_TX_STATUS_OK, 0, 0, 0, 0);
+ else if (flags & DP_CEC_TX_LINE_ERROR)
+ cec_transmit_done(adap, CEC_TX_STATUS_ERROR |
+ CEC_TX_STATUS_MAX_RETRIES, 0, 0, 0, 1);
+ else if (flags &
+ (DP_CEC_TX_ADDRESS_NACK_ERROR | DP_CEC_TX_DATA_NACK_ERROR))
+ cec_transmit_done(adap, CEC_TX_STATUS_NACK |
+ CEC_TX_STATUS_MAX_RETRIES, 0, 1, 0, 0);
+ drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, flags);
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_cec_irq);
+
+int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
+ struct device *parent)
+{
+ u32 cec_caps = CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
+ CEC_CAP_PASSTHROUGH | CEC_CAP_RC | CEC_CAP_NEEDS_HPD;
+ unsigned int num_las = 1;
+ int err;
+ u8 cap;
+
+ if (drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CAPABILITY, &cap) != 1 ||
+ !(cap & DP_CEC_TUNNELING_CAPABLE)) {
+ cec_unregister_adapter(aux->cec_adap);
+ aux->cec_adap = NULL;
+ return -ENODEV;
+ }
+
+ if (cap & DP_CEC_SNOOPING_CAPABLE)
+ cec_caps |= CEC_CAP_MONITOR_ALL;
+ if (cap & DP_CEC_MULTIPLE_LA_CAPABLE)
+ num_las = CEC_MAX_LOG_ADDRS;
+
+ if (!IS_ERR_OR_NULL(aux->cec_adap)) {
+ if (aux->cec_adap->capabilities == cec_caps &&
+ aux->cec_adap->available_log_addrs == num_las)
+ return 0;
+ cec_unregister_adapter(aux->cec_adap);
+ }
+
+ aux->cec_adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
+ aux, name, cec_caps, num_las);
+ if (IS_ERR(aux->cec_adap)) {
+ err = PTR_ERR(aux->cec_adap);
+ aux->cec_adap = NULL;
+ return err;
+ }
+ err = cec_register_adapter(aux->cec_adap, parent);
+ if (err) {
+ cec_delete_adapter(aux->cec_adap);
+ aux->cec_adap = NULL;
+ }
+ return err;
+}
+EXPORT_SYMBOL(drm_dp_cec_configure_adapter);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3f4ad709534e..1e373df48108 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -843,6 +843,8 @@ struct drm_dp_aux_msg {
size_t size;
};
+struct cec_adapter;
+
/**
* struct drm_dp_aux - DisplayPort AUX channel
* @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
@@ -901,6 +903,10 @@ struct drm_dp_aux {
* @i2c_defer_count: Counts I2C DEFERs, used for DP validation.
*/
unsigned i2c_defer_count;
+ /**
+ * @cec_adap: the CEC adapter for CEC-Tunneling-over-AUX support.
+ */
+ struct cec_adapter *cec_adap;
};
ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
@@ -972,4 +978,22 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
int drm_dp_stop_crc(struct drm_dp_aux *aux);
+#ifdef CONFIG_DRM_DP_CEC
+int drm_dp_cec_irq(struct drm_dp_aux *aux);
+int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
+ struct device *parent);
+#else
+static inline int drm_dp_cec_irq(struct drm_dp_aux *aux)
+{
+ return 0;
+}
+
+static inline int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux,
+ const char *name,
+ struct device *parent)
+{
+ return -ENODEV;
+}
+#endif
+
#endif /* _DRM_DP_HELPER_H_ */
--
2.11.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
@ 2017-05-25 15:06 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media; +Cc: Jani Nikula, intel-gfx, dri-devel, Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
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 <hans.verkuil@cisco.com>
---
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
+
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 000000000000..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 <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <drm/drm_dp_helper.h>
+#include <media/cec.h>
+
+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 int retries = attempts - 1;
+ ssize_t err;
+
+ err = drm_dp_dpcd_write(aux, DP_CEC_TX_MESSAGE_BUFFER,
+ msg->msg, msg->len);
+ if (err < 0)
+ return err;
+
+ if (retries > 5)
+ retries = 5;
+ err = drm_dp_dpcd_writeb(aux, DP_CEC_TX_MESSAGE_INFO,
+ (msg->len - 1) | (retries << 4) |
+ DP_CEC_TX_MESSAGE_SEND);
+ return err < 0 ? err : 0;
+}
+
+static int drm_dp_cec_adap_monitor_all_enable(struct cec_adapter *adap,
+ bool enable)
+{
+ struct drm_dp_aux *aux = cec_get_drvdata(adap);
+ ssize_t err;
+ u8 val;
+
+ if (!(adap->capabilities & CEC_CAP_MONITOR_ALL))
+ return 0;
+
+ err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CONTROL, &val);
+ if (err >= 0) {
+ if (enable)
+ val |= DP_CEC_SNOOPING_ENABLE;
+ else
+ val &= ~DP_CEC_SNOOPING_ENABLE;
+ err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
+ }
+ return (enable && err < 0) ? err : 0;
+}
+
+static const struct cec_adap_ops drm_dp_cec_adap_ops = {
+ .adap_enable = drm_dp_cec_adap_enable,
+ .adap_log_addr = drm_dp_cec_adap_log_addr,
+ .adap_transmit = drm_dp_cec_adap_transmit,
+ .adap_monitor_all_enable = drm_dp_cec_adap_monitor_all_enable,
+};
+
+static int drm_dp_cec_received(struct drm_dp_aux *aux)
+{
+ struct cec_adapter *adap = aux->cec_adap;
+ struct cec_msg msg;
+ u8 rx_msg_info;
+ ssize_t err;
+
+ err = drm_dp_dpcd_readb(aux, DP_CEC_RX_MESSAGE_INFO, &rx_msg_info);
+ if (err < 0)
+ return err;
+ if (!(rx_msg_info & DP_CEC_RX_MESSAGE_ENDED))
+ return 0;
+ msg.len = (rx_msg_info & DP_CEC_RX_MESSAGE_LEN_MASK) + 1;
+ err = drm_dp_dpcd_read(aux, DP_CEC_RX_MESSAGE_BUFFER, msg.msg, msg.len);
+ if (err < 0)
+ return err;
+ cec_received_msg(adap, &msg);
+ return 0;
+}
+
+int drm_dp_cec_irq(struct drm_dp_aux *aux)
+{
+ struct cec_adapter *adap = aux->cec_adap;
+ u8 flags;
+ ssize_t err;
+
+ if (!aux->cec_adap)
+ return 0;
+
+ err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, &flags);
+ if (err < 0)
+ return err;
+
+ if (flags & DP_CEC_RX_MESSAGE_INFO_VALID)
+ drm_dp_cec_received(aux);
+
+ if (flags & DP_CEC_TX_MESSAGE_SENT)
+ cec_transmit_done(adap, CEC_TX_STATUS_OK, 0, 0, 0, 0);
+ else if (flags & DP_CEC_TX_LINE_ERROR)
+ cec_transmit_done(adap, CEC_TX_STATUS_ERROR |
+ CEC_TX_STATUS_MAX_RETRIES, 0, 0, 0, 1);
+ else if (flags &
+ (DP_CEC_TX_ADDRESS_NACK_ERROR | DP_CEC_TX_DATA_NACK_ERROR))
+ cec_transmit_done(adap, CEC_TX_STATUS_NACK |
+ CEC_TX_STATUS_MAX_RETRIES, 0, 1, 0, 0);
+ drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, flags);
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_cec_irq);
+
+int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
+ struct device *parent)
+{
+ u32 cec_caps = CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
+ CEC_CAP_PASSTHROUGH | CEC_CAP_RC | CEC_CAP_NEEDS_HPD;
+ unsigned int num_las = 1;
+ int err;
+ u8 cap;
+
+ if (drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CAPABILITY, &cap) != 1 ||
+ !(cap & DP_CEC_TUNNELING_CAPABLE)) {
+ cec_unregister_adapter(aux->cec_adap);
+ aux->cec_adap = NULL;
+ return -ENODEV;
+ }
+
+ if (cap & DP_CEC_SNOOPING_CAPABLE)
+ cec_caps |= CEC_CAP_MONITOR_ALL;
+ if (cap & DP_CEC_MULTIPLE_LA_CAPABLE)
+ num_las = CEC_MAX_LOG_ADDRS;
+
+ if (!IS_ERR_OR_NULL(aux->cec_adap)) {
+ if (aux->cec_adap->capabilities == cec_caps &&
+ aux->cec_adap->available_log_addrs == num_las)
+ return 0;
+ cec_unregister_adapter(aux->cec_adap);
+ }
+
+ aux->cec_adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
+ aux, name, cec_caps, num_las);
+ if (IS_ERR(aux->cec_adap)) {
+ err = PTR_ERR(aux->cec_adap);
+ aux->cec_adap = NULL;
+ return err;
+ }
+ err = cec_register_adapter(aux->cec_adap, parent);
+ if (err) {
+ cec_delete_adapter(aux->cec_adap);
+ aux->cec_adap = NULL;
+ }
+ return err;
+}
+EXPORT_SYMBOL(drm_dp_cec_configure_adapter);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3f4ad709534e..1e373df48108 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -843,6 +843,8 @@ struct drm_dp_aux_msg {
size_t size;
};
+struct cec_adapter;
+
/**
* struct drm_dp_aux - DisplayPort AUX channel
* @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
@@ -901,6 +903,10 @@ struct drm_dp_aux {
* @i2c_defer_count: Counts I2C DEFERs, used for DP validation.
*/
unsigned i2c_defer_count;
+ /**
+ * @cec_adap: the CEC adapter for CEC-Tunneling-over-AUX support.
+ */
+ struct cec_adapter *cec_adap;
};
ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
@@ -972,4 +978,22 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
int drm_dp_stop_crc(struct drm_dp_aux *aux);
+#ifdef CONFIG_DRM_DP_CEC
+int drm_dp_cec_irq(struct drm_dp_aux *aux);
+int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
+ struct device *parent);
+#else
+static inline int drm_dp_cec_irq(struct drm_dp_aux *aux)
+{
+ return 0;
+}
+
+static inline int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux,
+ const char *name,
+ struct device *parent)
+{
+ return -ENODEV;
+}
+#endif
+
#endif /* _DRM_DP_HELPER_H_ */
--
2.11.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
@ 2017-05-25 15:06 ` Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD Hans Verkuil
` (7 subsequent siblings)
8 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Jani Nikula, Daniel Vetter,
Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Implement support for this DisplayPort feature.
The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the previous one, then the old cec device is
unregistered and a new one is registered to replace the old one.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/gpu/drm/i915/Kconfig | 11 ++++++++++
drivers/gpu/drm/i915/intel_dp.c | 46 +++++++++++++++++++++++++++++++++++++----
2 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index a5cd5dacf055..f317b13a1409 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
Choose this option if you want to enable KVMGT support for
Intel GVT-g.
+config DRM_I915_DP_CEC
+ tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
+ depends on DRM_I915 && CEC_CORE
+ select DRM_DP_CEC
+ help
+ Choose this option if you want to enable HDMI CEC support for
+ DisplayPort/USB-C to HDMI adapters.
+
+ Note: not all adapters support this feature, and even for those
+ that do support this often do not hook up the CEC pin.
+
menu "drm/i915 Debugging"
depends on DRM_I915
depends on EXPERT
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ee77b519835c..38e17ee2548d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -32,6 +32,7 @@
#include <linux/notifier.h>
#include <linux/reboot.h>
#include <asm/byteorder.h>
+#include <media/cec.h>
#include <drm/drmP.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_crtc.h>
@@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
static void
intel_dp_aux_fini(struct intel_dp *intel_dp)
{
+ cec_unregister_adapter(intel_dp->aux.cec_adap);
kfree(intel_dp->aux.name);
}
@@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return -EINVAL;
}
+static bool
+intel_dp_check_cec_status(struct intel_dp *intel_dp)
+{
+ bool handled = false;
+
+ for (;;) {
+ u8 cec_irq;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
+ &cec_irq);
+ if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
+ return handled;
+
+ cec_irq &= ~DP_CEC_IRQ;
+ drm_dp_cec_irq(&intel_dp->aux);
+ handled = true;
+
+ ret = drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
+ cec_irq);
+ if (ret < 0)
+ return handled;
+ }
+}
+
static void
intel_dp_retrain_link(struct intel_dp *intel_dp)
{
@@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
else
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
}
static void
@@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
+ cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
intel_dp->has_audio = false;
}
@@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
/* Can't disconnect eDP, but you can close the lid... */
- if (is_edp(intel_dp))
+ if (is_edp(intel_dp)) {
status = edp_detect(intel_dp);
- else if (intel_digital_port_connected(to_i915(dev),
- dp_to_dig_port(intel_dp)))
+ } else if (intel_digital_port_connected(to_i915(dev),
+ dp_to_dig_port(intel_dp))) {
status = intel_dp_detect_dpcd(intel_dp);
- else
+ if (status == connector_status_connected)
+ drm_dp_cec_configure_adapter(&intel_dp->aux,
+ intel_dp->aux.name, dev->dev);
+ } else {
status = connector_status_disconnected;
+ }
if (status == connector_status_disconnected) {
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -5080,6 +5115,9 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
+ if (intel_dp->aux.cec_adap)
+ intel_dp_check_cec_status(intel_dp);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
--
2.11.0
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
@ 2017-05-25 15:06 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:06 UTC (permalink / raw)
To: linux-media; +Cc: Jani Nikula, intel-gfx, dri-devel, Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Implement support for this DisplayPort feature.
The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the previous one, then the old cec device is
unregistered and a new one is registered to replace the old one.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/gpu/drm/i915/Kconfig | 11 ++++++++++
drivers/gpu/drm/i915/intel_dp.c | 46 +++++++++++++++++++++++++++++++++++++----
2 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index a5cd5dacf055..f317b13a1409 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
Choose this option if you want to enable KVMGT support for
Intel GVT-g.
+config DRM_I915_DP_CEC
+ tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
+ depends on DRM_I915 && CEC_CORE
+ select DRM_DP_CEC
+ help
+ Choose this option if you want to enable HDMI CEC support for
+ DisplayPort/USB-C to HDMI adapters.
+
+ Note: not all adapters support this feature, and even for those
+ that do support this often do not hook up the CEC pin.
+
menu "drm/i915 Debugging"
depends on DRM_I915
depends on EXPERT
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ee77b519835c..38e17ee2548d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -32,6 +32,7 @@
#include <linux/notifier.h>
#include <linux/reboot.h>
#include <asm/byteorder.h>
+#include <media/cec.h>
#include <drm/drmP.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_crtc.h>
@@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
static void
intel_dp_aux_fini(struct intel_dp *intel_dp)
{
+ cec_unregister_adapter(intel_dp->aux.cec_adap);
kfree(intel_dp->aux.name);
}
@@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return -EINVAL;
}
+static bool
+intel_dp_check_cec_status(struct intel_dp *intel_dp)
+{
+ bool handled = false;
+
+ for (;;) {
+ u8 cec_irq;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
+ &cec_irq);
+ if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
+ return handled;
+
+ cec_irq &= ~DP_CEC_IRQ;
+ drm_dp_cec_irq(&intel_dp->aux);
+ handled = true;
+
+ ret = drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
+ cec_irq);
+ if (ret < 0)
+ return handled;
+ }
+}
+
static void
intel_dp_retrain_link(struct intel_dp *intel_dp)
{
@@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
else
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
}
static void
@@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
+ cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
intel_dp->has_audio = false;
}
@@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
/* Can't disconnect eDP, but you can close the lid... */
- if (is_edp(intel_dp))
+ if (is_edp(intel_dp)) {
status = edp_detect(intel_dp);
- else if (intel_digital_port_connected(to_i915(dev),
- dp_to_dig_port(intel_dp)))
+ } else if (intel_digital_port_connected(to_i915(dev),
+ dp_to_dig_port(intel_dp))) {
status = intel_dp_detect_dpcd(intel_dp);
- else
+ if (status == connector_status_connected)
+ drm_dp_cec_configure_adapter(&intel_dp->aux,
+ intel_dp->aux.name, dev->dev);
+ } else {
status = connector_status_disconnected;
+ }
if (status == connector_status_disconnected) {
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -5080,6 +5115,9 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
+ if (intel_dp->aux.cec_adap)
+ intel_dp_check_cec_status(intel_dp);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
--
2.11.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
` (6 preceding siblings ...)
2017-05-25 15:06 ` Hans Verkuil
@ 2017-05-25 15:30 ` Mike Lothian
2017-05-25 15:56 ` Hans Verkuil
2017-05-25 15:34 ` ✓ Fi.CI.BAT: success for " Patchwork
8 siblings, 1 reply; 46+ messages in thread
From: Mike Lothian @ 2017-05-25 15:30 UTC (permalink / raw)
To: Hans Verkuil, linux-media; +Cc: Jani Nikula, intel-gfx, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 6441 bytes --]
Hi
Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C
connector and no displayport
Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working
based on your testing?
I've been putting off buying one until I knew 4K@60Hz would work, CEC would
be nice to have too
Thanks
Mike
On Thu, 25 May 2017 at 16:06 Hans Verkuil <hverkuil@xs4all.nl> wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> protocol.
>
> This patch series is based on v4.12-rc2.
>
> The first four patches add support for a new CEC capability which is
> needed for these devices and for two helper functions.
>
> Then the DP CEC registers are added using Clint's patch.
>
> The core CEC tunneling support is added to drm_dp_cec.c.
>
> And finally this is hooked up in the i915 driver.
>
> Ideally the cec driver is created and destroyed whenever the DP-to-HDMI
> adapter is connected/disconnected, but I have not been a able to find
> a way to distinguish between connecting/disconnecting the HDMI cable
> and connecting/disconnecting the actual DP-to-HDMI adapter.
>
> My current approach is to check the CEC tunneling support whenever a new
> display is connected:
>
> - if CEC tunneling is supported, but no CEC adapter exists, then create
> one.
> - if CEC tunneling is not supported, then unregister the CEC adapter if one
> was created earlier.
> - if CEC tunneling is supported and the capabilities are identical to the
> existing CEC adapter, then leave it be.
> - if CEC tunneling is supported and the capabilities are different to the
> existing CEC adapter, then unregister that CEC adapter and register a
> new one.
>
> This works well, but it would be much nicer if I would just know when the
> DP adapter is disconnected as opposed to when the HDMI cable is
> disconnected
> from the adapter. Suggestions are welcome.
>
> The other remaining problem is that there are DP/USB-C to HDMI adapters
> that
> support CEC tunneling in the chipset, but where the CEC pin is simply never
> hooked up. From the point of view of the driver CEC is supported, but
> you'll
> never see any other devices.
>
> I am considering sending a CEC POLL message to logical address 0 (the TV)
> to detect if the CEC pin is connected, but this is not 100% guaranteed to
> work. This can be put under a kernel config option, though.
>
> I think I need to do something for this since of the 5 USB-C to HDMI
> adapters I've tested that set the CEC tunneling capability, only 2 have
> the CEC pin hooked up. So this seems to be quite common.
>
> I have tested this with my Intel NUC7i5BNK and with the two working
> USB-C to HDMI adapters that I have found:
>
> a Samsung EE-PW700 adapter and a Kramer ADC-U31C/HF adapter (I think that's
> the model, I need to confirm this).
>
> As usual the specifications of these adapters never, ever tell you whether
> this is supported or not :-( It's trial and error to find one that works.
> In
> fact, of the 10 USB-C to HDMI adapters I tested 5 didn't support CEC
> tunneling
> at all, and of the remaining 5 only two had the CEC pin hooked up and so
> actually worked.
>
> BTW, all adapters that supported CEC tunneling used the Parade PS176 chip.
>
> Output of cec-ctl -S (discovers the CEC topology):
>
> $ cec-ctl -S
> Driver Info:
> Driver Name : i915
> Adapter Name : DPDDC-C
> Capabilities : 0x0000007e
> Logical Addresses
> Transmit
> Passthrough
> Remote Control Support
> Monitor All
> Driver version : 4.12.0
> Available Logical Addresses: 4
> Physical Address : 3.0.0.0
> Logical Address Mask : 0x0010
> CEC Version : 2.0
> Vendor ID : 0x000c03 (HDMI)
> OSD Name : 'Playback'
> Logical Addresses : 1 (Allow RC Passthrough)
>
> Logical Address : 4 (Playback Device 1)
> Primary Device Type : Playback
> Logical Address Type : Playback
> All Device Types : Playback
> RC TV Profile : None
> Device Features :
> None
>
> System Information for device 0 (TV) from device 4 (Playback
> Device 1):
> CEC Version : 1.4
> Physical Address : 0.0.0.0
> Primary Device Type : TV
> Vendor ID : 0x0000f0 (Samsung)
> OSD Name : TV
> Menu Language : eng
> Power Status : On
>
> Topology:
>
> 0.0.0.0: TV
> 3.0.0.0: Playback Device 1
>
> Regards,
>
> Hans
>
> Clint Taylor (1):
> drm/cec: Add CEC over Aux register definitions
>
> Hans Verkuil (6):
> cec: add CEC_CAP_NEEDS_HPD
> cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD
> cec: add cec_s_phys_addr_from_edid helper function
> cec: add cec_phys_addr_invalidate() helper function
> drm: add support for DisplayPort CEC-Tunneling-over-AUX
> drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
>
> .../media/uapi/cec/cec-ioc-adap-g-caps.rst | 8 +
> drivers/gpu/drm/Kconfig | 3 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_dp_cec.c | 196
> +++++++++++++++++++++
> drivers/gpu/drm/i915/Kconfig | 11 ++
> drivers/gpu/drm/i915/intel_dp.c | 46 ++++-
> drivers/media/cec/cec-adap.c | 34 +++-
> drivers/media/cec/cec-api.c | 5 +-
> drivers/media/cec/cec-core.c | 1 +
> include/drm/drm_dp_helper.h | 83 +++++++++
> include/media/cec.h | 15 ++
> include/uapi/linux/cec.h | 2 +
> 12 files changed, 394 insertions(+), 11 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_dp_cec.c
>
> --
> 2.11.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[-- Attachment #1.2: Type: text/html, Size: 8192 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
` (7 preceding siblings ...)
2017-05-25 15:30 ` [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Mike Lothian
@ 2017-05-25 15:34 ` Patchwork
8 siblings, 0 replies; 46+ messages in thread
From: Patchwork @ 2017-05-25 15:34 UTC (permalink / raw)
To: Hans Verkuil; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
URL : https://patchwork.freedesktop.org/series/24918/
State : success
== Summary ==
Series 24918v1 drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
https://patchwork.freedesktop.org/api/1.0/series/24918/revisions/1/mbox/
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail -> PASS (fi-snb-2600) fdo#100215
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:441s
fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:577s
fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:516s
fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:486s
fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:474s
fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:422s
fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:414s
fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:418s
fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:496s
fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:466s
fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:460s
fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:567s
fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:457s
fi-skl-6700hq total:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:433s
fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:460s
fi-skl-6770hq total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:495s
fi-skl-gvtdvm total:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:431s
fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:535s
fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:410s
fi-bdw-gvtdvm failed to connect after reboot
028a0b3762b318a72ab04675355db97c854c230b drm-tip: 2017y-05m-25d-11h-47m-22s UTC integration manifest
85fa1ee drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
ec98545 drm: add support for DisplayPort CEC-Tunneling-over-AUX
4ca67fe cec: add cec_phys_addr_invalidate() helper function
54a6442 cec: add cec_s_phys_addr_from_edid helper function
3a8fd5b cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD
69ac40f cec: add CEC_CAP_NEEDS_HPD
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4809/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-25 15:30 ` [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Mike Lothian
@ 2017-05-25 15:56 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-25 15:56 UTC (permalink / raw)
To: Mike Lothian, linux-media; +Cc: Jani Nikula, intel-gfx, dri-devel
On 05/25/2017 05:30 PM, Mike Lothian wrote:
> Hi
>
> Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C connector and no displayport
>
> Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working based on your testing?
>
> I've been putting off buying one until I knew 4K@60Hz would work, CEC would be nice to have too
We have done a lot of testing of USB-C to HDMI adapters and many are awful.
Admittedly, we have a special requirement that the adapter shouldn't enable HDCP if
the sink doesn't support HDCP. For whatever reason many of these adapters enable HDCP
regardless, making them useless for video conferencing where you are not allowed to
share HDCP encrypted video. Besides that issue many also have bad signal integrity
or the voltage of the 5V pin is below the allowed minimum voltage.
The best is the Club 3D CAC-1504, but that is one that doesn't hook up the
CEC pin :-( That's a shame since this one was fully within the HDMI specifications.
If you want CEC, then the Samsung EE-PW700 is best.
BTW, the Kramer adapter I mentioned below is indeed the ADC-U31C/HF model.
There are some more adapters that I can test next week, and I'll see if I can also
test a bunch of (mini-)DP to HDMI adapters.
Regards,
Hans
>
> Thanks
>
> Mike
>
> On Thu, 25 May 2017 at 16:06 Hans Verkuil <hverkuil@xs4all.nl <mailto:hverkuil@xs4all.nl>> wrote:
>
> From: Hans Verkuil <hans.verkuil@cisco.com <mailto:hans.verkuil@cisco.com>>
>
> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> protocol.
>
> This patch series is based on v4.12-rc2.
>
> The first four patches add support for a new CEC capability which is
> needed for these devices and for two helper functions.
>
> Then the DP CEC registers are added using Clint's patch.
>
> The core CEC tunneling support is added to drm_dp_cec.c.
>
> And finally this is hooked up in the i915 driver.
>
> Ideally the cec driver is created and destroyed whenever the DP-to-HDMI
> adapter is connected/disconnected, but I have not been a able to find
> a way to distinguish between connecting/disconnecting the HDMI cable
> and connecting/disconnecting the actual DP-to-HDMI adapter.
>
> My current approach is to check the CEC tunneling support whenever a new
> display is connected:
>
> - if CEC tunneling is supported, but no CEC adapter exists, then create one.
> - if CEC tunneling is not supported, then unregister the CEC adapter if one
> was created earlier.
> - if CEC tunneling is supported and the capabilities are identical to the
> existing CEC adapter, then leave it be.
> - if CEC tunneling is supported and the capabilities are different to the
> existing CEC adapter, then unregister that CEC adapter and register a
> new one.
>
> This works well, but it would be much nicer if I would just know when the
> DP adapter is disconnected as opposed to when the HDMI cable is disconnected
> from the adapter. Suggestions are welcome.
>
> The other remaining problem is that there are DP/USB-C to HDMI adapters that
> support CEC tunneling in the chipset, but where the CEC pin is simply never
> hooked up. From the point of view of the driver CEC is supported, but you'll
> never see any other devices.
>
> I am considering sending a CEC POLL message to logical address 0 (the TV)
> to detect if the CEC pin is connected, but this is not 100% guaranteed to
> work. This can be put under a kernel config option, though.
>
> I think I need to do something for this since of the 5 USB-C to HDMI
> adapters I've tested that set the CEC tunneling capability, only 2 have
> the CEC pin hooked up. So this seems to be quite common.
>
> I have tested this with my Intel NUC7i5BNK and with the two working
> USB-C to HDMI adapters that I have found:
>
> a Samsung EE-PW700 adapter and a Kramer ADC-U31C/HF adapter (I think that's
> the model, I need to confirm this).
>
> As usual the specifications of these adapters never, ever tell you whether
> this is supported or not :-( It's trial and error to find one that works. In
> fact, of the 10 USB-C to HDMI adapters I tested 5 didn't support CEC tunneling
> at all, and of the remaining 5 only two had the CEC pin hooked up and so
> actually worked.
>
> BTW, all adapters that supported CEC tunneling used the Parade PS176 chip.
>
> Output of cec-ctl -S (discovers the CEC topology):
>
> $ cec-ctl -S
> Driver Info:
> Driver Name : i915
> Adapter Name : DPDDC-C
> Capabilities : 0x0000007e
> Logical Addresses
> Transmit
> Passthrough
> Remote Control Support
> Monitor All
> Driver version : 4.12.0
> Available Logical Addresses: 4
> Physical Address : 3.0.0.0
> Logical Address Mask : 0x0010
> CEC Version : 2.0
> Vendor ID : 0x000c03 (HDMI)
> OSD Name : 'Playback'
> Logical Addresses : 1 (Allow RC Passthrough)
>
> Logical Address : 4 (Playback Device 1)
> Primary Device Type : Playback
> Logical Address Type : Playback
> All Device Types : Playback
> RC TV Profile : None
> Device Features :
> None
>
> System Information for device 0 (TV) from device 4 (Playback Device 1):
> CEC Version : 1.4
> Physical Address : 0.0.0.0
> Primary Device Type : TV
> Vendor ID : 0x0000f0 (Samsung)
> OSD Name : TV
> Menu Language : eng
> Power Status : On
>
> Topology:
>
> 0.0.0.0 <http://0.0.0.0>: TV
> 3.0.0.0 <http://3.0.0.0>: Playback Device 1
>
> Regards,
>
> Hans
>
> Clint Taylor (1):
> drm/cec: Add CEC over Aux register definitions
>
> Hans Verkuil (6):
> cec: add CEC_CAP_NEEDS_HPD
> cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD
> cec: add cec_s_phys_addr_from_edid helper function
> cec: add cec_phys_addr_invalidate() helper function
> drm: add support for DisplayPort CEC-Tunneling-over-AUX
> drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
>
> .../media/uapi/cec/cec-ioc-adap-g-caps.rst | 8 +
> drivers/gpu/drm/Kconfig | 3 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_dp_cec.c | 196 +++++++++++++++++++++
> drivers/gpu/drm/i915/Kconfig | 11 ++
> drivers/gpu/drm/i915/intel_dp.c | 46 ++++-
> drivers/media/cec/cec-adap.c | 34 +++-
> drivers/media/cec/cec-api.c | 5 +-
> drivers/media/cec/cec-core.c | 1 +
> include/drm/drm_dp_helper.h | 83 +++++++++
> include/media/cec.h | 15 ++
> include/uapi/linux/cec.h | 2 +
> 12 files changed, 394 insertions(+), 11 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_dp_cec.c
>
> --
> 2.11.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org <mailto: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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-25 15:06 ` Hans Verkuil
(?)
@ 2017-05-26 7:15 ` Daniel Vetter
2017-05-26 10:20 ` Hans Verkuil
-1 siblings, 1 reply; 46+ messages in thread
From: Daniel Vetter @ 2017-05-26 7:15 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, dri-devel, intel-gfx, Clint Taylor, Jani Nikula,
Daniel Vetter, Hans Verkuil
On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Implement support for this DisplayPort feature.
>
> The cec device is created whenever it detects an adapter that
> has this feature. It is only removed when a new adapter is connected
> that does not support this. If a new adapter is connected that has
> different properties than the previous one, then the old cec device is
> unregistered and a new one is registered to replace the old one.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Some small comments below.
> ---
> drivers/gpu/drm/i915/Kconfig | 11 ++++++++++
> drivers/gpu/drm/i915/intel_dp.c | 46 +++++++++++++++++++++++++++++++++++++----
> 2 files changed, 53 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index a5cd5dacf055..f317b13a1409 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
> Choose this option if you want to enable KVMGT support for
> Intel GVT-g.
>
> +config DRM_I915_DP_CEC
> + tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> + depends on DRM_I915 && CEC_CORE
> + select DRM_DP_CEC
> + help
> + Choose this option if you want to enable HDMI CEC support for
> + DisplayPort/USB-C to HDMI adapters.
> +
> + Note: not all adapters support this feature, and even for those
> + that do support this often do not hook up the CEC pin.
Why Kconfig? There's not anything else optional in i915.ko (except debug
stuff ofc), since generally just not worth the pain. Also doesn't seem to
be wired up at all :-)
> +
> menu "drm/i915 Debugging"
> depends on DRM_I915
> depends on EXPERT
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ee77b519835c..38e17ee2548d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -32,6 +32,7 @@
> #include <linux/notifier.h>
> #include <linux/reboot.h>
> #include <asm/byteorder.h>
> +#include <media/cec.h>
> #include <drm/drmP.h>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_crtc.h>
> @@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
> static void
> intel_dp_aux_fini(struct intel_dp *intel_dp)
> {
> + cec_unregister_adapter(intel_dp->aux.cec_adap);
> kfree(intel_dp->aux.name);
> }
>
> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> return -EINVAL;
> }
>
> +static bool
> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
> +{
> + bool handled = false;
> +
> + for (;;) {
> + u8 cec_irq;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + &cec_irq);
> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
> + return handled;
> +
> + cec_irq &= ~DP_CEC_IRQ;
> + drm_dp_cec_irq(&intel_dp->aux);
> + handled = true;
> +
> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + cec_irq);
> + if (ret < 0)
> + return handled;
> + }
> +}
Shouldn't the above be a helper in the cec library? Doesn't look i915
specific to me at least ...
> +
> static void
> intel_dp_retrain_link(struct intel_dp *intel_dp)
> {
> @@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
> intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
> else
> intel_dp->has_audio = drm_detect_monitor_audio(edid);
> + cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
> }
>
> static void
> @@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>
> kfree(intel_connector->detect_edid);
> intel_connector->detect_edid = NULL;
> + cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>
> intel_dp->has_audio = false;
> }
> @@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
>
> /* Can't disconnect eDP, but you can close the lid... */
> - if (is_edp(intel_dp))
> + if (is_edp(intel_dp)) {
> status = edp_detect(intel_dp);
> - else if (intel_digital_port_connected(to_i915(dev),
> - dp_to_dig_port(intel_dp)))
> + } else if (intel_digital_port_connected(to_i915(dev),
> + dp_to_dig_port(intel_dp))) {
> status = intel_dp_detect_dpcd(intel_dp);
> - else
> + if (status == connector_status_connected)
> + drm_dp_cec_configure_adapter(&intel_dp->aux,
> + intel_dp->aux.name, dev->dev);
Did you look into also wiring this up for dp mst chains?
-Daniel
> + } else {
> status = connector_status_disconnected;
> + }
>
> if (status == connector_status_disconnected) {
> memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
> @@ -5080,6 +5115,9 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>
> intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
>
> + if (intel_dp->aux.cec_adap)
> + intel_dp_check_cec_status(intel_dp);
> +
> if (intel_dp->is_mst) {
> if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
> /*
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-25 15:06 ` Hans Verkuil
@ 2017-05-26 7:18 ` Daniel Vetter
-1 siblings, 0 replies; 46+ messages in thread
From: Daniel Vetter @ 2017-05-26 7:18 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, dri-devel, intel-gfx, Clint Taylor, Jani Nikula,
Daniel Vetter, Hans Verkuil
On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> 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 <hans.verkuil@cisco.com>
> ---
> 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.
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 000000000000..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 <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <drm/drm_dp_helper.h>
> +#include <media/cec.h>
> +
> +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 int retries = attempts - 1;
> + ssize_t err;
> +
> + err = drm_dp_dpcd_write(aux, DP_CEC_TX_MESSAGE_BUFFER,
> + msg->msg, msg->len);
> + if (err < 0)
> + return err;
> +
> + if (retries > 5)
> + retries = 5;
> + err = drm_dp_dpcd_writeb(aux, DP_CEC_TX_MESSAGE_INFO,
> + (msg->len - 1) | (retries << 4) |
> + DP_CEC_TX_MESSAGE_SEND);
> + return err < 0 ? err : 0;
> +}
> +
> +static int drm_dp_cec_adap_monitor_all_enable(struct cec_adapter *adap,
> + bool enable)
> +{
> + struct drm_dp_aux *aux = cec_get_drvdata(adap);
> + ssize_t err;
> + u8 val;
> +
> + if (!(adap->capabilities & CEC_CAP_MONITOR_ALL))
> + return 0;
> +
> + err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CONTROL, &val);
> + if (err >= 0) {
> + if (enable)
> + val |= DP_CEC_SNOOPING_ENABLE;
> + else
> + val &= ~DP_CEC_SNOOPING_ENABLE;
> + err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
> + }
> + return (enable && err < 0) ? err : 0;
> +}
> +
> +static const struct cec_adap_ops drm_dp_cec_adap_ops = {
> + .adap_enable = drm_dp_cec_adap_enable,
> + .adap_log_addr = drm_dp_cec_adap_log_addr,
> + .adap_transmit = drm_dp_cec_adap_transmit,
> + .adap_monitor_all_enable = drm_dp_cec_adap_monitor_all_enable,
> +};
> +
> +static int drm_dp_cec_received(struct drm_dp_aux *aux)
> +{
> + struct cec_adapter *adap = aux->cec_adap;
> + struct cec_msg msg;
> + u8 rx_msg_info;
> + ssize_t err;
> +
> + err = drm_dp_dpcd_readb(aux, DP_CEC_RX_MESSAGE_INFO, &rx_msg_info);
> + if (err < 0)
> + return err;
> + if (!(rx_msg_info & DP_CEC_RX_MESSAGE_ENDED))
> + return 0;
> + msg.len = (rx_msg_info & DP_CEC_RX_MESSAGE_LEN_MASK) + 1;
> + err = drm_dp_dpcd_read(aux, DP_CEC_RX_MESSAGE_BUFFER, msg.msg, msg.len);
> + if (err < 0)
> + return err;
> + cec_received_msg(adap, &msg);
> + return 0;
> +}
> +
> +int drm_dp_cec_irq(struct drm_dp_aux *aux)
> +{
> + struct cec_adapter *adap = aux->cec_adap;
> + u8 flags;
> + ssize_t err;
> +
> + if (!aux->cec_adap)
> + return 0;
> +
> + err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, &flags);
> + if (err < 0)
> + return err;
> +
> + if (flags & DP_CEC_RX_MESSAGE_INFO_VALID)
> + drm_dp_cec_received(aux);
> +
> + if (flags & DP_CEC_TX_MESSAGE_SENT)
> + cec_transmit_done(adap, CEC_TX_STATUS_OK, 0, 0, 0, 0);
> + else if (flags & DP_CEC_TX_LINE_ERROR)
> + cec_transmit_done(adap, CEC_TX_STATUS_ERROR |
> + CEC_TX_STATUS_MAX_RETRIES, 0, 0, 0, 1);
> + else if (flags &
> + (DP_CEC_TX_ADDRESS_NACK_ERROR | DP_CEC_TX_DATA_NACK_ERROR))
> + cec_transmit_done(adap, CEC_TX_STATUS_NACK |
> + CEC_TX_STATUS_MAX_RETRIES, 0, 1, 0, 0);
> + drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, flags);
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_cec_irq);
> +
> +int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
> + struct device *parent)
> +{
> + u32 cec_caps = CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
> + CEC_CAP_PASSTHROUGH | CEC_CAP_RC | CEC_CAP_NEEDS_HPD;
> + unsigned int num_las = 1;
> + int err;
> + u8 cap;
> +
> + if (drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CAPABILITY, &cap) != 1 ||
> + !(cap & DP_CEC_TUNNELING_CAPABLE)) {
> + cec_unregister_adapter(aux->cec_adap);
> + aux->cec_adap = NULL;
> + return -ENODEV;
> + }
> +
> + if (cap & DP_CEC_SNOOPING_CAPABLE)
> + cec_caps |= CEC_CAP_MONITOR_ALL;
> + if (cap & DP_CEC_MULTIPLE_LA_CAPABLE)
> + num_las = CEC_MAX_LOG_ADDRS;
> +
> + if (!IS_ERR_OR_NULL(aux->cec_adap)) {
> + if (aux->cec_adap->capabilities == cec_caps &&
> + aux->cec_adap->available_log_addrs == num_las)
> + return 0;
> + cec_unregister_adapter(aux->cec_adap);
> + }
> +
> + aux->cec_adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
> + aux, name, cec_caps, num_las);
> + if (IS_ERR(aux->cec_adap)) {
> + err = PTR_ERR(aux->cec_adap);
> + aux->cec_adap = NULL;
> + return err;
> + }
> + err = cec_register_adapter(aux->cec_adap, parent);
> + if (err) {
> + cec_delete_adapter(aux->cec_adap);
> + aux->cec_adap = NULL;
> + }
> + return err;
> +}
> +EXPORT_SYMBOL(drm_dp_cec_configure_adapter);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 3f4ad709534e..1e373df48108 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -843,6 +843,8 @@ struct drm_dp_aux_msg {
> size_t size;
> };
>
> +struct cec_adapter;
> +
> /**
> * struct drm_dp_aux - DisplayPort AUX channel
> * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
> @@ -901,6 +903,10 @@ struct drm_dp_aux {
> * @i2c_defer_count: Counts I2C DEFERs, used for DP validation.
> */
> unsigned i2c_defer_count;
> + /**
> + * @cec_adap: the CEC adapter for CEC-Tunneling-over-AUX support.
> + */
> + struct cec_adapter *cec_adap;
> };
>
> ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
> @@ -972,4 +978,22 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
> int drm_dp_stop_crc(struct drm_dp_aux *aux);
>
> +#ifdef CONFIG_DRM_DP_CEC
> +int drm_dp_cec_irq(struct drm_dp_aux *aux);
> +int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
> + struct device *parent);
> +#else
> +static inline int drm_dp_cec_irq(struct drm_dp_aux *aux)
> +{
> + return 0;
> +}
> +
> +static inline int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux,
> + const char *name,
> + struct device *parent)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
@ 2017-05-26 7:18 ` Daniel Vetter
0 siblings, 0 replies; 46+ messages in thread
From: Daniel Vetter @ 2017-05-26 7:18 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Jani Nikula, intel-gfx, dri-devel, Hans Verkuil, linux-media
On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> 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 <hans.verkuil@cisco.com>
> ---
> 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.
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 000000000000..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 <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <drm/drm_dp_helper.h>
> +#include <media/cec.h>
> +
> +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 int retries = attempts - 1;
> + ssize_t err;
> +
> + err = drm_dp_dpcd_write(aux, DP_CEC_TX_MESSAGE_BUFFER,
> + msg->msg, msg->len);
> + if (err < 0)
> + return err;
> +
> + if (retries > 5)
> + retries = 5;
> + err = drm_dp_dpcd_writeb(aux, DP_CEC_TX_MESSAGE_INFO,
> + (msg->len - 1) | (retries << 4) |
> + DP_CEC_TX_MESSAGE_SEND);
> + return err < 0 ? err : 0;
> +}
> +
> +static int drm_dp_cec_adap_monitor_all_enable(struct cec_adapter *adap,
> + bool enable)
> +{
> + struct drm_dp_aux *aux = cec_get_drvdata(adap);
> + ssize_t err;
> + u8 val;
> +
> + if (!(adap->capabilities & CEC_CAP_MONITOR_ALL))
> + return 0;
> +
> + err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CONTROL, &val);
> + if (err >= 0) {
> + if (enable)
> + val |= DP_CEC_SNOOPING_ENABLE;
> + else
> + val &= ~DP_CEC_SNOOPING_ENABLE;
> + err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
> + }
> + return (enable && err < 0) ? err : 0;
> +}
> +
> +static const struct cec_adap_ops drm_dp_cec_adap_ops = {
> + .adap_enable = drm_dp_cec_adap_enable,
> + .adap_log_addr = drm_dp_cec_adap_log_addr,
> + .adap_transmit = drm_dp_cec_adap_transmit,
> + .adap_monitor_all_enable = drm_dp_cec_adap_monitor_all_enable,
> +};
> +
> +static int drm_dp_cec_received(struct drm_dp_aux *aux)
> +{
> + struct cec_adapter *adap = aux->cec_adap;
> + struct cec_msg msg;
> + u8 rx_msg_info;
> + ssize_t err;
> +
> + err = drm_dp_dpcd_readb(aux, DP_CEC_RX_MESSAGE_INFO, &rx_msg_info);
> + if (err < 0)
> + return err;
> + if (!(rx_msg_info & DP_CEC_RX_MESSAGE_ENDED))
> + return 0;
> + msg.len = (rx_msg_info & DP_CEC_RX_MESSAGE_LEN_MASK) + 1;
> + err = drm_dp_dpcd_read(aux, DP_CEC_RX_MESSAGE_BUFFER, msg.msg, msg.len);
> + if (err < 0)
> + return err;
> + cec_received_msg(adap, &msg);
> + return 0;
> +}
> +
> +int drm_dp_cec_irq(struct drm_dp_aux *aux)
> +{
> + struct cec_adapter *adap = aux->cec_adap;
> + u8 flags;
> + ssize_t err;
> +
> + if (!aux->cec_adap)
> + return 0;
> +
> + err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, &flags);
> + if (err < 0)
> + return err;
> +
> + if (flags & DP_CEC_RX_MESSAGE_INFO_VALID)
> + drm_dp_cec_received(aux);
> +
> + if (flags & DP_CEC_TX_MESSAGE_SENT)
> + cec_transmit_done(adap, CEC_TX_STATUS_OK, 0, 0, 0, 0);
> + else if (flags & DP_CEC_TX_LINE_ERROR)
> + cec_transmit_done(adap, CEC_TX_STATUS_ERROR |
> + CEC_TX_STATUS_MAX_RETRIES, 0, 0, 0, 1);
> + else if (flags &
> + (DP_CEC_TX_ADDRESS_NACK_ERROR | DP_CEC_TX_DATA_NACK_ERROR))
> + cec_transmit_done(adap, CEC_TX_STATUS_NACK |
> + CEC_TX_STATUS_MAX_RETRIES, 0, 1, 0, 0);
> + drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, flags);
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_cec_irq);
> +
> +int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
> + struct device *parent)
> +{
> + u32 cec_caps = CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
> + CEC_CAP_PASSTHROUGH | CEC_CAP_RC | CEC_CAP_NEEDS_HPD;
> + unsigned int num_las = 1;
> + int err;
> + u8 cap;
> +
> + if (drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CAPABILITY, &cap) != 1 ||
> + !(cap & DP_CEC_TUNNELING_CAPABLE)) {
> + cec_unregister_adapter(aux->cec_adap);
> + aux->cec_adap = NULL;
> + return -ENODEV;
> + }
> +
> + if (cap & DP_CEC_SNOOPING_CAPABLE)
> + cec_caps |= CEC_CAP_MONITOR_ALL;
> + if (cap & DP_CEC_MULTIPLE_LA_CAPABLE)
> + num_las = CEC_MAX_LOG_ADDRS;
> +
> + if (!IS_ERR_OR_NULL(aux->cec_adap)) {
> + if (aux->cec_adap->capabilities == cec_caps &&
> + aux->cec_adap->available_log_addrs == num_las)
> + return 0;
> + cec_unregister_adapter(aux->cec_adap);
> + }
> +
> + aux->cec_adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
> + aux, name, cec_caps, num_las);
> + if (IS_ERR(aux->cec_adap)) {
> + err = PTR_ERR(aux->cec_adap);
> + aux->cec_adap = NULL;
> + return err;
> + }
> + err = cec_register_adapter(aux->cec_adap, parent);
> + if (err) {
> + cec_delete_adapter(aux->cec_adap);
> + aux->cec_adap = NULL;
> + }
> + return err;
> +}
> +EXPORT_SYMBOL(drm_dp_cec_configure_adapter);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 3f4ad709534e..1e373df48108 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -843,6 +843,8 @@ struct drm_dp_aux_msg {
> size_t size;
> };
>
> +struct cec_adapter;
> +
> /**
> * struct drm_dp_aux - DisplayPort AUX channel
> * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
> @@ -901,6 +903,10 @@ struct drm_dp_aux {
> * @i2c_defer_count: Counts I2C DEFERs, used for DP validation.
> */
> unsigned i2c_defer_count;
> + /**
> + * @cec_adap: the CEC adapter for CEC-Tunneling-over-AUX support.
> + */
> + struct cec_adapter *cec_adap;
> };
>
> ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
> @@ -972,4 +978,22 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
> int drm_dp_stop_crc(struct drm_dp_aux *aux);
>
> +#ifdef CONFIG_DRM_DP_CEC
> +int drm_dp_cec_irq(struct drm_dp_aux *aux);
> +int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
> + struct device *parent);
> +#else
> +static inline int drm_dp_cec_irq(struct drm_dp_aux *aux)
> +{
> + return 0;
> +}
> +
> +static inline int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux,
> + const char *name,
> + struct device *parent)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions
2017-05-25 15:06 ` Hans Verkuil
@ 2017-05-26 8:39 ` Jani Nikula
-1 siblings, 0 replies; 46+ messages in thread
From: Jani Nikula @ 2017-05-26 8:39 UTC (permalink / raw)
To: Hans Verkuil, linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Daniel Vetter
On Thu, 25 May 2017, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> From: Clint Taylor <clinton.a.taylor@intel.com>
>
> Adding DPCD register definitions from the DP 1.3 specification for CEC
> over AUX support.
>
> V2: Add DP_ prefix to all defines.
> V3: missed prefixes from the ESI1 defines
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> Link: http://patchwork.freedesktop.org/patch/msgid/1492703263-11494-1-git-send-email-clinton.a.taylor@intel.com
This one's already in drm-next as
commit d753e41d475421543eaaea5f0feadba827f5fa01
Author: Clint Taylor <clinton.a.taylor@intel.com>
Date: Thu Apr 20 08:47:43 2017 -0700
drm/cec: Add CEC over Aux register definitions
BR,
Jani.
> ---
> include/drm/drm_dp_helper.h | 59 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c0bd0d7651a9..3f4ad709534e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -603,6 +603,9 @@
> #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */
>
> #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */
> +# define DP_RX_GTC_MSTR_REQ_STATUS_CHANGE (1 << 0)
> +# define DP_LOCK_ACQUISITION_REQUEST (1 << 1)
> +# define DP_CEC_IRQ (1 << 2)
>
> #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
>
> @@ -636,6 +639,62 @@
> # define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */
> # define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */
>
> +/* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
> +#define DP_CEC_TUNNELING_CAPABILITY 0x3000
> +# define DP_CEC_TUNNELING_CAPABLE (1 << 0)
> +# define DP_CEC_SNOOPING_CAPABLE (1 << 1)
> +# define DP_CEC_MULTIPLE_LA_CAPABLE (1 << 2)
> +
> +#define DP_CEC_TUNNELING_CONTROL 0x3001
> +# define DP_CEC_TUNNELING_ENABLE (1 << 0)
> +# define DP_CEC_SNOOPING_ENABLE (1 << 1)
> +
> +#define DP_CEC_RX_MESSAGE_INFO 0x3002
> +# define DP_CEC_RX_MESSAGE_LEN_MASK (0xf << 0)
> +# define DP_CEC_RX_MESSAGE_LEN_SHIFT 0
> +# define DP_CEC_RX_MESSAGE_HPD_STATE (1 << 4)
> +# define DP_CEC_RX_MESSAGE_HPD_LOST (1 << 5)
> +# define DP_CEC_RX_MESSAGE_ACKED (1 << 6)
> +# define DP_CEC_RX_MESSAGE_ENDED (1 << 7)
> +
> +#define DP_CEC_TX_MESSAGE_INFO 0x3003
> +# define DP_CEC_TX_MESSAGE_LEN_MASK (0xf << 0)
> +# define DP_CEC_TX_MESSAGE_LEN_SHIFT 0
> +# define DP_CEC_TX_RETRY_COUNT_MASK (0x7 << 4)
> +# define DP_CEC_TX_RETRY_COUNT_SHIFT 4
> +# define DP_CEC_TX_MESSAGE_SEND (1 << 7)
> +
> +#define DP_CEC_TUNNELING_IRQ_FLAGS 0x3004
> +# define DP_CEC_RX_MESSAGE_INFO_VALID (1 << 0)
> +# define DP_CEC_RX_MESSAGE_OVERFLOW (1 << 1)
> +# define DP_CEC_TX_MESSAGE_SENT (1 << 4)
> +# define DP_CEC_TX_LINE_ERROR (1 << 5)
> +# define DP_CEC_TX_ADDRESS_NACK_ERROR (1 << 6)
> +# define DP_CEC_TX_DATA_NACK_ERROR (1 << 7)
> +
> +#define DP_CEC_LOGICAL_ADDRESS_MASK 0x300E /* 0x300F word */
> +# define DP_CEC_LOGICAL_ADDRESS_0 (1 << 0)
> +# define DP_CEC_LOGICAL_ADDRESS_1 (1 << 1)
> +# define DP_CEC_LOGICAL_ADDRESS_2 (1 << 2)
> +# define DP_CEC_LOGICAL_ADDRESS_3 (1 << 3)
> +# define DP_CEC_LOGICAL_ADDRESS_4 (1 << 4)
> +# define DP_CEC_LOGICAL_ADDRESS_5 (1 << 5)
> +# define DP_CEC_LOGICAL_ADDRESS_6 (1 << 6)
> +# define DP_CEC_LOGICAL_ADDRESS_7 (1 << 7)
> +#define DP_CEC_LOGICAL_ADDRESS_MASK_2 0x300F /* 0x300E word */
> +# define DP_CEC_LOGICAL_ADDRESS_8 (1 << 0)
> +# define DP_CEC_LOGICAL_ADDRESS_9 (1 << 1)
> +# define DP_CEC_LOGICAL_ADDRESS_10 (1 << 2)
> +# define DP_CEC_LOGICAL_ADDRESS_11 (1 << 3)
> +# define DP_CEC_LOGICAL_ADDRESS_12 (1 << 4)
> +# define DP_CEC_LOGICAL_ADDRESS_13 (1 << 5)
> +# define DP_CEC_LOGICAL_ADDRESS_14 (1 << 6)
> +# define DP_CEC_LOGICAL_ADDRESS_15 (1 << 7)
> +
> +#define DP_CEC_RX_MESSAGE_BUFFER 0x3010
> +#define DP_CEC_TX_MESSAGE_BUFFER 0x3020
> +#define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
> +
> /* DP 1.2 Sideband message defines */
> /* peer device type - DP 1.2a Table 2-92 */
> #define DP_PEER_DEVICE_NONE 0x0
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions
@ 2017-05-26 8:39 ` Jani Nikula
0 siblings, 0 replies; 46+ messages in thread
From: Jani Nikula @ 2017-05-26 8:39 UTC (permalink / raw)
To: Hans Verkuil, linux-media; +Cc: intel-gfx, dri-devel
On Thu, 25 May 2017, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> From: Clint Taylor <clinton.a.taylor@intel.com>
>
> Adding DPCD register definitions from the DP 1.3 specification for CEC
> over AUX support.
>
> V2: Add DP_ prefix to all defines.
> V3: missed prefixes from the ESI1 defines
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> Link: http://patchwork.freedesktop.org/patch/msgid/1492703263-11494-1-git-send-email-clinton.a.taylor@intel.com
This one's already in drm-next as
commit d753e41d475421543eaaea5f0feadba827f5fa01
Author: Clint Taylor <clinton.a.taylor@intel.com>
Date: Thu Apr 20 08:47:43 2017 -0700
drm/cec: Add CEC over Aux register definitions
BR,
Jani.
> ---
> include/drm/drm_dp_helper.h | 59 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c0bd0d7651a9..3f4ad709534e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -603,6 +603,9 @@
> #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */
>
> #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */
> +# define DP_RX_GTC_MSTR_REQ_STATUS_CHANGE (1 << 0)
> +# define DP_LOCK_ACQUISITION_REQUEST (1 << 1)
> +# define DP_CEC_IRQ (1 << 2)
>
> #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
>
> @@ -636,6 +639,62 @@
> # define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */
> # define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */
>
> +/* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
> +#define DP_CEC_TUNNELING_CAPABILITY 0x3000
> +# define DP_CEC_TUNNELING_CAPABLE (1 << 0)
> +# define DP_CEC_SNOOPING_CAPABLE (1 << 1)
> +# define DP_CEC_MULTIPLE_LA_CAPABLE (1 << 2)
> +
> +#define DP_CEC_TUNNELING_CONTROL 0x3001
> +# define DP_CEC_TUNNELING_ENABLE (1 << 0)
> +# define DP_CEC_SNOOPING_ENABLE (1 << 1)
> +
> +#define DP_CEC_RX_MESSAGE_INFO 0x3002
> +# define DP_CEC_RX_MESSAGE_LEN_MASK (0xf << 0)
> +# define DP_CEC_RX_MESSAGE_LEN_SHIFT 0
> +# define DP_CEC_RX_MESSAGE_HPD_STATE (1 << 4)
> +# define DP_CEC_RX_MESSAGE_HPD_LOST (1 << 5)
> +# define DP_CEC_RX_MESSAGE_ACKED (1 << 6)
> +# define DP_CEC_RX_MESSAGE_ENDED (1 << 7)
> +
> +#define DP_CEC_TX_MESSAGE_INFO 0x3003
> +# define DP_CEC_TX_MESSAGE_LEN_MASK (0xf << 0)
> +# define DP_CEC_TX_MESSAGE_LEN_SHIFT 0
> +# define DP_CEC_TX_RETRY_COUNT_MASK (0x7 << 4)
> +# define DP_CEC_TX_RETRY_COUNT_SHIFT 4
> +# define DP_CEC_TX_MESSAGE_SEND (1 << 7)
> +
> +#define DP_CEC_TUNNELING_IRQ_FLAGS 0x3004
> +# define DP_CEC_RX_MESSAGE_INFO_VALID (1 << 0)
> +# define DP_CEC_RX_MESSAGE_OVERFLOW (1 << 1)
> +# define DP_CEC_TX_MESSAGE_SENT (1 << 4)
> +# define DP_CEC_TX_LINE_ERROR (1 << 5)
> +# define DP_CEC_TX_ADDRESS_NACK_ERROR (1 << 6)
> +# define DP_CEC_TX_DATA_NACK_ERROR (1 << 7)
> +
> +#define DP_CEC_LOGICAL_ADDRESS_MASK 0x300E /* 0x300F word */
> +# define DP_CEC_LOGICAL_ADDRESS_0 (1 << 0)
> +# define DP_CEC_LOGICAL_ADDRESS_1 (1 << 1)
> +# define DP_CEC_LOGICAL_ADDRESS_2 (1 << 2)
> +# define DP_CEC_LOGICAL_ADDRESS_3 (1 << 3)
> +# define DP_CEC_LOGICAL_ADDRESS_4 (1 << 4)
> +# define DP_CEC_LOGICAL_ADDRESS_5 (1 << 5)
> +# define DP_CEC_LOGICAL_ADDRESS_6 (1 << 6)
> +# define DP_CEC_LOGICAL_ADDRESS_7 (1 << 7)
> +#define DP_CEC_LOGICAL_ADDRESS_MASK_2 0x300F /* 0x300E word */
> +# define DP_CEC_LOGICAL_ADDRESS_8 (1 << 0)
> +# define DP_CEC_LOGICAL_ADDRESS_9 (1 << 1)
> +# define DP_CEC_LOGICAL_ADDRESS_10 (1 << 2)
> +# define DP_CEC_LOGICAL_ADDRESS_11 (1 << 3)
> +# define DP_CEC_LOGICAL_ADDRESS_12 (1 << 4)
> +# define DP_CEC_LOGICAL_ADDRESS_13 (1 << 5)
> +# define DP_CEC_LOGICAL_ADDRESS_14 (1 << 6)
> +# define DP_CEC_LOGICAL_ADDRESS_15 (1 << 7)
> +
> +#define DP_CEC_RX_MESSAGE_BUFFER 0x3010
> +#define DP_CEC_TX_MESSAGE_BUFFER 0x3020
> +#define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
> +
> /* DP 1.2 Sideband message defines */
> /* peer device type - DP 1.2a Table 2-92 */
> #define DP_PEER_DEVICE_NONE 0x0
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-25 15:06 ` Hans Verkuil
@ 2017-05-26 10:13 ` Jani Nikula
-1 siblings, 0 replies; 46+ messages in thread
From: Jani Nikula @ 2017-05-26 10:13 UTC (permalink / raw)
To: Hans Verkuil, linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Daniel Vetter, Hans Verkuil
On Thu, 25 May 2017, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> return -EINVAL;
> }
>
> +static bool
> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
> +{
> + bool handled = false;
> +
> + for (;;) {
> + u8 cec_irq;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + &cec_irq);
> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
> + return handled;
> +
> + cec_irq &= ~DP_CEC_IRQ;
> + drm_dp_cec_irq(&intel_dp->aux);
> + handled = true;
> +
> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + cec_irq);
> + if (ret < 0)
> + return handled;
> + }
DP sinks suck. Please add a limit to the loop.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
@ 2017-05-26 10:13 ` Jani Nikula
0 siblings, 0 replies; 46+ messages in thread
From: Jani Nikula @ 2017-05-26 10:13 UTC (permalink / raw)
To: Hans Verkuil, linux-media; +Cc: intel-gfx, Hans Verkuil, dri-devel
On Thu, 25 May 2017, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> return -EINVAL;
> }
>
> +static bool
> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
> +{
> + bool handled = false;
> +
> + for (;;) {
> + u8 cec_irq;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + &cec_irq);
> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
> + return handled;
> +
> + cec_irq &= ~DP_CEC_IRQ;
> + drm_dp_cec_irq(&intel_dp->aux);
> + handled = true;
> +
> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + cec_irq);
> + if (ret < 0)
> + return handled;
> + }
DP sinks suck. Please add a limit to the loop.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-26 10:13 ` Jani Nikula
@ 2017-05-26 10:13 ` Hans Verkuil
-1 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-26 10:13 UTC (permalink / raw)
To: Jani Nikula, linux-media
Cc: dri-devel, intel-gfx, Clint Taylor, Daniel Vetter, Hans Verkuil
On 05/26/2017 12:13 PM, Jani Nikula wrote:
> On Thu, 25 May 2017, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
>> +{
>> + bool handled = false;
>> +
>> + for (;;) {
>> + u8 cec_irq;
>> + int ret;
>> +
>> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + &cec_irq);
>> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
>> + return handled;
>> +
>> + cec_irq &= ~DP_CEC_IRQ;
>> + drm_dp_cec_irq(&intel_dp->aux);
>> + handled = true;
>> +
>> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + cec_irq);
>> + if (ret < 0)
>> + return handled;
>> + }
>
> DP sinks suck. Please add a limit to the loop.
Good to know. I wondered about that.
Regards,
Hans
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
@ 2017-05-26 10:13 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-26 10:13 UTC (permalink / raw)
To: Jani Nikula, linux-media; +Cc: intel-gfx, Hans Verkuil, dri-devel
On 05/26/2017 12:13 PM, Jani Nikula wrote:
> On Thu, 25 May 2017, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
>> +{
>> + bool handled = false;
>> +
>> + for (;;) {
>> + u8 cec_irq;
>> + int ret;
>> +
>> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + &cec_irq);
>> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
>> + return handled;
>> +
>> + cec_irq &= ~DP_CEC_IRQ;
>> + drm_dp_cec_irq(&intel_dp->aux);
>> + handled = true;
>> +
>> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + cec_irq);
>> + if (ret < 0)
>> + return handled;
>> + }
>
> DP sinks suck. Please add a limit to the loop.
Good to know. I wondered about that.
Regards,
Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-26 7:15 ` Daniel Vetter
@ 2017-05-26 10:20 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-26 10:20 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-media, dri-devel, intel-gfx, Clint Taylor, Jani Nikula,
Hans Verkuil
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> Implement support for this DisplayPort feature.
>>
>> The cec device is created whenever it detects an adapter that
>> has this feature. It is only removed when a new adapter is connected
>> that does not support this. If a new adapter is connected that has
>> different properties than the previous one, then the old cec device is
>> unregistered and a new one is registered to replace the old one.
>>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>
> Some small comments below.
>
>> ---
>> drivers/gpu/drm/i915/Kconfig | 11 ++++++++++
>> drivers/gpu/drm/i915/intel_dp.c | 46 +++++++++++++++++++++++++++++++++++++----
>> 2 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index a5cd5dacf055..f317b13a1409 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
>> Choose this option if you want to enable KVMGT support for
>> Intel GVT-g.
>>
>> +config DRM_I915_DP_CEC
>> + tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
>> + depends on DRM_I915 && CEC_CORE
>> + select DRM_DP_CEC
>> + help
>> + Choose this option if you want to enable HDMI CEC support for
>> + DisplayPort/USB-C to HDMI adapters.
>> +
>> + Note: not all adapters support this feature, and even for those
>> + that do support this often do not hook up the CEC pin.
>
> Why Kconfig? There's not anything else optional in i915.ko (except debug
> stuff ofc), since generally just not worth the pain. Also doesn't seem to
> be wired up at all :-)
It selects DRM_DP_CEC, but you're right, it can be dropped.
>
>> +
>> menu "drm/i915 Debugging"
>> depends on DRM_I915
>> depends on EXPERT
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index ee77b519835c..38e17ee2548d 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -32,6 +32,7 @@
>> #include <linux/notifier.h>
>> #include <linux/reboot.h>
>> #include <asm/byteorder.h>
>> +#include <media/cec.h>
>> #include <drm/drmP.h>
>> #include <drm/drm_atomic_helper.h>
>> #include <drm/drm_crtc.h>
>> @@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
>> static void
>> intel_dp_aux_fini(struct intel_dp *intel_dp)
>> {
>> + cec_unregister_adapter(intel_dp->aux.cec_adap);
>> kfree(intel_dp->aux.name);
>> }
>>
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
>> +{
>> + bool handled = false;
>> +
>> + for (;;) {
>> + u8 cec_irq;
>> + int ret;
>> +
>> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + &cec_irq);
>> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
>> + return handled;
>> +
>> + cec_irq &= ~DP_CEC_IRQ;
>> + drm_dp_cec_irq(&intel_dp->aux);
>> + handled = true;
>> +
>> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + cec_irq);
>> + if (ret < 0)
>> + return handled;
>> + }
>> +}
>
> Shouldn't the above be a helper in the cec library? Doesn't look i915
> specific to me at least ...
Good point, this can be moved to drm_dp_cec_irq().
>
>> +
>> static void
>> intel_dp_retrain_link(struct intel_dp *intel_dp)
>> {
>> @@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>> intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
>> else
>> intel_dp->has_audio = drm_detect_monitor_audio(edid);
>> + cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
>> }
>>
>> static void
>> @@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>>
>> kfree(intel_connector->detect_edid);
>> intel_connector->detect_edid = NULL;
>> + cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>>
>> intel_dp->has_audio = false;
>> }
>> @@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
>> intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
>>
>> /* Can't disconnect eDP, but you can close the lid... */
>> - if (is_edp(intel_dp))
>> + if (is_edp(intel_dp)) {
>> status = edp_detect(intel_dp);
>> - else if (intel_digital_port_connected(to_i915(dev),
>> - dp_to_dig_port(intel_dp)))
>> + } else if (intel_digital_port_connected(to_i915(dev),
>> + dp_to_dig_port(intel_dp))) {
>> status = intel_dp_detect_dpcd(intel_dp);
>> - else
>> + if (status == connector_status_connected)
>> + drm_dp_cec_configure_adapter(&intel_dp->aux,
>> + intel_dp->aux.name, dev->dev);
>
> 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.
Regards,
Hans
> -Daniel
>
>> + } else {
>> status = connector_status_disconnected;
>> + }
>>
>> if (status == connector_status_disconnected) {
>> memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
>> @@ -5080,6 +5115,9 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>>
>> intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
>>
>> + if (intel_dp->aux.cec_adap)
>> + intel_dp_check_cec_status(intel_dp);
>> +
>> if (intel_dp->is_mst) {
>> if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
>> /*
>> --
>> 2.11.0
>>
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
@ 2017-05-26 10:20 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-26 10:20 UTC (permalink / raw)
To: Daniel Vetter
Cc: Jani Nikula, intel-gfx, dri-devel, Hans Verkuil, linux-media
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> Implement support for this DisplayPort feature.
>>
>> The cec device is created whenever it detects an adapter that
>> has this feature. It is only removed when a new adapter is connected
>> that does not support this. If a new adapter is connected that has
>> different properties than the previous one, then the old cec device is
>> unregistered and a new one is registered to replace the old one.
>>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>
> Some small comments below.
>
>> ---
>> drivers/gpu/drm/i915/Kconfig | 11 ++++++++++
>> drivers/gpu/drm/i915/intel_dp.c | 46 +++++++++++++++++++++++++++++++++++++----
>> 2 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index a5cd5dacf055..f317b13a1409 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
>> Choose this option if you want to enable KVMGT support for
>> Intel GVT-g.
>>
>> +config DRM_I915_DP_CEC
>> + tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
>> + depends on DRM_I915 && CEC_CORE
>> + select DRM_DP_CEC
>> + help
>> + Choose this option if you want to enable HDMI CEC support for
>> + DisplayPort/USB-C to HDMI adapters.
>> +
>> + Note: not all adapters support this feature, and even for those
>> + that do support this often do not hook up the CEC pin.
>
> Why Kconfig? There's not anything else optional in i915.ko (except debug
> stuff ofc), since generally just not worth the pain. Also doesn't seem to
> be wired up at all :-)
It selects DRM_DP_CEC, but you're right, it can be dropped.
>
>> +
>> menu "drm/i915 Debugging"
>> depends on DRM_I915
>> depends on EXPERT
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index ee77b519835c..38e17ee2548d 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -32,6 +32,7 @@
>> #include <linux/notifier.h>
>> #include <linux/reboot.h>
>> #include <asm/byteorder.h>
>> +#include <media/cec.h>
>> #include <drm/drmP.h>
>> #include <drm/drm_atomic_helper.h>
>> #include <drm/drm_crtc.h>
>> @@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
>> static void
>> intel_dp_aux_fini(struct intel_dp *intel_dp)
>> {
>> + cec_unregister_adapter(intel_dp->aux.cec_adap);
>> kfree(intel_dp->aux.name);
>> }
>>
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
>> +{
>> + bool handled = false;
>> +
>> + for (;;) {
>> + u8 cec_irq;
>> + int ret;
>> +
>> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + &cec_irq);
>> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
>> + return handled;
>> +
>> + cec_irq &= ~DP_CEC_IRQ;
>> + drm_dp_cec_irq(&intel_dp->aux);
>> + handled = true;
>> +
>> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + cec_irq);
>> + if (ret < 0)
>> + return handled;
>> + }
>> +}
>
> Shouldn't the above be a helper in the cec library? Doesn't look i915
> specific to me at least ...
Good point, this can be moved to drm_dp_cec_irq().
>
>> +
>> static void
>> intel_dp_retrain_link(struct intel_dp *intel_dp)
>> {
>> @@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>> intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
>> else
>> intel_dp->has_audio = drm_detect_monitor_audio(edid);
>> + cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
>> }
>>
>> static void
>> @@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>>
>> kfree(intel_connector->detect_edid);
>> intel_connector->detect_edid = NULL;
>> + cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>>
>> intel_dp->has_audio = false;
>> }
>> @@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
>> intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
>>
>> /* Can't disconnect eDP, but you can close the lid... */
>> - if (is_edp(intel_dp))
>> + if (is_edp(intel_dp)) {
>> status = edp_detect(intel_dp);
>> - else if (intel_digital_port_connected(to_i915(dev),
>> - dp_to_dig_port(intel_dp)))
>> + } else if (intel_digital_port_connected(to_i915(dev),
>> + dp_to_dig_port(intel_dp))) {
>> status = intel_dp_detect_dpcd(intel_dp);
>> - else
>> + if (status == connector_status_connected)
>> + drm_dp_cec_configure_adapter(&intel_dp->aux,
>> + intel_dp->aux.name, dev->dev);
>
> 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.
Regards,
Hans
> -Daniel
>
>> + } else {
>> status = connector_status_disconnected;
>> + }
>>
>> if (status == connector_status_disconnected) {
>> memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
>> @@ -5080,6 +5115,9 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>>
>> intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
>>
>> + if (intel_dp->aux.cec_adap)
>> + intel_dp_check_cec_status(intel_dp);
>> +
>> if (intel_dp->is_mst) {
>> if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
>> /*
>> --
>> 2.11.0
>>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-26 7:18 ` Daniel Vetter
@ 2017-05-26 10:34 ` Hans Verkuil
-1 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-26 10:34 UTC (permalink / raw)
To: Daniel Vetter
Cc: Jani Nikula, intel-gfx, dri-devel, Hans Verkuil, linux-media
On 05/26/2017 09:18 AM, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> 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 <hans.verkuil@cisco.com>
>> ---
>> 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.
For all other CEC implementations I have placed it under a config option. The
reason is that 1) CEC is an optional feature of HDMI and you may not actually
want it, and 2) enabling CEC also pulls in the cec module.
I still think turning this into a drm config option makes sense. This would
replace the i915 config option I made in the next patch, i.e. this config option
is moved up one level.
Your choice, though.
> 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.
Will do.
BTW, do you know if it is possible to detect when a DP-to-HDMI adapter is
connected as I discussed in my cover letter? That's my main open question
for this patch series.
Regarding the other thing I discussed in the cover letter about detecting if
the CEC pin is really hooked up: I think I shouldn't try to be smart. Yes, I
can try to poll for a TV, but that doesn't really say anything about whether
CEC is working or not since the TV itself may not have enabled CEC (actually
quite common).
One alternative might be to poll and, if no TV is detected, call dev_info to
let the user know that either there is no CEC-enabled TV, or the CEC pin isn't
connected.
I'm not sure if that helps the user or not.
Regards,
Hans
>
> Thanks, Daniel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
@ 2017-05-26 10:34 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-26 10:34 UTC (permalink / raw)
To: Daniel Vetter
Cc: Jani Nikula, intel-gfx, Hans Verkuil, dri-devel, linux-media
On 05/26/2017 09:18 AM, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> 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 <hans.verkuil@cisco.com>
>> ---
>> 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.
For all other CEC implementations I have placed it under a config option. The
reason is that 1) CEC is an optional feature of HDMI and you may not actually
want it, and 2) enabling CEC also pulls in the cec module.
I still think turning this into a drm config option makes sense. This would
replace the i915 config option I made in the next patch, i.e. this config option
is moved up one level.
Your choice, though.
> 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.
Will do.
BTW, do you know if it is possible to detect when a DP-to-HDMI adapter is
connected as I discussed in my cover letter? That's my main open question
for this patch series.
Regarding the other thing I discussed in the cover letter about detecting if
the CEC pin is really hooked up: I think I shouldn't try to be smart. Yes, I
can try to poll for a TV, but that doesn't really say anything about whether
CEC is working or not since the TV itself may not have enabled CEC (actually
quite common).
One alternative might be to poll and, if no TV is detected, call dev_info to
let the user know that either there is no CEC-enabled TV, or the CEC pin isn't
connected.
I'm not sure if that helps the user or not.
Regards,
Hans
>
> Thanks, Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-26 10:34 ` Hans Verkuil
@ 2017-05-26 11:33 ` Daniel Vetter
-1 siblings, 0 replies; 46+ messages in thread
From: Daniel Vetter @ 2017-05-26 11:33 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Jani Nikula, intel-gfx, dri-devel, Hans Verkuil, linux-media
On Fri, May 26, 2017 at 12:34 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> 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.
>
> For all other CEC implementations I have placed it under a config option. The
> reason is that 1) CEC is an optional feature of HDMI and you may not actually
> want it, and 2) enabling CEC also pulls in the cec module.
>
> I still think turning this into a drm config option makes sense. This would
> replace the i915 config option I made in the next patch, i.e. this config option
> is moved up one level.
>
> Your choice, though.
If there is a CEC option already, can we just reuse that one? I.e.
when it's enabled, we compile the drm dp cec helpers, if it's not, you
get the pile of dummy functions. drm_dp_cec.c should still be part of
drm_kms_helper.ko though I think (since the dp aux stuff is in there
anyway, doesn't make sense to split it).
I'm still not sold on Kconfig proliferation for optional features
(have one for the driver, that's imo enough), but if it exists already
not going to block it's use in drm. As long as it's minimally invasive
on the code and drivers don't have to care at all.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
@ 2017-05-26 11:33 ` Daniel Vetter
0 siblings, 0 replies; 46+ messages in thread
From: Daniel Vetter @ 2017-05-26 11:33 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Jani Nikula, intel-gfx, Hans Verkuil, dri-devel, linux-media
On Fri, May 26, 2017 at 12:34 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> 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.
>
> For all other CEC implementations I have placed it under a config option. The
> reason is that 1) CEC is an optional feature of HDMI and you may not actually
> want it, and 2) enabling CEC also pulls in the cec module.
>
> I still think turning this into a drm config option makes sense. This would
> replace the i915 config option I made in the next patch, i.e. this config option
> is moved up one level.
>
> Your choice, though.
If there is a CEC option already, can we just reuse that one? I.e.
when it's enabled, we compile the drm dp cec helpers, if it's not, you
get the pile of dummy functions. drm_dp_cec.c should still be part of
drm_kms_helper.ko though I think (since the dp aux stuff is in there
anyway, doesn't make sense to split it).
I'm still not sold on Kconfig proliferation for optional features
(have one for the driver, that's imo enough), but if it exists already
not going to block it's use in drm. As long as it's minimally invasive
on the code and drivers don't have to care at all.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-26 10:20 ` Hans Verkuil
(?)
@ 2017-05-29 19:00 ` Daniel Vetter
2017-05-30 7:02 ` Hans Verkuil
-1 siblings, 1 reply; 46+ messages in thread
From: Daniel Vetter @ 2017-05-29 19:00 UTC (permalink / raw)
To: Hans Verkuil
Cc: Daniel Vetter, linux-media, dri-devel, intel-gfx, Clint Taylor,
Jani Nikula, Hans Verkuil
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
> On 05/26/2017 09:15 AM, Daniel Vetter wrote:
> > On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil <hans.verkuil@cisco.com>
> >>
> >> Implement support for this DisplayPort feature.
> >>
> >> The cec device is created whenever it detects an adapter that
> >> has this feature. It is only removed when a new adapter is connected
> >> that does not support this. If a new adapter is connected that has
> >> different properties than the previous one, then the old cec device is
> >> unregistered and a new one is registered to replace the old one.
> >>
> >> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> >
> > Some small comments below.
> >
> >> ---
> >> drivers/gpu/drm/i915/Kconfig | 11 ++++++++++
> >> drivers/gpu/drm/i915/intel_dp.c | 46 +++++++++++++++++++++++++++++++++++++----
> >> 2 files changed, 53 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> >> index a5cd5dacf055..f317b13a1409 100644
> >> --- a/drivers/gpu/drm/i915/Kconfig
> >> +++ b/drivers/gpu/drm/i915/Kconfig
> >> @@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
> >> Choose this option if you want to enable KVMGT support for
> >> Intel GVT-g.
> >>
> >> +config DRM_I915_DP_CEC
> >> + tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> >> + depends on DRM_I915 && CEC_CORE
> >> + select DRM_DP_CEC
> >> + help
> >> + Choose this option if you want to enable HDMI CEC support for
> >> + DisplayPort/USB-C to HDMI adapters.
> >> +
> >> + Note: not all adapters support this feature, and even for those
> >> + that do support this often do not hook up the CEC pin.
> >
> > Why Kconfig? There's not anything else optional in i915.ko (except debug
> > stuff ofc), since generally just not worth the pain. Also doesn't seem to
> > be wired up at all :-)
>
> It selects DRM_DP_CEC, but you're right, it can be dropped.
>
> >
> >> +
> >> menu "drm/i915 Debugging"
> >> depends on DRM_I915
> >> depends on EXPERT
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> >> index ee77b519835c..38e17ee2548d 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -32,6 +32,7 @@
> >> #include <linux/notifier.h>
> >> #include <linux/reboot.h>
> >> #include <asm/byteorder.h>
> >> +#include <media/cec.h>
> >> #include <drm/drmP.h>
> >> #include <drm/drm_atomic_helper.h>
> >> #include <drm/drm_crtc.h>
> >> @@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
> >> static void
> >> intel_dp_aux_fini(struct intel_dp *intel_dp)
> >> {
> >> + cec_unregister_adapter(intel_dp->aux.cec_adap);
> >> kfree(intel_dp->aux.name);
> >> }
> >>
> >> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> >> return -EINVAL;
> >> }
> >>
> >> +static bool
> >> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
> >> +{
> >> + bool handled = false;
> >> +
> >> + for (;;) {
> >> + u8 cec_irq;
> >> + int ret;
> >> +
> >> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
> >> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> >> + &cec_irq);
> >> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
> >> + return handled;
> >> +
> >> + cec_irq &= ~DP_CEC_IRQ;
> >> + drm_dp_cec_irq(&intel_dp->aux);
> >> + handled = true;
> >> +
> >> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> >> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> >> + cec_irq);
> >> + if (ret < 0)
> >> + return handled;
> >> + }
> >> +}
> >
> > Shouldn't the above be a helper in the cec library? Doesn't look i915
> > specific to me at least ...
>
> Good point, this can be moved to drm_dp_cec_irq().
>
> >
> >> +
> >> static void
> >> intel_dp_retrain_link(struct intel_dp *intel_dp)
> >> {
> >> @@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
> >> intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
> >> else
> >> intel_dp->has_audio = drm_detect_monitor_audio(edid);
> >> + cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
> >> }
> >>
> >> static void
> >> @@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> >>
> >> kfree(intel_connector->detect_edid);
> >> intel_connector->detect_edid = NULL;
> >> + cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
> >>
> >> intel_dp->has_audio = false;
> >> }
> >> @@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> >> intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
> >>
> >> /* Can't disconnect eDP, but you can close the lid... */
> >> - if (is_edp(intel_dp))
> >> + if (is_edp(intel_dp)) {
> >> status = edp_detect(intel_dp);
> >> - else if (intel_digital_port_connected(to_i915(dev),
> >> - dp_to_dig_port(intel_dp)))
> >> + } else if (intel_digital_port_connected(to_i915(dev),
> >> + dp_to_dig_port(intel_dp))) {
> >> status = intel_dp_detect_dpcd(intel_dp);
> >> - else
> >> + if (status == connector_status_connected)
> >> + drm_dp_cec_configure_adapter(&intel_dp->aux,
> >> + intel_dp->aux.name, dev->dev);
> >
> > 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.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-29 19:00 ` Daniel Vetter
@ 2017-05-30 7:02 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-30 7:02 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-media, dri-devel, intel-gfx, Clint Taylor, Jani Nikula,
Hans Verkuil
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 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
@ 2017-05-30 7:02 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-30 7:02 UTC (permalink / raw)
To: Daniel Vetter
Cc: Jani Nikula, intel-gfx, dri-devel, Hans Verkuil, linux-media
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 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 7:02 ` Hans Verkuil
(?)
@ 2017-05-30 7:11 ` Jani Nikula
2017-05-30 14:19 ` Clint Taylor
-1 siblings, 1 reply; 46+ messages in thread
From: Jani Nikula @ 2017-05-30 7:11 UTC (permalink / raw)
To: Hans Verkuil, Daniel Vetter
Cc: linux-media, dri-devel, intel-gfx, Clint Taylor, Hans Verkuil
On Tue, 30 May 2017, Hans Verkuil <hverkuil@xs4all.nl> 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.
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
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 7:11 ` Jani Nikula
@ 2017-05-30 14:19 ` Clint Taylor
2017-05-30 16:49 ` Hans Verkuil
0 siblings, 1 reply; 46+ messages in thread
From: Clint Taylor @ 2017-05-30 14:19 UTC (permalink / raw)
To: Jani Nikula, Hans Verkuil, Daniel Vetter
Cc: linux-media, dri-devel, intel-gfx, Hans Verkuil
On 05/30/2017 12:11 AM, Jani Nikula wrote:
> On Tue, 30 May 2017, Hans Verkuil <hverkuil@xs4all.nl> 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 14:19 ` Clint Taylor
@ 2017-05-30 16:49 ` Hans Verkuil
2017-05-30 16:54 ` Hans Verkuil
2017-05-30 20:31 ` Clint Taylor
0 siblings, 2 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-30 16:49 UTC (permalink / raw)
To: Clint Taylor, Jani Nikula, Daniel Vetter
Cc: linux-media, dri-devel, intel-gfx, Hans Verkuil
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 <hverkuil@xs4all.nl> 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.
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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 16:49 ` Hans Verkuil
@ 2017-05-30 16:54 ` Hans Verkuil
2017-05-30 20:32 ` Clint Taylor
2017-05-30 20:31 ` Clint Taylor
1 sibling, 1 reply; 46+ messages in thread
From: Hans Verkuil @ 2017-05-30 16:54 UTC (permalink / raw)
To: Clint Taylor, Jani Nikula, Daniel Vetter
Cc: intel-gfx, Hans Verkuil, dri-devel, linux-media
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 <hverkuil@xs4all.nl> 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?
Thanks,
Hans
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 16:49 ` Hans Verkuil
@ 2017-05-30 20:31 ` Clint Taylor
2017-05-30 20:31 ` Clint Taylor
1 sibling, 0 replies; 46+ messages in thread
From: Clint Taylor @ 2017-05-30 20:31 UTC (permalink / raw)
To: Hans Verkuil, Jani Nikula, Daniel Vetter
Cc: linux-media, dri-devel, intel-gfx, Hans Verkuil
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 <hverkuil@xs4all.nl> 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
00000000 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
|................|
00000010 f8 23 c4 8f 06 d8 59 7b 37 bb 1e 14 9c cb cd 88
|.#....Y{7.......|
00000020 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
Uptab USB-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
>>
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
@ 2017-05-30 20:31 ` Clint Taylor
0 siblings, 0 replies; 46+ messages in thread
From: Clint Taylor @ 2017-05-30 20:31 UTC (permalink / raw)
To: Hans Verkuil, Jani Nikula, Daniel Vetter
Cc: intel-gfx, Hans Verkuil, dri-devel, linux-media
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 <hverkuil@xs4all.nl> 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
00000000 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
|................|
00000010 f8 23 c4 8f 06 d8 59 7b 37 bb 1e 14 9c cb cd 88
|.#....Y{7.......|
00000020 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
Uptab USB-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
>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 16:54 ` Hans Verkuil
@ 2017-05-30 20:32 ` Clint Taylor
0 siblings, 0 replies; 46+ messages in thread
From: Clint Taylor @ 2017-05-30 20:32 UTC (permalink / raw)
To: Hans Verkuil, Jani Nikula, Daniel Vetter
Cc: intel-gfx, Hans Verkuil, dri-devel, linux-media
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 <hverkuil@xs4all.nl> 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 0x00000000
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.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24
little-endian (0x34325258), rotation=0 (0x00000001)
--Plane id 28: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0,
src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0
(0x00000001)
--Plane id 30: type=CUR, crtc_pos= 0x 0, crtc_size= 0x 0,
src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0
(0x00000001)
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 0x00000000
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.0000x0.0000, src_size=3840.0000x2160.0000, format=XR24
little-endian (0x34325258), rotation=0 (0x00000001)
--Plane id 35: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0,
src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0
(0x00000001)
--Plane id 37: type=CUR, crtc_pos= 0x 0, crtc_size= 0x 0,
src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0
(0x00000001)
underrun reporting: cpu=yes pch=yes
CRTC 46: pipe: C, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes
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: 600000 kHz
Max bpc: 12
modes:
id 70:"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
id 92:"1920x1080" freq 60 clock 148352 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 71:"1920x1080i" freq 60 clock 74250 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 93:"1920x1080i" freq 60 clock 74176 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 91:"1920x1080" freq 50 clock 148500 hdisp 1920 hss 2448 hse
2492 htot 2640 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 77:"1920x1080i" freq 50 clock 74250 hdisp 1920 hss 2448 hse
2492 htot 2640 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 72:"1280x720" freq 60 clock 74250 hdisp 1280 hss 1390 hse
1430 htot 1650 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 94:"1280x720" freq 60 clock 74176 hdisp 1280 hss 1390 hse
1430 htot 1650 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 78:"1280x720" freq 50 clock 74250 hdisp 1280 hss 1720 hse
1760 htot 1980 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 75:"1440x480i" freq 60 clock 27000 hdisp 1440 hss 1478 hse
1602 htot 1716 vdisp 480 vss 488 vse 494 vtot 525 type 0x40 flags 0x1a
id 88:"720x576" freq 50 clock 27000 hdisp 720 hss 732 hse 796
htot 864 vdisp 576 vss 581 vse 586 vtot 625 type 0x40 flags 0xa
id 95:"720x480" freq 60 clock 27027 hdisp 720 hss 736 hse 798
htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa
id 73:"720x480" freq 60 clock 27000 hdisp 720 hss 736 hse 798
htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa
id 97:"640x480" freq 60 clock 25200 hdisp 640 hss 656 hse 752
htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
id 76:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752
htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
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
modes:
id 79:"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
id 130:"3840x2160" freq 30 clock 297000 hdisp 3840 hss 4016 hse
4104 htot 4400 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 131:"3840x2160" freq 25 clock 297000 hdisp 3840 hss 4896 hse
4984 htot 5280 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 132:"3840x2160" freq 24 clock 297000 hdisp 3840 hss 5116 hse
5204 htot 5500 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 149:"3840x2160" freq 24 clock 296703 hdisp 3840 hss 5116 hse
5204 htot 5500 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 82:"1920x2160" freq 60 clock 297000 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 80:"2560x1440" freq 52 clock 241500 hdisp 2560 hss 2864 hse
3152 htot 3153 vdisp 1440 vss 1443 vse 1448 vtot 1481 type 0x40 flags 0x9
id 85:"2048x1152" freq 60 clock 162000 hdisp 2048 hss 2074 hse
2154 htot 2250 vdisp 1152 vss 1153 vse 1156 vtot 1200 type 0x40 flags 0x5
id 87:"1920x1200" freq 60 clock 154000 hdisp 1920 hss 1968 hse
2000 htot 2080 vdisp 1200 vss 1203 vse 1209 vtot 1235 type 0x40 flags 0x9
id 83:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 135:"1920x1080" freq 60 clock 148352 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 84:"1920x1080i" freq 60 clock 74250 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 136:"1920x1080i" freq 60 clock 74176 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 121:"1920x1080" freq 50 clock 148500 hdisp 1920 hss 2448 hse
2492 htot 2640 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 122:"1920x1080i" freq 50 clock 74250 hdisp 1920 hss 2448 hse
2492 htot 2640 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 128:"1920x1080" freq 24 clock 74250 hdisp 1920 hss 2558 hse
2602 htot 2750 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 146:"1920x1080" freq 24 clock 74176 hdisp 1920 hss 2558 hse
2602 htot 2750 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 89:"1600x1200" freq 60 clock 162000 hdisp 1600 hss 1664 hse
1856 htot 2160 vdisp 1200 vss 1201 vse 1204 vtot 1250 type 0x40 flags 0x5
id 90:"1680x1050" freq 60 clock 119000 hdisp 1680 hss 1728 hse
1760 htot 1840 vdisp 1050 vss 1053 vse 1059 vtot 1080 type 0x40 flags 0x9
id 86:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse
1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5
id 106:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse
1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5
id 96:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse
1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5
id 113:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse
1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5
id 98:"1280x720" freq 60 clock 74250 hdisp 1280 hss 1390 hse
1430 htot 1650 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 137:"1280x720" freq 60 clock 74176 hdisp 1280 hss 1390 hse
1430 htot 1650 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 123:"1280x720" freq 50 clock 74250 hdisp 1280 hss 1720 hse
1760 htot 1980 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 107:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse
1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5
id 108:"1024x768" freq 70 clock 75000 hdisp 1024 hss 1048 hse
1184 htot 1328 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa
id 109:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse
1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa
id 110:"832x624" freq 75 clock 57284 hdisp 832 hss 864 hse 928
htot 1152 vdisp 624 vss 625 vse 628 vtot 667 type 0x40 flags 0xa
id 111:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896
htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5
id 112:"800x600" freq 72 clock 50000 hdisp 800 hss 856 hse 976
htot 1040 vdisp 600 vss 637 vse 643 vtot 666 type 0x40 flags 0x5
id 99:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968
htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5
id 100:"800x600" freq 56 clock 36000 hdisp 800 hss 824 hse 896
htot 1024 vdisp 600 vss 601 vse 603 vtot 625 type 0x40 flags 0x5
id 124:"720x576" freq 50 clock 27000 hdisp 720 hss 732 hse 796
htot 864 vdisp 576 vss 581 vse 586 vtot 625 type 0x40 flags 0xa
id 142:"720x480" freq 60 clock 27027 hdisp 720 hss 736 hse 798
htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa
id 117:"720x480" freq 60 clock 27000 hdisp 720 hss 736 hse 798
htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa
id 101:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720
htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa
id 102:"640x480" freq 73 clock 31500 hdisp 640 hss 664 hse 704
htot 832 vdisp 480 vss 489 vse 492 vtot 520 type 0x40 flags 0xa
id 103:"640x480" freq 67 clock 30240 hdisp 640 hss 704 hse 768
htot 864 vdisp 480 vss 483 vse 486 vtot 525 type 0x40 flags 0xa
id 138:"640x480" freq 60 clock 25200 hdisp 640 hss 656 hse 752
htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
id 104:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752
htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
id 105:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846
htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6
connector 59: type HDMI-A-1, status: disconnected
modes:
connector 62: type DP-3, status: disconnected
DPCD rev: 0
audio support: no
DP branch device present: no
modes:
connector 66: type HDMI-A-2, status: disconnected
audio support: no
modes:
>
> Thanks,
>
> Hans
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
@ 2017-05-30 20:32 ` Clint Taylor
0 siblings, 0 replies; 46+ messages in thread
From: Clint Taylor @ 2017-05-30 20:32 UTC (permalink / raw)
To: Hans Verkuil, Jani Nikula, Daniel Vetter
Cc: intel-gfx, Hans Verkuil, dri-devel, linux-media
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 <hverkuil@xs4all.nl> 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 0x00000000
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.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24
little-endian (0x34325258), rotation=0 (0x00000001)
--Plane id 28: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0,
src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0
(0x00000001)
--Plane id 30: type=CUR, crtc_pos= 0x 0, crtc_size= 0x 0,
src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0
(0x00000001)
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 0x00000000
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.0000x0.0000, src_size=3840.0000x2160.0000, format=XR24
little-endian (0x34325258), rotation=0 (0x00000001)
--Plane id 35: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0,
src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0
(0x00000001)
--Plane id 37: type=CUR, crtc_pos= 0x 0, crtc_size= 0x 0,
src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0
(0x00000001)
underrun reporting: cpu=yes pch=yes
CRTC 46: pipe: C, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes
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: 600000 kHz
Max bpc: 12
modes:
id 70:"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
id 92:"1920x1080" freq 60 clock 148352 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 71:"1920x1080i" freq 60 clock 74250 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 93:"1920x1080i" freq 60 clock 74176 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 91:"1920x1080" freq 50 clock 148500 hdisp 1920 hss 2448 hse
2492 htot 2640 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 77:"1920x1080i" freq 50 clock 74250 hdisp 1920 hss 2448 hse
2492 htot 2640 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 72:"1280x720" freq 60 clock 74250 hdisp 1280 hss 1390 hse
1430 htot 1650 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 94:"1280x720" freq 60 clock 74176 hdisp 1280 hss 1390 hse
1430 htot 1650 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 78:"1280x720" freq 50 clock 74250 hdisp 1280 hss 1720 hse
1760 htot 1980 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 75:"1440x480i" freq 60 clock 27000 hdisp 1440 hss 1478 hse
1602 htot 1716 vdisp 480 vss 488 vse 494 vtot 525 type 0x40 flags 0x1a
id 88:"720x576" freq 50 clock 27000 hdisp 720 hss 732 hse 796
htot 864 vdisp 576 vss 581 vse 586 vtot 625 type 0x40 flags 0xa
id 95:"720x480" freq 60 clock 27027 hdisp 720 hss 736 hse 798
htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa
id 73:"720x480" freq 60 clock 27000 hdisp 720 hss 736 hse 798
htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa
id 97:"640x480" freq 60 clock 25200 hdisp 640 hss 656 hse 752
htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
id 76:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752
htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
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
modes:
id 79:"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
id 130:"3840x2160" freq 30 clock 297000 hdisp 3840 hss 4016 hse
4104 htot 4400 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 131:"3840x2160" freq 25 clock 297000 hdisp 3840 hss 4896 hse
4984 htot 5280 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 132:"3840x2160" freq 24 clock 297000 hdisp 3840 hss 5116 hse
5204 htot 5500 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 149:"3840x2160" freq 24 clock 296703 hdisp 3840 hss 5116 hse
5204 htot 5500 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 82:"1920x2160" freq 60 clock 297000 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x40 flags 0x5
id 80:"2560x1440" freq 52 clock 241500 hdisp 2560 hss 2864 hse
3152 htot 3153 vdisp 1440 vss 1443 vse 1448 vtot 1481 type 0x40 flags 0x9
id 85:"2048x1152" freq 60 clock 162000 hdisp 2048 hss 2074 hse
2154 htot 2250 vdisp 1152 vss 1153 vse 1156 vtot 1200 type 0x40 flags 0x5
id 87:"1920x1200" freq 60 clock 154000 hdisp 1920 hss 1968 hse
2000 htot 2080 vdisp 1200 vss 1203 vse 1209 vtot 1235 type 0x40 flags 0x9
id 83:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 135:"1920x1080" freq 60 clock 148352 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 84:"1920x1080i" freq 60 clock 74250 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 136:"1920x1080i" freq 60 clock 74176 hdisp 1920 hss 2008 hse
2052 htot 2200 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 121:"1920x1080" freq 50 clock 148500 hdisp 1920 hss 2448 hse
2492 htot 2640 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 122:"1920x1080i" freq 50 clock 74250 hdisp 1920 hss 2448 hse
2492 htot 2640 vdisp 1080 vss 1084 vse 1094 vtot 1125 type 0x40 flags 0x15
id 128:"1920x1080" freq 24 clock 74250 hdisp 1920 hss 2558 hse
2602 htot 2750 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 146:"1920x1080" freq 24 clock 74176 hdisp 1920 hss 2558 hse
2602 htot 2750 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x40 flags 0x5
id 89:"1600x1200" freq 60 clock 162000 hdisp 1600 hss 1664 hse
1856 htot 2160 vdisp 1200 vss 1201 vse 1204 vtot 1250 type 0x40 flags 0x5
id 90:"1680x1050" freq 60 clock 119000 hdisp 1680 hss 1728 hse
1760 htot 1840 vdisp 1050 vss 1053 vse 1059 vtot 1080 type 0x40 flags 0x9
id 86:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse
1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5
id 106:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse
1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5
id 96:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse
1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5
id 113:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse
1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5
id 98:"1280x720" freq 60 clock 74250 hdisp 1280 hss 1390 hse
1430 htot 1650 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 137:"1280x720" freq 60 clock 74176 hdisp 1280 hss 1390 hse
1430 htot 1650 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 123:"1280x720" freq 50 clock 74250 hdisp 1280 hss 1720 hse
1760 htot 1980 vdisp 720 vss 725 vse 730 vtot 750 type 0x40 flags 0x5
id 107:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse
1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5
id 108:"1024x768" freq 70 clock 75000 hdisp 1024 hss 1048 hse
1184 htot 1328 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa
id 109:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse
1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa
id 110:"832x624" freq 75 clock 57284 hdisp 832 hss 864 hse 928
htot 1152 vdisp 624 vss 625 vse 628 vtot 667 type 0x40 flags 0xa
id 111:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896
htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5
id 112:"800x600" freq 72 clock 50000 hdisp 800 hss 856 hse 976
htot 1040 vdisp 600 vss 637 vse 643 vtot 666 type 0x40 flags 0x5
id 99:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968
htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5
id 100:"800x600" freq 56 clock 36000 hdisp 800 hss 824 hse 896
htot 1024 vdisp 600 vss 601 vse 603 vtot 625 type 0x40 flags 0x5
id 124:"720x576" freq 50 clock 27000 hdisp 720 hss 732 hse 796
htot 864 vdisp 576 vss 581 vse 586 vtot 625 type 0x40 flags 0xa
id 142:"720x480" freq 60 clock 27027 hdisp 720 hss 736 hse 798
htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa
id 117:"720x480" freq 60 clock 27000 hdisp 720 hss 736 hse 798
htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa
id 101:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720
htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa
id 102:"640x480" freq 73 clock 31500 hdisp 640 hss 664 hse 704
htot 832 vdisp 480 vss 489 vse 492 vtot 520 type 0x40 flags 0xa
id 103:"640x480" freq 67 clock 30240 hdisp 640 hss 704 hse 768
htot 864 vdisp 480 vss 483 vse 486 vtot 525 type 0x40 flags 0xa
id 138:"640x480" freq 60 clock 25200 hdisp 640 hss 656 hse 752
htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
id 104:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752
htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
id 105:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846
htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6
connector 59: type HDMI-A-1, status: disconnected
modes:
connector 62: type DP-3, status: disconnected
DPCD rev: 0
audio support: no
DP branch device present: no
modes:
connector 66: type HDMI-A-2, status: disconnected
audio support: no
modes:
>
> Thanks,
>
> Hans
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 20:32 ` Clint Taylor
(?)
@ 2017-05-30 21:29 ` Hans Verkuil
2017-05-30 23:25 ` Clint Taylor
-1 siblings, 1 reply; 46+ messages in thread
From: Hans Verkuil @ 2017-05-30 21:29 UTC (permalink / raw)
To: Clint Taylor, Jani Nikula, Daniel Vetter
Cc: intel-gfx, Hans Verkuil, dri-devel, linux-media
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 <hverkuil@xs4all.nl> 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: 600000 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).
<snip>
> 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.
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: 600000 kHz
Max bpc: 16
Clearly a Megachip.
Regards,
Hans
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 21:29 ` Hans Verkuil
@ 2017-05-30 23:25 ` Clint Taylor
0 siblings, 0 replies; 46+ messages in thread
From: Clint Taylor @ 2017-05-30 23:25 UTC (permalink / raw)
To: Hans Verkuil, Jani Nikula, Daniel Vetter
Cc: intel-gfx, Hans Verkuil, dri-devel, linux-media
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 <hverkuil@xs4all.nl> 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: 600000 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.
>
> <snip>
>
>> 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: 600000 kHz
> Max bpc: 16
>
> Clearly a Megachip.
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
@ 2017-05-30 23:25 ` Clint Taylor
0 siblings, 0 replies; 46+ messages in thread
From: Clint Taylor @ 2017-05-30 23:25 UTC (permalink / raw)
To: Hans Verkuil, Jani Nikula, Daniel Vetter
Cc: intel-gfx, Hans Verkuil, dri-devel, linux-media
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 <hverkuil@xs4all.nl> 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: 600000 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.
>
> <snip>
>
>> 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: 600000 kHz
> Max bpc: 16
>
> Clearly a Megachip.
>
> Regards,
>
> Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-26 7:18 ` Daniel Vetter
(?)
(?)
@ 2017-05-30 23:57 ` Clint Taylor
2017-05-31 6:40 ` Hans Verkuil
-1 siblings, 1 reply; 46+ messages in thread
From: Clint Taylor @ 2017-05-30 23:57 UTC (permalink / raw)
To: Daniel Vetter, Hans Verkuil
Cc: linux-media, dri-devel, intel-gfx, Jani Nikula, Hans Verkuil
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 <hans.verkuil@cisco.com>
>>
>> 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 <hans.verkuil@cisco.com>
>> ---
>> 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 000000000000..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 <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <drm/drm_dp_helper.h>
>> +#include <media/cec.h>
>> +
>> +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 int retries = attempts - 1;
>> + ssize_t err;
>> +
>> + err = drm_dp_dpcd_write(aux, DP_CEC_TX_MESSAGE_BUFFER,
>> + msg->msg, msg->len);
>> + if (err < 0)
>> + return err;
>> +
>> + if (retries > 5)
>> + retries = 5;
>> + err = drm_dp_dpcd_writeb(aux, DP_CEC_TX_MESSAGE_INFO,
>> + (msg->len - 1) | (retries << 4) |
>> + DP_CEC_TX_MESSAGE_SEND);
>> + return err < 0 ? err : 0;
>> +}
>> +
>> +static int drm_dp_cec_adap_monitor_all_enable(struct cec_adapter *adap,
>> + bool enable)
>> +{
>> + struct drm_dp_aux *aux = cec_get_drvdata(adap);
>> + ssize_t err;
>> + u8 val;
>> +
>> + if (!(adap->capabilities & CEC_CAP_MONITOR_ALL))
>> + return 0;
>> +
>> + err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CONTROL, &val);
>> + if (err >= 0) {
>> + if (enable)
>> + val |= DP_CEC_SNOOPING_ENABLE;
>> + else
>> + val &= ~DP_CEC_SNOOPING_ENABLE;
>> + err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
>> + }
>> + return (enable && err < 0) ? err : 0;
>> +}
>> +
>> +static const struct cec_adap_ops drm_dp_cec_adap_ops = {
>> + .adap_enable = drm_dp_cec_adap_enable,
>> + .adap_log_addr = drm_dp_cec_adap_log_addr,
>> + .adap_transmit = drm_dp_cec_adap_transmit,
>> + .adap_monitor_all_enable = drm_dp_cec_adap_monitor_all_enable,
>> +};
>> +
>> +static int drm_dp_cec_received(struct drm_dp_aux *aux)
>> +{
>> + struct cec_adapter *adap = aux->cec_adap;
>> + struct cec_msg msg;
>> + u8 rx_msg_info;
>> + ssize_t err;
>> +
>> + err = drm_dp_dpcd_readb(aux, DP_CEC_RX_MESSAGE_INFO, &rx_msg_info);
>> + if (err < 0)
>> + return err;
>> + if (!(rx_msg_info & DP_CEC_RX_MESSAGE_ENDED))
>> + return 0;
>> + msg.len = (rx_msg_info & DP_CEC_RX_MESSAGE_LEN_MASK) + 1;
>> + err = drm_dp_dpcd_read(aux, DP_CEC_RX_MESSAGE_BUFFER, msg.msg, msg.len);
>> + if (err < 0)
>> + return err;
>> + cec_received_msg(adap, &msg);
>> + return 0;
>> +}
>> +
>> +int drm_dp_cec_irq(struct drm_dp_aux *aux)
>> +{
>> + struct cec_adapter *adap = aux->cec_adap;
>> + u8 flags;
>> + ssize_t err;
>> +
>> + if (!aux->cec_adap)
>> + return 0;
>> +
>> + err = drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, &flags);
>> + if (err < 0)
>> + return err;
>> +
>> + if (flags & DP_CEC_RX_MESSAGE_INFO_VALID)
>> + drm_dp_cec_received(aux);
>> +
>> + if (flags & DP_CEC_TX_MESSAGE_SENT)
>> + cec_transmit_done(adap, CEC_TX_STATUS_OK, 0, 0, 0, 0);
>> + else if (flags & DP_CEC_TX_LINE_ERROR)
>> + cec_transmit_done(adap, CEC_TX_STATUS_ERROR |
>> + CEC_TX_STATUS_MAX_RETRIES, 0, 0, 0, 1);
>> + else if (flags &
>> + (DP_CEC_TX_ADDRESS_NACK_ERROR | DP_CEC_TX_DATA_NACK_ERROR))
>> + cec_transmit_done(adap, CEC_TX_STATUS_NACK |
>> + CEC_TX_STATUS_MAX_RETRIES, 0, 1, 0, 0);
>> + drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_IRQ_FLAGS, flags);
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(drm_dp_cec_irq);
>> +
>> +int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
>> + struct device *parent)
>> +{
>> + u32 cec_caps = CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
>> + CEC_CAP_PASSTHROUGH | CEC_CAP_RC | CEC_CAP_NEEDS_HPD;
>> + unsigned int num_las = 1;
>> + int err;
>> + u8 cap;
>> +
>> + if (drm_dp_dpcd_readb(aux, DP_CEC_TUNNELING_CAPABILITY, &cap) != 1 ||
>> + !(cap & DP_CEC_TUNNELING_CAPABLE)) {
>> + cec_unregister_adapter(aux->cec_adap);
>> + aux->cec_adap = NULL;
>> + return -ENODEV;
>> + }
>> +
>> + if (cap & DP_CEC_SNOOPING_CAPABLE)
>> + cec_caps |= CEC_CAP_MONITOR_ALL;
>> + if (cap & DP_CEC_MULTIPLE_LA_CAPABLE)
>> + num_las = CEC_MAX_LOG_ADDRS;
>> +
>> + if (!IS_ERR_OR_NULL(aux->cec_adap)) {
>> + if (aux->cec_adap->capabilities == cec_caps &&
>> + aux->cec_adap->available_log_addrs == num_las)
>> + return 0;
>> + cec_unregister_adapter(aux->cec_adap);
>> + }
>> +
>> + aux->cec_adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
>> + aux, name, cec_caps, num_las);
>> + if (IS_ERR(aux->cec_adap)) {
>> + err = PTR_ERR(aux->cec_adap);
>> + aux->cec_adap = NULL;
>> + return err;
>> + }
>> + err = cec_register_adapter(aux->cec_adap, parent);
>> + if (err) {
>> + cec_delete_adapter(aux->cec_adap);
>> + aux->cec_adap = NULL;
>> + }
>> + return err;
>> +}
>> +EXPORT_SYMBOL(drm_dp_cec_configure_adapter);
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index 3f4ad709534e..1e373df48108 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -843,6 +843,8 @@ struct drm_dp_aux_msg {
>> size_t size;
>> };
>>
>> +struct cec_adapter;
>> +
>> /**
>> * struct drm_dp_aux - DisplayPort AUX channel
>> * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
>> @@ -901,6 +903,10 @@ struct drm_dp_aux {
>> * @i2c_defer_count: Counts I2C DEFERs, used for DP validation.
>> */
>> unsigned i2c_defer_count;
>> + /**
>> + * @cec_adap: the CEC adapter for CEC-Tunneling-over-AUX support.
>> + */
>> + struct cec_adapter *cec_adap;
>> };
>>
>> ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
>> @@ -972,4 +978,22 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
>> int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
>> int drm_dp_stop_crc(struct drm_dp_aux *aux);
>>
>> +#ifdef CONFIG_DRM_DP_CEC
>> +int drm_dp_cec_irq(struct drm_dp_aux *aux);
>> +int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char *name,
>> + struct device *parent);
>> +#else
>> +static inline int drm_dp_cec_irq(struct drm_dp_aux *aux)
>> +{
>> + return 0;
>> +}
>> +
>> +static inline int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux,
>> + const char *name,
>> + struct device *parent)
>> +{
>> + return -ENODEV;
>> +}
>> +#endif
>> +
>> #endif /* _DRM_DP_HELPER_H_ */
>> --
>> 2.11.0
>>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
2017-05-30 23:25 ` Clint Taylor
(?)
@ 2017-05-31 6:37 ` Hans Verkuil
-1 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-31 6:37 UTC (permalink / raw)
To: Clint Taylor, Jani Nikula, Daniel Vetter
Cc: intel-gfx, Hans Verkuil, dri-devel, linux-media
On 05/31/2017 01:25 AM, Clint Taylor wrote:
>
>
> 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 <hverkuil@xs4all.nl> 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: 600000 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.
>>
>> <snip>
>>
>>> 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.
OK, in other words the Parade chipsets work and the Megachip chipsets
don't. And Intel in their wisdom decided to go with Megachip for the new
NUCs.
I have no idea if you have any ins with the NUC team, but it would be so
nice if there would be a Megachip firmware update enabling this feature.
Regards,
Hans
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
2017-05-30 23:57 ` Clint Taylor
@ 2017-05-31 6:40 ` Hans Verkuil
0 siblings, 0 replies; 46+ messages in thread
From: Hans Verkuil @ 2017-05-31 6:40 UTC (permalink / raw)
To: Clint Taylor, Daniel Vetter
Cc: Jani Nikula, intel-gfx, Hans Verkuil, dri-devel, linux-media
On 05/31/2017 01:57 AM, Clint Taylor wrote:
>
>
> 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 <hans.verkuil@cisco.com>
>>>
>>> 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 <hans.verkuil@cisco.com>
>>> ---
>>> 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.
This has changed in the next version. I realized the same thing and there
are CEC core patches pending for 4.12 to solve this.
I plan on posting a new patch series for this later this week, and that
will include those patches for 4.12 so it is easier to test this.
Regards,
Hans
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2017-05-31 6:40 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-25 15:06 [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 1/7] cec: add CEC_CAP_NEEDS_HPD Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 3/7] cec: add cec_s_phys_addr_from_edid helper function Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 4/7] cec: add cec_phys_addr_invalidate() " Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions Hans Verkuil
2017-05-25 15:06 ` Hans Verkuil
2017-05-26 8:39 ` Jani Nikula
2017-05-26 8:39 ` Jani Nikula
2017-05-25 15:06 ` [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
2017-05-25 15:06 ` Hans Verkuil
2017-05-26 7:18 ` Daniel Vetter
2017-05-26 7:18 ` Daniel Vetter
2017-05-26 10:34 ` Hans Verkuil
2017-05-26 10:34 ` Hans Verkuil
2017-05-26 11:33 ` Daniel Vetter
2017-05-26 11:33 ` Daniel Vetter
2017-05-30 23:57 ` Clint Taylor
2017-05-31 6:40 ` Hans Verkuil
2017-05-25 15:06 ` [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support Hans Verkuil
2017-05-25 15:06 ` Hans Verkuil
2017-05-26 7:15 ` Daniel Vetter
2017-05-26 10:20 ` Hans Verkuil
2017-05-26 10:20 ` Hans Verkuil
2017-05-29 19:00 ` Daniel Vetter
2017-05-30 7:02 ` Hans Verkuil
2017-05-30 7:02 ` Hans Verkuil
2017-05-30 7:11 ` Jani Nikula
2017-05-30 14:19 ` Clint Taylor
2017-05-30 16:49 ` Hans Verkuil
2017-05-30 16:54 ` Hans Verkuil
2017-05-30 20:32 ` Clint Taylor
2017-05-30 20:32 ` Clint Taylor
2017-05-30 21:29 ` Hans Verkuil
2017-05-30 23:25 ` Clint Taylor
2017-05-30 23:25 ` Clint Taylor
2017-05-31 6:37 ` Hans Verkuil
2017-05-30 20:31 ` Clint Taylor
2017-05-30 20:31 ` Clint Taylor
2017-05-26 10:13 ` Jani Nikula
2017-05-26 10:13 ` Jani Nikula
2017-05-26 10:13 ` Hans Verkuil
2017-05-26 10:13 ` Hans Verkuil
2017-05-25 15:30 ` [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX Mike Lothian
2017-05-25 15:56 ` Hans Verkuil
2017-05-25 15:34 ` ✓ Fi.CI.BAT: success for " Patchwork
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.