Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux