> I'm guessing this is v2 of [1], but I shouldn't have to guess. You're right, it is effectively v2 of [1] -- same patch, no functional change. Sorry for not labelling it.
[1] was pasted into a mail client by hand, which hard-wrapped the "diff --git" lines and turned the leading tabs into spaces. It did reach the lists, but not as an applicable patch, so I resent it with git send-email and didn't think of it as a revision. I'll use proper vN and changelogs from here on. > Is there a bug report about this? Would be nice to see the logs in the > failing case. See [2]. There wasn't one -- I went straight to the list. Filed now: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/17087 It has the full failing-case log with drm debug enabled, on an unpatched i915 with the panel muxed to the iGPU. AUX and EDID are fine, and then the panel's only mode is pruned: [drm:intel_dp_print_rates] sink rates: 162000, 270000 [drm:update_display_info] [CONNECTOR:93:eDP-1] Assigning EDID-1.4 digital sink color depth as 8 bpc. [drm:drm_mode_prune_invalid] Rejected mode: "2880x1800": 60 337750 2880 2928 2960 3040 1800 1803 1809 1852 0x48 0x9 (CLOCK_HIGH) because intel_ddi_max_lanes() reports a source maximum of 2 for port A. The matching log with the quirk applied is attached too, where the same link trains at lane count 4. > i915_vbt from debugfs would also be interesting. Attached to the bug as i915_vbt.bin, 6144 bytes -- a $VBT HASWELL block, BIOS build 1215 dated 12/13/2012, on Apple firmware 427.140.8.0.0. Say the word if you'd rather have a specific block dumped inline. > The patch itself looks sane. Thanks. One thing I got wrong in the commit message, which v3 fixes: I wrote Broadwell, but the machine is Haswell Crystal Well -- i7-4980HQ, 8086:0d26, $VBT HASWELL, and i915 logs "Found haswell". Apple's ACPI DMAR OEM string says BDW, which is what misled me. No code change; the quirk matches on DMI model either way. I'll send it as v3 rather than v2, to match the numbering you used above -- neither earlier posting was labelled, and renumbering them now would just recreate the ambiguity. It has that fix, a Closes: tag for the bug, and a changelog spelling out what v1 and v2 were. BR, Theo
