intel: initialize GMADR on meteorlake and newer on freebsd

This fixes issues with the smem_start being nonzero but invalid,
which caused panics on meteorlake.

The problem is that the GMADR was not getting initialized on mtl
which we need in order to use shmem framebuffers. We are falling
back to shmem framebuffers on freebsd because the Wa_22018444074
mtl hardware workaround disabled using stolen memory on mtl. We
end up trying to use shmem but due to Wa_22018444074 GMADR is
not valid so we end up with a value such as 0x2000 instead of a
valid pointer.

This change initializes GMADR on meteorlake. Linux has likely not
run into this as they do not actually consume the physical address
in smem_start like we do when we pass it to register_fictitious_range.

See freebsd#324

Author: amshafer

drivers/gpu/drm/i915/gt/intel_ggtt.c

@@ -1229,7 +1229,22 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 	unsigned int size;
 	u16 snb_gmch_ctl;
 
+#ifdef __linux__
 	if (!HAS_LMEM(i915) && !HAS_LMEMBAR_SMEM_STOLEN(i915)) {
+#elif defined(__FreeBSD__)
+	/*
+	 * We need to initialize GMADR on freebsd in order to use shmem
+	 * framebuffers. We are falling back to shmem framebuffers on freebsd
+	 * because the Wa_22018444074 mtl hardware workaround disabled using stolen
+	 * memory on mtl. Unlike on linux, when this happens we end up passing an
+	 * invalid phys address to register_fictitious_range which causes a panic.
+	 * Because GMADR is not valid we end up with a value such as 0x2000 instead
+	 * of a valid pointer.
+	 * MTL has LMEMBAR for stolen but still needs GMADR for shmem objects.
+	 */
+	if ((!HAS_LMEM(i915) && !HAS_LMEMBAR_SMEM_STOLEN(i915))
+			|| HAS_LMEMBAR_SMEM_STOLEN(i915)) {
+#endif
 		if (!i915_pci_resource_valid(pdev, GEN4_GMADR_BAR))
 			return -ENXIO;