| Message ID | 20170525150626.29748-8-hverkuil@xs4all.nl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 >
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.
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
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 >> >
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
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
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
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
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 >
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
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 >> >
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
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
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
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
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) { /*