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]

 



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 changed, so that's when I should
> detect whether there is a new branch device with CEC capabilities.

Just FYI: unfortunately this is delayed due to a lot of other work.
I will get back to this as soon as have some time.

Regards,

	Hans
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux