@@ -117,15 +117,6 @@ nvkm_outp_acquire_hda(struct nvkm_outp *outp, enum nvkm_ior_type type,
117117{
118118 struct nvkm_ior * ior ;
119119
120- /* First preference is to reuse the OR that is currently armed
121- * on HW, if any, in order to prevent unnecessary switching.
122- */
123- list_for_each_entry (ior , & outp -> disp -> ior , head ) {
124- if (!ior -> identity && !!ior -> func -> hda .hpd == hda &&
125- !ior -> asy .outp && ior -> arm .outp == outp )
126- return nvkm_outp_acquire_ior (outp , user , ior );
127- }
128-
129120 /* Failing that, a completely unused OR is the next best thing. */
130121 list_for_each_entry (ior , & outp -> disp -> ior , head ) {
131122 if (!ior -> identity && !!ior -> func -> hda .hpd == hda &&
@@ -173,6 +164,27 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user, bool hda)
173164 return nvkm_outp_acquire_ior (outp , user , ior );
174165 }
175166
167+ /* First preference is to reuse the OR that is currently armed
168+ * on HW, if any, in order to prevent unnecessary switching.
169+ */
170+ list_for_each_entry (ior , & outp -> disp -> ior , head ) {
171+ if (!ior -> identity && !ior -> asy .outp && ior -> arm .outp == outp ) {
172+ /*XXX: For various complicated reasons, we can't outright switch
173+ * the boot-time OR on the first modeset without some fairly
174+ * invasive changes.
175+ *
176+ * The systems that were fixed by modifying the OR selection
177+ * code to account for HDA support shouldn't regress here as
178+ * the HDA-enabled ORs match the relevant output's pad macro
179+ * index, and the firmware seems to select an OR this way.
180+ *
181+ * This warning is to make it obvious if that proves wrong.
182+ */
183+ WARN_ON (hda && !ior -> func -> hda .hpd );
184+ return nvkm_outp_acquire_ior (outp , user , ior );
185+ }
186+ }
187+
176188 /* If we don't need HDA, first try to acquire an OR that doesn't
177189 * support it to leave free the ones that do.
178190 */
0 commit comments