Displaying 3 results from an estimated 3 matches for "00080h".
Did you mean:
0000h
2020 Aug 20
2
[RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()
...To me it looks correct, only DFP0's cap info is used, by also handling
the DP_DETAILED_CAP_INFO_AVAILABLE=0/1 cases.
The wording is a bit unclear, but as I understand the Standard only
calls for the above:
"""
A DP upstream device shall read the capability from DPCD Addresses 00080h
through 00083h. A DP Branch device with multiple DFPs shall report the detailed
capability information of the lowest DFP number to which a downstream device
is connected, consistent with the DisplayID or legacy EDID access routing policy
of an SST-only DP Branch device as described in Section 2.1.4...
2020 Aug 21
0
[RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()
...rsion of the RFC - yeah, it
definitely shouldn't be causing any real problems as of now
>
> The wording is a bit unclear, but as I understand the Standard only
> calls for the above:
>
> """
> A DP upstream device shall read the capability from DPCD Addresses 00080h
> through 00083h. A DP Branch device with multiple DFPs shall report the
> detailed
> capability information of the lowest DFP number to which a downstream device
> is connected, consistent with the DisplayID or legacy EDID access routing
> policy
> of an SST-only DP Branch device...
2020 Aug 19
3
[RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()
On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> We're going to be doing the same probing process in nouveau for
> determining downstream DP port capabilities, so let's deduplicate the
> work by moving i915's code for handling this into a shared helper:
> drm_dp_downstream_read_info().
>
> Note that when we do this, we also do make some functional