similar to: [PATCH 04/15] drm/dp_mst: Add PBN calculation for DSC modes

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: intel-gfx at

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: intel-gfx at

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: intel-gfx at

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: intel-gfx at

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

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Manasi Navare <manasi.d.navare at

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Manasi Navare <manasi.d.navare at

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Manasi Navare <manasi.d.navare at

On 8/8/19 1:04 PM, Lyude Paul wrote: > I -thought- I had fixed this entirely, but it looks like that I didn't > test this thoroughly enough as we apparently still make one big mistake > with nv50_msto_atomic_check() - we don't handle the following scenario: > > * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 > which is attached to encoder #1.

On Thu, 2019-08-08 at 18:17 +0000, William Lewis wrote: > On 8/8/19 1:04 PM, Lyude Paul wrote: > > I -thought- I had fixed this entirely, but it looks like that I didn't > > test this thoroughly enough as we apparently still make one big mistake > > with nv50_msto_atomic_check() - we don't handle the following scenario: > > > > * CRTC #1 has n VCPI

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

I -thought- I had fixed this entirely, but it looks like that I didn't test this thoroughly enough as we apparently still make one big mistake with nv50_msto_atomic_check() - we don't handle the following scenario: * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 which is attached to encoder #1. enabled=y active=n * CRTC #1 is changed from DP-4 to DP-5, causing: *

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

I -thought- I had fixed this entirely, but it looks like that I didn't test this thoroughly enough as we apparently still make one big mistake with nv50_msto_atomic_check() - we don't handle the following scenario: * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 which is attached to encoder #1. enabled=y active=n * CRTC #1 is changed from DP-4 to DP-5, causing: *

Latest version of https://patchwork.freedesktop.org/series/39642/ , hopefully patchwork understands this and doesn't break anything! Lots of changes. Lyude Paul (10): drm/atomic: Print debug message on atomic check failure drm/i915: Move DP modeset retry work into intel_dp drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state() drm/dp_mst: Remove all evil duplicate state

Latest version of PW series 39642, hopefully this should also actually come up on intel-gfx and go through CI. No changes other than rebasing to the current drm-intel-next-queued Lyude Paul (10): drm/atomic: Print debug message on atomic check failure drm/i915: Move DP modeset retry work into intel_dp drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state() drm/dp_mst: Remove all

Next version of https://patchwork.freedesktop.org/series/41576/ Only changes are removing duplicate SoBs that git send-email annoyingly added. Sorry about that :( Lyude Paul (10): drm/atomic: Print debug message on atomic check failure drm/i915: Move DP modeset retry work into intel_dp drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state() drm/dp_mst: Remove all evil duplicate

Next version of https://patchwork.freedesktop.org/series/41576/ All changes in this patch series are just to make checkpatch a little happier, no functional changes. Lyude Paul (10): drm/atomic: Print debug message on atomic check failure drm/i915: Move DP modeset retry work into intel_dp drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state() drm/dp_mst: Remove all evil duplicate

There's no actual reason we pass the connector ID instead of a pointer to the connector itself, and we're going to need the entire connector (but only temporarily) in order to name MST debugfs folders properly since connector IDs can't be looked up until the driver has been registered with userspace which happens after debugfs init. So, just pass the entire drm_connector struct

There's no actual reason we pass the connector ID instead of a pointer to the connector itself, and we're going to need the entire connector (but only temporarily) in order to name MST debugfs folders properly since connector IDs can't be looked up until the driver has been registered with userspace which happens after debugfs init. So, just pass the entire drm_connector struct