All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: ville.syrjala@linux.intel.com
Cc: dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
Date: Fri, 12 Jan 2018 20:08:57 +0100	[thread overview]
Message-ID: <9e28a8fe-c792-df98-012d-f7d02ad1e9b2@xs4all.nl> (raw)
In-Reply-To: <47a32832-4a4e-c66b-2d7f-f8f7a6093ada@xs4all.nl>

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

  reply	other threads:[~2018-01-12 19:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-20 11:42 [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support Hans Verkuil
2017-11-20 11:42 ` Hans Verkuil
2017-11-20 11:42 ` [PATCHv5 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX Hans Verkuil
2017-11-20 11:42   ` Hans Verkuil
2018-05-02  8:24   ` [PATCHv5, " Dariusz Marcinkiewicz
2018-05-02  8:24     ` Dariusz Marcinkiewicz
2018-05-02  8:33     ` Hans Verkuil
2018-05-02  8:33       ` Hans Verkuil
2017-11-20 11:42 ` [PATCHv5 2/3] drm-kms-helpers.rst: document the DP CEC helpers Hans Verkuil
2017-11-20 11:42 ` [PATCHv5 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support Hans Verkuil
2017-12-01  7:23 ` [PATCHv5 0/3] " Hans Verkuil
2017-12-01  7:23   ` Hans Verkuil
2017-12-11  8:57   ` Hans Verkuil
2018-01-09 12:46     ` Hans Verkuil
2018-01-09 12:46       ` Hans Verkuil
     [not found]       ` <7ec14da2-7aed-906e-3d55-8af1907aaf0c@xs4all.nl>
2018-01-12 16:30         ` Fwd: " Ville Syrjälä
2018-01-12 17:14           ` Hans Verkuil
2018-01-12 17:52             ` Ville Syrjälä
2018-01-12 18:12               ` Hans Verkuil
2018-01-12 18:12                 ` Hans Verkuil
2018-01-12 19:08                 ` Hans Verkuil [this message]
2018-02-12 10:11                   ` Hans Verkuil
2018-06-11 12:20                     ` Hans Verkuil
2018-06-11 12:20                       ` Hans Verkuil
2018-06-12 10:23                       ` Hans Verkuil
2018-06-12 10:23                         ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e28a8fe-c792-df98-012d-f7d02ad1e9b2@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-media@vger.kernel.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.