drm/i915/fbdev: Fix MTL console scanout [FreeBSD]

[JustAnotherHumanBeing]

Summary

• use a direct WB object mapping for Meteor Lake's shmem-backed fbdev on FreeBSD
• flush dirty console ranges before display scanout
• balance the direct mapping pin during teardown and failed initialization

Root cause

Wa_22018444074 prevents the Meteor Lake fbdev framebuffer from using stolen memory, so it falls back to shmem. On FreeBSD, CPU writes through the GGTT/GMADR iomap can fail to update the shmem pages scanned out by the display engine after the EFI framebuffer handoff. The observed result was a lit but black 4K HDMI display after i915 replaced efifb.

Mapping the actual shmem object with I915_MAP_WB makes the console visible, and flushing each dirty range makes those WB writes coherent for scanout without the severe refresh slowdown seen with a WC direct mapping. The existing GGTT iomap path remains unchanged for non-Meteor-Lake hardware.

Testing

• clean-built i915kms.ko from official master with the module's normal -Werror flags
• tested EFI-to-i915 takeover on Meteor Lake graphics device 0x7d55
• verified visible, normally refreshing VT output on a 4K HDMI television that was black before this fix
• verified no external-output regression with a 1080p HDMI monitor
• verified Plasma handoff and dual-display operation
• repeated module-load and reboot testing with no observed panic, map leak, or display regression

[amshafer]

You may be interested in testing with: https://reviews.freebsd.org/D59436