@@ -117,15 +117,6 @@ nvkm_outp_acquire_hda(struct nvkm_outp *outp, enum nvkm_ior_type type,
117
117
{
118
118
struct nvkm_ior * ior ;
119
119
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
-
129
120
/* Failing that, a completely unused OR is the next best thing. */
130
121
list_for_each_entry (ior , & outp -> disp -> ior , head ) {
131
122
if (!ior -> identity && !!ior -> func -> hda .hpd == hda &&
@@ -173,6 +164,27 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user, bool hda)
173
164
return nvkm_outp_acquire_ior (outp , user , ior );
174
165
}
175
166
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
+
176
188
/* If we don't need HDA, first try to acquire an OR that doesn't
177
189
* support it to leave free the ones that do.
178
190
*/
0 commit comments