search for: pbn

With DSC, bpp can be fractional in multiples of 1/16. Change drm_dp_calc_pbn_mode to reflect this, adding a new parameter bool dsc. When this parameter is true, treat the bpp parameter as having units not of bits per pixel, but 1/16 of a bit per pixel v2: Don't add separate function for this Cc: amd-gfx at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc:...

From: David Francis <David.Francis at amd.com> With DSC, bpp can be fractional in multiples of 1/16. Change drm_dp_calc_pbn_mode to reflect this, adding a new parameter bool dsc. When this parameter is true, treat the bpp parameter as having units not of bits per pixel, but 1/16 of a bit per pixel v2: Don't add separate function for this Change-Id: I33ef6f53c44dc32aa869aa9741ba0339aaf5e54f Cc: amd-gfx at lists.fre...

With DSC, bpp can be fractional in multiples of 1/16. Change drm_dp_calc_pbn_mode to reflect this, adding a new parameter bool dsc. When this parameter is true, treat the bpp parameter as having units not of bits per pixel, but 1/16 of a bit per pixel v2: Don't add separate function for this Cc: amd-gfx at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc:...

With DSC, bpp can be fractional in multiples of 1/16. Change drm_dp_calc_pbn_mode to reflect this, adding a new parameter bool dsc. When this parameter is true, treat the bpp parameter as having units not of bits per pixel, but 1/16 of a bit per pixel v2: Don't add separate function for this Cc: amd-gfx at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc:...

With DSC, bpp can be fractional in multiples of 1/16. Change drm_dp_calc_pbn_mode to reflect this, adding a new parameter bool dsc. When this parameter is true, treat the bpp parameter as having units not of bits per pixel, but 1/16 of a bit per pixel v2: Don't add separate function for this Cc: amd-gfx at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc:...

Atomic checks should never modify anything outside of the state that they're passed in. Unfortunately this appears to be exactly what we're doing in nv50_msto_atomic_check() where we update mstc->pbn every time the function is called. This hasn't caused any bugs yet, but it needs to be fixed in order to ensure that when committing an artificially duplicated state (like during system resume), that we reuse the PBN of that state to perform VCPI allocations and don't recalculate a differen...

Yes, apparently we've been testing this for every single driver load for quite a long time now. At least that means our PBN calculation is solid! Anyway, introduce self tests for MST and move this into there. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry Wentland <hwentlan at amd.com> Reviewed-by: Dan...

...d, 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 hotplug event which we have to send before probing the > available PBN of a connector. Even if we didn't have this hotplug event > sent, there's still always a chance that userspace started probing > connectors before we finished probing the topology. > > This can be a problem when validating a new MST state since the > connector will be shown...

...der.deucher at amd.com> Cc: Sean Paul <seanpaul at google.com> Cc: Hans de Goede <hdegoede at redhat.com> Lyude Paul (3): drm/dp_mst: Rename drm_dp_mst_is_dp_mst_end_device() to be less redundant drm/dp_mst: Don't show connectors as connected before probing available PBN drm/dp_mst: Rewrite and fix bandwidth limit checks drivers/gpu/drm/drm_dp_mst_topology.c | 124 ++++++++++++++++++++------ 1 file changed, 96 insertions(+), 28 deletions(-) -- 2.24.1

...de 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 hotplug event which we have to send before probing the > > > available PBN of a connector. Even if we didn't have this hotplug event > > > sent, there's still always a chance that userspace started probing > > > connectors before we finished probing the topology. > > > > > > This can be a problem when validating a new MST state...

...5: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 hotplug event which we have to send before probing the > > available PBN of a connector. Even if we didn't have this hotplug event > > sent, there's still always a chance that userspace started probing > > connectors before we finished probing the topology. > > > > This can be a problem when validating a new MST state since the > >...

...cenario is repeated once, we'll attempt freeing VCPI from the connector that we didn't allocate due to the connectors changing, but the mode staying the same. Sigh. Since nv50_msto_atomic_check() has broken a few times now, let's rethink things a bit to be more careful: limit both VCPI/PBN allocations to mode_changed || connectors_changed, since neither VCPI or PBN should ever need to change outside of routing and mode changes. Signed-off-by: Lyude Paul <lyude at redhat.com> Reported-by: Bohdan Milar <bmilar at redhat.com> Tested-by: Bohdan Milar <bmilar at redhat.com...

...> > > 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 hotplug event which we have to send before probing the > > > > available PBN of a connector. Even if we didn't have this hotplug > > > > event > > > > sent, there's still always a chance that userspace started probing > > > > connectors before we finished probing the topology. > > > > > > > > This can be a...

Since nv50_outp_atomic_check_view() can set crtc_state->mode_changed, we probably should be calling it before handling any PBN changes. Just a precaution. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: David Airlie <airlied at redhat.c...

...cenario is repeated once, we'll attempt freeing VCPI from the connector that we didn't allocate due to the connectors changing, but the mode staying the same. Sigh. Since nv50_msto_atomic_check() has broken a few times now, let's rethink things a bit to be more careful: limit both VCPI/PBN allocations to mode_changed || connectors_changed, since neither VCPI or PBN should ever need to change outside of routing and mode changes. Changes since v1: * Fix accidental reversal of clock and bpp arguments in drm_dp_calc_pbn_mode() - William Lewis Signed-off-by: Lyude Paul <lyude at re...

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 hotplug event which we have to send before probing the available PBN of a connector. Even if we didn't have this hotplug event sent, there's still always a chance that userspace started probing connectors before we finished probing the topology. This can be a problem when validating a new MST state since the connector will be shown as connected briefly, but...

...g VCPI > > from the connector that we didn't allocate due to the connectors > > changing, but the mode staying the same. Sigh. > > > > Since nv50_msto_atomic_check() has broken a few times now, let's rethink > > things a bit to be more careful: limit both VCPI/PBN allocations to > > mode_changed || connectors_changed, since neither VCPI or PBN should > > ever need to change outside of routing and mode changes. > > > > Signed-off-by: Lyude Paul <lyude at redhat.com> > > Reported-by: Bohdan Milar <bmilar at redhat.com&gt...

..., we'll attempt freeing VCPI > from the connector that we didn't allocate due to the connectors > changing, but the mode staying the same. Sigh. > > Since nv50_msto_atomic_check() has broken a few times now, let's rethink > things a bit to be more careful: limit both VCPI/PBN allocations to > mode_changed || connectors_changed, since neither VCPI or PBN should > ever need to change outside of routing and mode changes. > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Reported-by: Bohdan Milar <bmilar at redhat.com> > Tested-by: Bohdan M...

...> > > 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 hotplug event which we have to send before probing the > > > > available PBN of a connector. Even if we didn't have this hotplug > > > > event > > > > sent, there's still always a chance that userspace started probing > > > > connectors before we finished probing the topology. > > > > > > > > This can be a...

Looks like a regression got introduced into nv50_mstc_atomic_check() that somehow didn't get found until now. If userspace changes crtc_state->active to false but leaves the CRTC enabled, we end up calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in asyh->dp.pbn. However, if the display is inactive we end up calculating a PBN of 0, which inadvertently causes us to have an allocation of 0. >From there, if userspace then disables the CRTC afterwards we end up accidentally attempting to free the VCPI twice: WARNING: CPU: 0 PI...