search for: dp_detailed_cap_info_available

...m ports, no sense in reading the whole thing every time v2: * Fixup logic for calculating the downstream port length to account for the fact that downstream port caps can be either 1 byte or 4 bytes long. We can actually skip fixing the max_clock/max_bpc helpers here since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway. * Fix ret code check for drm_dp_dpcd_read Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/drm_dp_helper.c | 46 +++++++++++++++++++++++++ drivers/gpu/drm/i915/display/intel_dp.c | 14 ++------ include/drm/drm_dp_helper.h | 3 ++ 3 files chang...

...m ports, no sense in reading the whole thing every time v2: * Fixup logic for calculating the downstream port length to account for the fact that downstream port caps can be either 1 byte or 4 bytes long. We can actually skip fixing the max_clock/max_bpc helpers here since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway. * Fix ret code check for drm_dp_dpcd_read v5: * Change name from drm_dp_downstream_read_info() to drm_dp_read_downstream_info() * Also, add "See Also" sections for the various downstream info functions (drm_dp_read_downstream_info(), drm_dp_downstream_max_clock(), drm_dp_dow...

..._pbn/full_pbn confusion in the past, I > squinted very hard at the specification and eventually found something that I > think clears this up. Surprise - we definitely had this implemented incorrectly > in i915 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 o...

...quinted very hard at the specification and eventually found something that > > I > > think clears this up. Surprise - we definitely had this implemented > > incorrectly > > in i915 > > To me it looks correct, only DFP0's cap info is used, by also handling > the DP_DETAILED_CAP_INFO_AVAILABLE=0/1 cases. Ended up realizing this right after I sent this version 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...

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

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

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code