search for: full_pbn

...tand. You're saying this is going to change for already > existing connectors when something else gets plugged in, and either we > zero it out during the probe or it always was zero to begin with for > whatever reason? ok-me and Sean Paul did some playing around with available_pbn and full_pbn (I'll get into this one in a moment), and I also played around with a couple of different hubs and have a much better understanding of how this should work now. So: first off tl;dr available_pbn is absolutely not what we want in basically any scenario, we actually want to use the full_pbn fiel...

On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote: > On Thu, 2020-03-05 at 15:11 +0200, Ville Syrj?l? wrote: > > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote: > > > It's next to impossible for us to do connector probing on topologies > > > without occasionally racing with userspace, since creating a connector > > > itself causes a

...DP_MAX_DOWNSTREAM_PORTS being 16, but > > only > > having 4 ports worth of data in the DP_DOWNSTREAM_PORT_* registers. Do you > > know > > what's supposed to happen if dpcd[DP_DOWN_STREAM_PORT_COUNT] is > 4? > > > ok!! Taking a lesson from our available_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_C...

...ving a hard time rationalizing DP_MAX_DOWNSTREAM_PORTS being 16, but > only > having 4 ports worth of data in the DP_DOWNSTREAM_PORT_* registers. Do you > know > what's supposed to happen if dpcd[DP_DOWN_STREAM_PORT_COUNT] is > 4? > ok!! Taking a lesson from our available_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 >From section 5.3.3.1: Either one or four bytes are used, per DFP type indication. Therefore, up to...

...16, but > > > only > > > having 4 ports worth of data in the DP_DOWNSTREAM_PORT_* registers. Do you > > > know > > > what's supposed to happen if dpcd[DP_DOWN_STREAM_PORT_COUNT] is > 4? > > > > > ok!! Taking a lesson from our available_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'...

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

Now that we've added the hooks that we've needed for this and used them in i915, let's add one more hook (which I could use some feedback on, I'm not sure if it's worth maybe just reworking how we do mode pruning in nouveau instead...) and start using this in our mst ->mode_valid callback to filter out impossible to set modes on MST connectors. Lyude Paul (2):