Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 11/06/18 14:20, Hans Verkuil wrote: > Hi Ville, > > I finally found some time to dig deeper into when a CEC device should be > registered. > > Since it's been a long while since we discussed this let me just recap the > situation > and then propose three solutions: > CEC is implemented for DP-to-HDMI branch devices through DPCD CEC registers. > When > HPD is high we can read these registers and check if CEC is supported or not. > > If an external USB-C/DP/mini-DP to HDMI adapter is used, then when the HPD > goes low > you lose access to the DPCD registers since that is (I think) powered by the > HPD. > > If an integrated branch device is used (such as for the HDMI connector on the > NUC) > the DPCD registers will remain available even if the display is disconnected. > > The problem is with external adapters since if the HPD goes low you do not > know > if the adapter has been disconnected, or if the display just pulled the HPD > low for a > short time (updating the EDID, HDCP changes). In the latter case you do not > want to > unregister and reregister the cec device. > > I see three options: > > 1) register a cec device when a connector is registered and keep it for the > life time > of the connector. If HPD goes low, or the branch device doesn't support CEC, > then just > set the physical address of the CEC adapter to f.f.f.f. > > This is simple, but the disadvantage is that there is a CEC device around, > even if the > branch device doesn't support CEC. > > 2) register a cec device when HPD goes high and if a branch device that > supports CEC is > detected. Unregister the cec device when the HPD goes low and stays low for > more than > a second. This prevents a cec device from disappearing whenever the display > toggles > the HPD. It does require a delayed workqueue to handle this delay. > > It would be nice if there is a way to avoid a delayed workqueue, but I didn't > see > anything in the i915 code. > > 3) A hybrid option where the cec device is only registered when a CEC capable > branch > device is detected, but then we keep it for the remaining lifetime of the > connector. > This avoids the delayed workqueue, and avoids creating cec devices if the > branch > device doesn't support CEC. But once it is created it won't be removed until > the > connector is also unregistered. > > I'm leaning towards the second or third option. > > Opinions? Other ideas? A quick update: I've been working on a next version of this patch series that combines options 2 and 3 and moves the logic out of the i915 driver into the core drm CEC code since all DP drivers will have the same problem. I hope to post the new series later today. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
Hi Ville, I finally found some time to dig deeper into when a CEC device should be registered. Since it's been a long while since we discussed this let me just recap the situation and then propose three solutions: CEC is implemented for DP-to-HDMI branch devices through DPCD CEC registers. When HPD is high we can read these registers and check if CEC is supported or not. If an external USB-C/DP/mini-DP to HDMI adapter is used, then when the HPD goes low you lose access to the DPCD registers since that is (I think) powered by the HPD. If an integrated branch device is used (such as for the HDMI connector on the NUC) the DPCD registers will remain available even if the display is disconnected. The problem is with external adapters since if the HPD goes low you do not know if the adapter has been disconnected, or if the display just pulled the HPD low for a short time (updating the EDID, HDCP changes). In the latter case you do not want to unregister and reregister the cec device. I see three options: 1) register a cec device when a connector is registered and keep it for the life time of the connector. If HPD goes low, or the branch device doesn't support CEC, then just set the physical address of the CEC adapter to f.f.f.f. This is simple, but the disadvantage is that there is a CEC device around, even if the branch device doesn't support CEC. 2) register a cec device when HPD goes high and if a branch device that supports CEC is detected. Unregister the cec device when the HPD goes low and stays low for more than a second. This prevents a cec device from disappearing whenever the display toggles the HPD. It does require a delayed workqueue to handle this delay. It would be nice if there is a way to avoid a delayed workqueue, but I didn't see anything in the i915 code. 3) A hybrid option where the cec device is only registered when a CEC capable branch device is detected, but then we keep it for the remaining lifetime of the connector. This avoids the delayed workqueue, and avoids creating cec devices if the branch device doesn't support CEC. But once it is created it won't be removed until the connector is also unregistered. I'm leaning towards the second or third option. Opinions? Other ideas? Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
Hi Ville, On 12/01/18 20:08, Hans Verkuil wrote: > On 01/12/2018 07:12 PM, Hans Verkuil wrote: >> On 01/12/2018 06:52 PM, Ville Syrjälä wrote: >>> On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote: On 01/12/2018 05:30 PM, Ville Syrjälä wrote: > On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: >> Hi Ville, >> >> For some strange reason your email disappeared from the Cc list. Perhaps >> it's the >> ä that confuses something somewhere. >> >> So I'll just forward this directly to you. >> >> Can you please take a look? This patch series has been in limbo for too >> long. > > IIRC last I looked we still had some ragistration race to deal with. > Was that fixed? That was fixed in v5. > > Also I think we got stuck on leaving the zombie device lingering around > when the display is disconnected. I couldn't understand why that is > at all useful since you anyway remove the device eventually. It's not a zombie device. If you disconnect and reconnect the display then the application using the CEC device will see the display disappear and reappear as expected. It helps if you think of the normal situation (as is present in most ARM SoCs) where CEC is integral to the HDMI transmitter. I.e. it is not functionality that can be removed. So the cec device is always there and an application opens the device and can use it, regardless of whether a display is connected or not. If a display is detected, the EDID will be read and the CEC physical address is set. The application is informed of that through an event and the CEC adapter can be used. If the HPD disappears the physical address is reset to f.f.f.f and again the application is informed. And in fact it still has to be able to use the CEC adapter even if there is no HPD since some displays turn off the HPD when in standby, but CEC can still be used to power them up again. >>> >>> Hmm. So you're saying there are DP devices out there that release HPD >>> but still respond to DPCD accesses? That sounds... wrong. >> >> Not quite. To be precise: there are HDMI displays that release HPD when in >> standby >> but still respond to CEC commands. >> >> Such displays are still being made today so if you are building a product >> like >> a media streaming box, then this is something to take into account. >> >> However, for this specific case (CEC tunneling) it is a non-issue since the >> DP CEC protocol simply doesn't support sending CEC commands without HPD. >> >>> In general I don't think we can assume that a device has retained its >>> state if it has deasserted HPD, thus we have to reconfigure everything >>> again anyway. >>> Now consider a future Intel NUC with an HDMI connector on the backplane and working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the CEC support is always there (it's built in), but only becomes visible to the kernel when you connect a display. You don't want the cec device to disappear whenever you unplug the display, that makes no sense. Applications would loose the CEC configuration and have to close and reopen (when it reappears) the cec device for no good reason since it is built in. >>> >>> If the application can't remember its settings across a disconnect it >>> sounds broken anwyay. This would anyway happen when you disconenct the >>> entire dongle. >> >> Huh? >> >>> The same situation is valid when using a USB-C to HDMI adapter: disconnecting or reconnecting a display should not lead to the removal of the CEC device. Only when an adapter with different CEC capabilities is detected is there a need to actually unregister the CEC device. All this is really a workaround of the fact that when the HPD disappears the DP-to-HDMI adapter (either external or built-in) also disappears from the topology, even though it is physically still there. >>> >>> The dongles I've seen do not disappear. The downstream hpd is >>> signalled with short hpd pulses + SINK_COUNT instead. >>> >>> But I've not actually seen a dongle that implements the >>> BRANCH_DEVICE_CTRL DPCD register, so not quite sure what those would >>> actually do. The spec does say they should default to using long >>> hpd for downstream hpd handling. >> >> I did a few more experiments and it appears that someone somewhere keeps >> track of DP branch devices. I.e. after disconnecting my usb-c to hdmi adapter >> it still appears in i915_display_info. At least until something else is >> connected. I basically need to hook into the DP branch detection. >> >> Something to look at this weekend. > > I found a better place to do the CEC (un)registration: a long HPD pulse > indicates that the DPCD registers have c
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 01/12/2018 07:12 PM, Hans Verkuil wrote: > On 01/12/2018 06:52 PM, Ville Syrjälä wrote: >> On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote: >>> On 01/12/2018 05:30 PM, Ville Syrjälä wrote: On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: > Hi Ville, > > For some strange reason your email disappeared from the Cc list. Perhaps > it's the > ä that confuses something somewhere. > > So I'll just forward this directly to you. > > Can you please take a look? This patch series has been in limbo for too > long. IIRC last I looked we still had some ragistration race to deal with. Was that fixed? >>> >>> That was fixed in v5. >>> Also I think we got stuck on leaving the zombie device lingering around when the display is disconnected. I couldn't understand why that is at all useful since you anyway remove the device eventually. >>> >>> It's not a zombie device. If you disconnect and reconnect the display then >>> the >>> application using the CEC device will see the display disappear and reappear >>> as expected. >>> >>> It helps if you think of the normal situation (as is present in most ARM >>> SoCs) >>> where CEC is integral to the HDMI transmitter. I.e. it is not functionality >>> that >>> can be removed. So the cec device is always there and an application opens >>> the >>> device and can use it, regardless of whether a display is connected or not. >>> >>> If a display is detected, the EDID will be read and the CEC physical >>> address is >>> set. The application is informed of that through an event and the CEC >>> adapter >>> can be used. If the HPD disappears the physical address is reset to f.f.f.f >>> and >>> again the application is informed. And in fact it still has to be able to >>> use >>> the CEC adapter even if there is no HPD since some displays turn off the >>> HPD when >>> in standby, but CEC can still be used to power them up again. >> >> Hmm. So you're saying there are DP devices out there that release HPD >> but still respond to DPCD accesses? That sounds... wrong. > > Not quite. To be precise: there are HDMI displays that release HPD when in > standby > but still respond to CEC commands. > > Such displays are still being made today so if you are building a product like > a media streaming box, then this is something to take into account. > > However, for this specific case (CEC tunneling) it is a non-issue since the > DP CEC protocol simply doesn't support sending CEC commands without HPD. > >> In general I don't think we can assume that a device has retained its >> state if it has deasserted HPD, thus we have to reconfigure everything >> again anyway. >> >>> >>> Now consider a future Intel NUC with an HDMI connector on the backplane and >>> working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the >>> CEC support is always there (it's built in), but only becomes visible to the >>> kernel when you connect a display. You don't want the cec device to >>> disappear >>> whenever you unplug the display, that makes no sense. Applications would >>> loose the CEC configuration and have to close and reopen (when it reappears) >>> the cec device for no good reason since it is built in. >> >> If the application can't remember its settings across a disconnect it >> sounds broken anwyay. This would anyway happen when you disconenct the >> entire dongle. > > Huh? > >> >>> >>> The same situation is valid when using a USB-C to HDMI adapter: >>> disconnecting >>> or reconnecting a display should not lead to the removal of the CEC device. >>> Only when an adapter with different CEC capabilities is detected is there a >>> need to actually unregister the CEC device. >>> >>> All this is really a workaround of the fact that when the HPD disappears the >>> DP-to-HDMI adapter (either external or built-in) also disappears from the >>> topology, even though it is physically still there. >> >> The dongles I've seen do not disappear. The downstream hpd is >> signalled with short hpd pulses + SINK_COUNT instead. >> >> But I've not actually seen a dongle that implements the >> BRANCH_DEVICE_CTRL DPCD register, so not quite sure what those would >> actually do. The spec does say they should default to using long >> hpd for downstream hpd handling. > > I did a few more experiments and it appears that someone somewhere keeps > track of DP branch devices. I.e. after disconnecting my usb-c to hdmi adapter > it still appears in i915_display_info. At least until something else is > connected. I basically need to hook into the DP branch detection. > > Something to look at this weekend. I found a better place to do the CEC (un)registration: a long HPD pulse indicates that the DPCD registers have changed, so that's when I should detect whether there is a new branch device with CEC capabilities. Regards, Hans ___ dri-devel mailing list
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 01/12/2018 06:52 PM, Ville Syrjälä wrote: > On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote: >> On 01/12/2018 05:30 PM, Ville Syrjälä wrote: >>> On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: Hi Ville, For some strange reason your email disappeared from the Cc list. Perhaps it's the ä that confuses something somewhere. So I'll just forward this directly to you. Can you please take a look? This patch series has been in limbo for too long. >>> >>> IIRC last I looked we still had some ragistration race to deal with. >>> Was that fixed? >> >> That was fixed in v5. >> >>> >>> Also I think we got stuck on leaving the zombie device lingering around >>> when the display is disconnected. I couldn't understand why that is >>> at all useful since you anyway remove the device eventually. >> >> It's not a zombie device. If you disconnect and reconnect the display then >> the >> application using the CEC device will see the display disappear and reappear >> as expected. >> >> It helps if you think of the normal situation (as is present in most ARM >> SoCs) >> where CEC is integral to the HDMI transmitter. I.e. it is not functionality >> that >> can be removed. So the cec device is always there and an application opens >> the >> device and can use it, regardless of whether a display is connected or not. >> >> If a display is detected, the EDID will be read and the CEC physical address >> is >> set. The application is informed of that through an event and the CEC adapter >> can be used. If the HPD disappears the physical address is reset to f.f.f.f >> and >> again the application is informed. And in fact it still has to be able to use >> the CEC adapter even if there is no HPD since some displays turn off the HPD >> when >> in standby, but CEC can still be used to power them up again. > > Hmm. So you're saying there are DP devices out there that release HPD > but still respond to DPCD accesses? That sounds... wrong. Not quite. To be precise: there are HDMI displays that release HPD when in standby but still respond to CEC commands. Such displays are still being made today so if you are building a product like a media streaming box, then this is something to take into account. However, for this specific case (CEC tunneling) it is a non-issue since the DP CEC protocol simply doesn't support sending CEC commands without HPD. > In general I don't think we can assume that a device has retained its > state if it has deasserted HPD, thus we have to reconfigure everything > again anyway. > >> >> Now consider a future Intel NUC with an HDMI connector on the backplane and >> working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the >> CEC support is always there (it's built in), but only becomes visible to the >> kernel when you connect a display. You don't want the cec device to disappear >> whenever you unplug the display, that makes no sense. Applications would >> loose the CEC configuration and have to close and reopen (when it reappears) >> the cec device for no good reason since it is built in. > > If the application can't remember its settings across a disconnect it > sounds broken anwyay. This would anyway happen when you disconenct the > entire dongle. Huh? > >> >> The same situation is valid when using a USB-C to HDMI adapter: disconnecting >> or reconnecting a display should not lead to the removal of the CEC device. >> Only when an adapter with different CEC capabilities is detected is there a >> need to actually unregister the CEC device. >> >> All this is really a workaround of the fact that when the HPD disappears the >> DP-to-HDMI adapter (either external or built-in) also disappears from the >> topology, even though it is physically still there. > > The dongles I've seen do not disappear. The downstream hpd is > signalled with short hpd pulses + SINK_COUNT instead. > > But I've not actually seen a dongle that implements the > BRANCH_DEVICE_CTRL DPCD register, so not quite sure what those would > actually do. The spec does say they should default to using long > hpd for downstream hpd handling. I did a few more experiments and it appears that someone somewhere keeps track of DP branch devices. I.e. after disconnecting my usb-c to hdmi adapter it still appears in i915_display_info. At least until something else is connected. I basically need to hook into the DP branch detection. Something to look at this weekend. Regards, Hans > >> If there was a way to >> detect the adapter when there is no display connected, then this workaround >> wouldn't be needed. >> >> This situation is specific to DisplayPort, this is the only case where the >> HDMI connector disappears in a puff of smoke when you disconnect the HDMI >> cable, even though the actual physical connector is obviously still there. >> >> Regards, >> >> Hans >> >>> >>> Adding the lists back to cc so I don't have to repeat myse
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote: > On 01/12/2018 05:30 PM, Ville Syrjälä wrote: > > On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: > >> Hi Ville, > >> > >> For some strange reason your email disappeared from the Cc list. Perhaps > >> it's the > >> ä that confuses something somewhere. > >> > >> So I'll just forward this directly to you. > >> > >> Can you please take a look? This patch series has been in limbo for too > >> long. > > > > IIRC last I looked we still had some ragistration race to deal with. > > Was that fixed? > > That was fixed in v5. > > > > > Also I think we got stuck on leaving the zombie device lingering around > > when the display is disconnected. I couldn't understand why that is > > at all useful since you anyway remove the device eventually. > > It's not a zombie device. If you disconnect and reconnect the display then the > application using the CEC device will see the display disappear and reappear > as expected. > > It helps if you think of the normal situation (as is present in most ARM SoCs) > where CEC is integral to the HDMI transmitter. I.e. it is not functionality > that > can be removed. So the cec device is always there and an application opens the > device and can use it, regardless of whether a display is connected or not. > > If a display is detected, the EDID will be read and the CEC physical address > is > set. The application is informed of that through an event and the CEC adapter > can be used. If the HPD disappears the physical address is reset to f.f.f.f > and > again the application is informed. And in fact it still has to be able to use > the CEC adapter even if there is no HPD since some displays turn off the HPD > when > in standby, but CEC can still be used to power them up again. Hmm. So you're saying there are DP devices out there that release HPD but still respond to DPCD accesses? That sounds... wrong. In general I don't think we can assume that a device has retained its state if it has deasserted HPD, thus we have to reconfigure everything again anyway. > > Now consider a future Intel NUC with an HDMI connector on the backplane and > working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the > CEC support is always there (it's built in), but only becomes visible to the > kernel when you connect a display. You don't want the cec device to disappear > whenever you unplug the display, that makes no sense. Applications would > loose the CEC configuration and have to close and reopen (when it reappears) > the cec device for no good reason since it is built in. If the application can't remember its settings across a disconnect it sounds broken anwyay. This would anyway happen when you disconenct the entire dongle. > > The same situation is valid when using a USB-C to HDMI adapter: disconnecting > or reconnecting a display should not lead to the removal of the CEC device. > Only when an adapter with different CEC capabilities is detected is there a > need to actually unregister the CEC device. > > All this is really a workaround of the fact that when the HPD disappears the > DP-to-HDMI adapter (either external or built-in) also disappears from the > topology, even though it is physically still there. The dongles I've seen do not disappear. The downstream hpd is signalled with short hpd pulses + SINK_COUNT instead. But I've not actually seen a dongle that implements the BRANCH_DEVICE_CTRL DPCD register, so not quite sure what those would actually do. The spec does say they should default to using long hpd for downstream hpd handling. > If there was a way to > detect the adapter when there is no display connected, then this workaround > wouldn't be needed. > > This situation is specific to DisplayPort, this is the only case where the > HDMI connector disappears in a puff of smoke when you disconnect the HDMI > cable, even though the actual physical connector is obviously still there. > > Regards, > > Hans > > > > > Adding the lists back to cc so I don't have to repeat myself there... > > > >> > >> Regards, > >> > >>Hans > >> > >> > >> Forwarded Message > >> Subject: Re: [PATCHv5 0/3] drm/i915: add DisplayPort > >> CEC-Tunneling-over-AUX support > >> Date: Tue, 9 Jan 2018 13:46:44 +0100 > >> From: Hans Verkuil > >> To: linux-me...@vger.kernel.org > >> CC: Daniel Vetter , Carlos Santa > >> , dri-devel@lists.freedesktop.org > >> > >> First of all a Happy New Year for all of you! > >> > >> And secondly: can this v5 patch series be reviewed/merged? It's been > >> waiting > >> for that for a very long time now... > >> > >> Regards, > >> > >>Hans > >> > >> On 12/11/17 09:57, Hans Verkuil wrote: > >>> Ping again. Added a CC to Ville whom I inexplicably forgot to add when > >>> I sent the v5 patch series. > >>> > >>> Regards, > >>> > >>> Hans > >>> > >>> On 01/12/17 08:23, Hans Verkuil wrote: > Ping! > > I really like to get this
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 01/12/2018 05:30 PM, Ville Syrjälä wrote: > On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: >> Hi Ville, >> >> For some strange reason your email disappeared from the Cc list. Perhaps >> it's the >> ä that confuses something somewhere. >> >> So I'll just forward this directly to you. >> >> Can you please take a look? This patch series has been in limbo for too long. > > IIRC last I looked we still had some ragistration race to deal with. > Was that fixed? That was fixed in v5. > > Also I think we got stuck on leaving the zombie device lingering around > when the display is disconnected. I couldn't understand why that is > at all useful since you anyway remove the device eventually. It's not a zombie device. If you disconnect and reconnect the display then the application using the CEC device will see the display disappear and reappear as expected. It helps if you think of the normal situation (as is present in most ARM SoCs) where CEC is integral to the HDMI transmitter. I.e. it is not functionality that can be removed. So the cec device is always there and an application opens the device and can use it, regardless of whether a display is connected or not. If a display is detected, the EDID will be read and the CEC physical address is set. The application is informed of that through an event and the CEC adapter can be used. If the HPD disappears the physical address is reset to f.f.f.f and again the application is informed. And in fact it still has to be able to use the CEC adapter even if there is no HPD since some displays turn off the HPD when in standby, but CEC can still be used to power them up again. Now consider a future Intel NUC with an HDMI connector on the backplane and working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the CEC support is always there (it's built in), but only becomes visible to the kernel when you connect a display. You don't want the cec device to disappear whenever you unplug the display, that makes no sense. Applications would loose the CEC configuration and have to close and reopen (when it reappears) the cec device for no good reason since it is built in. The same situation is valid when using a USB-C to HDMI adapter: disconnecting or reconnecting a display should not lead to the removal of the CEC device. Only when an adapter with different CEC capabilities is detected is there a need to actually unregister the CEC device. All this is really a workaround of the fact that when the HPD disappears the DP-to-HDMI adapter (either external or built-in) also disappears from the topology, even though it is physically still there. If there was a way to detect the adapter when there is no display connected, then this workaround wouldn't be needed. This situation is specific to DisplayPort, this is the only case where the HDMI connector disappears in a puff of smoke when you disconnect the HDMI cable, even though the actual physical connector is obviously still there. Regards, Hans > > Adding the lists back to cc so I don't have to repeat myself there... > >> >> Regards, >> >> Hans >> >> >> Forwarded Message >> Subject: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX >> support >> Date: Tue, 9 Jan 2018 13:46:44 +0100 >> From: Hans Verkuil >> To: linux-me...@vger.kernel.org >> CC: Daniel Vetter , Carlos Santa >> , dri-devel@lists.freedesktop.org >> >> First of all a Happy New Year for all of you! >> >> And secondly: can this v5 patch series be reviewed/merged? It's been waiting >> for that for a very long time now... >> >> Regards, >> >> Hans >> >> On 12/11/17 09:57, Hans Verkuil wrote: >>> Ping again. Added a CC to Ville whom I inexplicably forgot to add when >>> I sent the v5 patch series. >>> >>> Regards, >>> >>> Hans >>> >>> On 01/12/17 08:23, Hans Verkuil wrote: Ping! I really like to get this in for 4.16 so I can move forward with hooking this up for nouveau/amd. Regards, Hans On 11/20/2017 12:42 PM, Hans Verkuil wrote: > This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX > feature. This patch series is based on the 4.14 mainline release but > applies > as well to drm-next. > > This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to > HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI > adapter (where the CEC pin is wired up). > > Please note this comment at the start of drm_dp_cec.c: > > -- > Unfortunately it turns out that we have a chicken-and-egg situation > here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters > have a converter chip that supports CEC-Tunneling-over-AUX (usually the > Parade PS176 or MegaChips MCDP2900), but they do not wire up the CEC pin, > thus making CEC useless. > >
Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: > Hi Ville, > > For some strange reason your email disappeared from the Cc list. Perhaps it's > the > ä that confuses something somewhere. > > So I'll just forward this directly to you. > > Can you please take a look? This patch series has been in limbo for too long. IIRC last I looked we still had some ragistration race to deal with. Was that fixed? Also I think we got stuck on leaving the zombie device lingering around when the display is disconnected. I couldn't understand why that is at all useful since you anyway remove the device eventually. Adding the lists back to cc so I don't have to repeat myself there... > > Regards, > > Hans > > > Forwarded Message > Subject: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX > support > Date: Tue, 9 Jan 2018 13:46:44 +0100 > From: Hans Verkuil > To: linux-me...@vger.kernel.org > CC: Daniel Vetter , Carlos Santa > , dri-devel@lists.freedesktop.org > > First of all a Happy New Year for all of you! > > And secondly: can this v5 patch series be reviewed/merged? It's been waiting > for that for a very long time now... > > Regards, > > Hans > > On 12/11/17 09:57, Hans Verkuil wrote: > > Ping again. Added a CC to Ville whom I inexplicably forgot to add when > > I sent the v5 patch series. > > > > Regards, > > > > Hans > > > > On 01/12/17 08:23, Hans Verkuil wrote: > >> Ping! > >> > >> I really like to get this in for 4.16 so I can move forward with hooking > >> this up for nouveau/amd. > >> > >> Regards, > >> > >>Hans > >> > >> On 11/20/2017 12:42 PM, Hans Verkuil wrote: > >>> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX > >>> feature. This patch series is based on the 4.14 mainline release but > >>> applies > >>> as well to drm-next. > >>> > >>> This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to > >>> HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI > >>> adapter (where the CEC pin is wired up). > >>> > >>> Please note this comment at the start of drm_dp_cec.c: > >>> > >>> -- > >>> Unfortunately it turns out that we have a chicken-and-egg situation > >>> here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters > >>> have a converter chip that supports CEC-Tunneling-over-AUX (usually the > >>> Parade PS176 or MegaChips MCDP2900), but they do not wire up the CEC pin, > >>> thus making CEC useless. > >>> > >>> Sadly there is no way for this driver to know this. What happens is > >>> that a /dev/cecX device is created that is isolated and unable to see > >>> any of the other CEC devices. Quite literally the CEC wire is cut > >>> (or in this case, never connected in the first place). > >>> > >>> I suspect that the reason so few adapters support this is that this > >>> tunneling protocol was never supported by any OS. So there was no > >>> easy way of testing it, and no incentive to correctly wire up the > >>> CEC pin. > >>> > >>> Hopefully by creating this driver it will be easier for vendors to > >>> finally fix their adapters and test the CEC functionality. > >>> > >>> I keep a list of known working adapters here: > >>> > >>> https://hverkuil.home.xs4all.nl/cec-status.txt > >>> > >>> Please mail me (hverk...@xs4all.nl) if you find an adapter that works > >>> and is not yet listed there. > >>> > >>> Note that the current implementation does not support CEC over an MST hub. > >>> As far as I can see there is no mechanism defined in the DisplayPort > >>> standard to transport CEC interrupts over an MST device. It might be > >>> possible to do this through polling, but I have not been able to get that > >>> to work. > >>> -- > >>> > >>> I really hope that this work will provide an incentive for vendors to > >>> finally connect the CEC pin. It's a shame that there are so few adapters > >>> that work (I found only two USB-C to HDMI adapters that work, and no > >>> (mini-)DP to HDMI adapters at all). > >>> > >>> Hopefully if this gets merged there will be an incentive for vendors > >>> to make adapters where this actually works. It is a very nice feature > >>> for HTPC boxes. > >>> > >>> The main reason why this v5 is delayed by 2 months is due to the fact > >>> that I needed some dedicated time to investigate what happens when an > >>> MST hub is in use. It turns out that this is not working. There is no > >>> mechanism defined in the DisplayPort standard to transport the CEC > >>> interrupt back up the MST chain. I was actually able to send a CEC > >>> message but the interrupt that tells when the transmit finished is > >>> unavailable. > >>> > >>> I attempted to implement this via polling, but I got weird errors > >>> and was not able to read the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 > >>> register. I decided to give
