[Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

[Daniel Vetter]

On Wed, Nov 23, 2016 at 4:52 PM, Jani Nikula
<jani.nikula at linux.intel.com> wrote:
>> Take the CDN DP driver in rockchip for example (posted yesterday).
>> There's a worker in the driver that is responsible for handling
>> hpd/extcon events from the USB-C port. Ideally, this worker should
>> just be a thin shell around a kms uevent that lets userspace know
>> there's been a change. Unfortunately since we need to make re-training
>> work (/me grumbles about productization) seamlessly, we need to add a
>> bunch of goo into the worker to handle re-training. Since we need to
>> handle re-training there and in modeset, we need to properly
>> synchronize things. So we end up with a bunch of code that doesn't
>> *really* need to be there.
>>
>> So is the correct path forward to add GOOD/BAD connection handling to
>> Chrome/drm_hwc
>
> I think so.
>
>> and rip re-training out of the various kernel drivers?
>
> IMO if it works, don't change it, at least not in a rush. It also
> depends on the hardware and the driver; the amount of code required may
> be vastly different for various drivers.
>
> Personally, I think in the long run letting userspace help here leads to
> a simpler design and more efficient happy day scenario handling, and
> userspace knows what's going on.

We can't rip out re-training from existing drivers since it would
break existing userspace in certain cases (like cable re-plug into
same screen). But we could try to not implement so much for new
drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch