drm/nouveau/disp/gm200-: fix regression from HDA SOR selection changes
authorBen Skeggs <bskeggs@redhat.com>
Wed, 8 Jul 2020 07:28:09 +0000 (17:28 +1000)
committerBen Skeggs <bskeggs@redhat.com>
Fri, 24 Jul 2020 08:33:13 +0000 (18:33 +1000)
Fixes: 9b5ca547bb8 ("drm/nouveau/disp/gm200-: detect and potentially disable HDA support on some SORs")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c

index dcf0824..dffcac2 100644 (file)
@@ -117,15 +117,6 @@ nvkm_outp_acquire_hda(struct nvkm_outp *outp, enum nvkm_ior_type type,
 {
        struct nvkm_ior *ior;
 
-       /* First preference is to reuse the OR that is currently armed
-        * on HW, if any, in order to prevent unnecessary switching.
-        */
-       list_for_each_entry(ior, &outp->disp->ior, head) {
-               if (!ior->identity && !!ior->func->hda.hpd == hda &&
-                   !ior->asy.outp && ior->arm.outp == outp)
-                       return nvkm_outp_acquire_ior(outp, user, ior);
-       }
-
        /* Failing that, a completely unused OR is the next best thing. */
        list_for_each_entry(ior, &outp->disp->ior, head) {
                if (!ior->identity && !!ior->func->hda.hpd == hda &&
@@ -173,6 +164,27 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user, bool hda)
                return nvkm_outp_acquire_ior(outp, user, ior);
        }
 
+       /* First preference is to reuse the OR that is currently armed
+        * on HW, if any, in order to prevent unnecessary switching.
+        */
+       list_for_each_entry(ior, &outp->disp->ior, head) {
+               if (!ior->identity && !ior->asy.outp && ior->arm.outp == outp) {
+                       /*XXX: For various complicated reasons, we can't outright switch
+                        *     the boot-time OR on the first modeset without some fairly
+                        *     invasive changes.
+                        *
+                        *     The systems that were fixed by modifying the OR selection
+                        *     code to account for HDA support shouldn't regress here as
+                        *     the HDA-enabled ORs match the relevant output's pad macro
+                        *     index, and the firmware seems to select an OR this way.
+                        *
+                        *     This warning is to make it obvious if that proves wrong.
+                        */
+                       WARN_ON(hda && !ior->func->hda.hpd);
+                       return nvkm_outp_acquire_ior(outp, user, ior);
+               }
+       }
+
        /* If we don't need HDA, first try to acquire an OR that doesn't
         * support it to leave free the ones that do.
         */