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 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 <hverkuil@xxxxxxxxx> >>>> To: linux-media@xxxxxxxxxxxxxxx >>>> CC: Daniel Vetter <daniel.vetter@xxxxxxxx>, Carlos Santa <carlos.santa@xxxxxxxxx>, dri-devel@xxxxxxxxxxxxxxxxxxxxx >>>> >>>> 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 (hverkuil@xxxxxxxxx) 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 up on this for now and just disable CEC >>>>>>> for DP-to-HDMI adapters after an MST hub. I plan to revisit this >>>>>>> later since it would be neat to make this work as well. Although it >>>>>>> might not be possible at all. >>>>>>> >>>>>>> If anyone is interested, work-in-progress for this is here: >>>>>>> >>>>>>> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dp-cec-mst >>>>>>> >>>>>>> Note that I removed the Tested-by tag from Carlos Santa due to the >>>>>>> almost complete rework of the third patch. Carlos, can you test this again? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Hans >>>>>>> >>>>>>> Changes since v4: >>>>>>> >>>>>>> - Updated comment at the start of drm_dp_cec.c >>>>>>> - Add edid pointer to drm_dp_cec_configure_adapter >>>>>>> - Reworked the last patch (adding CEC to i915) based on Ville's comments >>>>>>> and my MST testing: >>>>>>> - register/unregister CEC in intel_dp_connector_register/unregister >>>>>>> - add comment and check if connector is registered in long_pulse >>>>>>> - unregister CEC if an MST 'connector' is detected. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dri-devel mailing list >>>>>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dri-devel mailing list >>>>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>>>>> >>>>> >>>>> _______________________________________________ >>>>> dri-devel mailing list >>>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>>>> >>>> >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
