[RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Daniel Vetter]

On Fri, May 26, 2017 at 12:34 PM, Hans Verkuil <hverkuil at xs4all.nl> wrote:
>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>> index 78d7fc0ebb57..dd771ce8a3d0 100644
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> @@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE
>>>        default case is N. Details and instructions how to build your own
>>>        EDID data are given in Documentation/EDID/HOWTO.txt.
>>>
>>> +config DRM_DP_CEC
>>> +    bool
>>
>> We generally don't bother with a Kconfig for every little bit in drm, not
>> worth the trouble (yes I know there's some exceptions, but somehow they're
>> all from soc people). Just smash this into the KMS_HELPER one and live is
>> much easier for drivers. Also allows you to drop the dummy inline
>> functions.
>
> For all other CEC implementations I have placed it under a config option. The
> reason is that 1) CEC is an optional feature of HDMI and you may not actually
> want it, and 2) enabling CEC also pulls in the cec module.
>
> I still think turning this into a drm config option makes sense. This would
> replace the i915 config option I made in the next patch, i.e. this config option
> is moved up one level.
>
> Your choice, though.

If there is a CEC option already, can we just reuse that one? I.e.
when it's enabled, we compile the drm dp cec helpers, if it's not, you
get the pile of dummy functions. drm_dp_cec.c should still be part of
drm_kms_helper.ko though I think (since the dp aux stuff is in there
anyway, doesn't make sense to split it).

I'm still not sold on Kconfig proliferation for optional features
(have one for the driver, that's imo enough), but if it exists already
not going to block it's use in drm. As long as it's minimally invasive
on the code and drivers don't have to care at all.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch