[PATCH] drm/amd: DC pull request review

[Harry Wentland]

On 2017-09-27 02:12 PM, Harry Wentland wrote:
> On 2017-09-27 12:48 PM, Daniel Vetter wrote:
>> On Wed, Sep 27, 2017 at 6:38 PM, Sean Paul <seanpaul at chromium.org> wrote:
>>> Any chance we can address the i2c/gpio [re-]implementations as well?
>>
>> It's already on the list. Part of this is code that's probably dead,
>> the other is a bit too much layer cake still left, and the final bits
>> are not fully using drm helpers for edid parsing and tons of other
>> stuff. But afaics all the i2c stuff does go through the i2c_adapter
>> abstraction in a proper fashion, which is at least the foundational
>> work. The other bits should be all captured in the todo already.
> 
> There might still be some dead code around i2c stuff. I'll take a look
> and see what I can rip out.
> 

Looks like there currently are no easy pickings. What we have is:

1) Connector info read

See get_ext_display_connection_info

On some boards the connector information has to be read through a
special I2C channel. This line is only used for this purpose and only on
driver init.


2) SCDC stuff

This should all be reworked to go through DRM's SCDC code. When this is
done some unnecessary I2C code can be retired as well.


3) Max TMDS clock read

See dal_ddc_service_i2c_query_dp_dual_mode_adaptor

This should happen in DRM as well. I haven't checked if there's
currently functionality in DRM. If not we can propose something.


4) HDMI retimer programming

Some boards have an HDMI retimer that we need to program to pass PHY
compliance.

It would take a bit of time to address all of them. I'll add them on the
TODO.

1 & 3 might be a good exercise if someone is looking for things to do.

Harry


> If there's any specific function, struct, etc. that's of concern let me
> know as well.
> 
> Harry
> 
>> -Daniel
>>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>