History log of /freebsd/sys/x86/pci/pci_early_quirks.h (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 249e24d7 26-Jun-2024 Vladimir Kondratyev <wulf@FreeBSD.org>

x86/pci_early_quirks: Sync Intel 11th+ gen PCI IDs with Linux

Sponsored by: Serenity Cyber Security, LLC
MFC after: 1 week
Reviewed by: manu, imp
Differential Revision: https://reviews.freebsd.org/D

x86/pci_early_quirks: Sync Intel 11th+ gen PCI IDs with Linux

Sponsored by: Serenity Cyber Security, LLC
MFC after: 1 week
Reviewed by: manu, imp
Differential Revision: https://reviews.freebsd.org/D45617

show more ...


Revision tags: release/14.1.0, release/13.3.0, release/14.0.0
# 95ee2897 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/


Revision tags: release/13.2.0
# d780c6a6 13-Mar-2023 Jean-Sébastien Pédron <dumbbell@FreeBSD.org>

x86/pci_early_quirks: Support Intel 11th+ gen

Newer Intel CPUs/iGPUs use a new method to determine the base address of
the stolen memory. This code was ported from Linux.

Reviewed by: manu
Approved

x86/pci_early_quirks: Support Intel 11th+ gen

Newer Intel CPUs/iGPUs use a new method to determine the base address of
the stolen memory. This code was ported from Linux.

Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D39057

show more ...


Revision tags: release/12.4.0, release/13.1.0
# 16f02a4c 17-Dec-2021 Corvin Köhne <CorvinK@beckhoff.com>

pci: add missing PCI id of Coffee Lake GPU

The PCI id of an UHD Graphics 630 for Coffee Lake GPUs is missing in
the PCI id list of all Intel GPUs.

You can take a look at
https://dgpu-docs.intel.com

pci: add missing PCI id of Coffee Lake GPU

The PCI id of an UHD Graphics 630 for Coffee Lake GPUs is missing in
the PCI id list of all Intel GPUs.

You can take a look at
https://dgpu-docs.intel.com/devices/hardware-table.html to check that
this device id exists. Or check the linux code:
https://github.com/torvalds/linux/commit/d0e062ebb3a44b56a7e672da568334c76f763552

MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D33460

show more ...


Revision tags: release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0
# 2a22df74 04-Nov-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r339813 through r340125.


# 6bc6a542 01-Nov-2018 Konstantin Belousov <kib@FreeBSD.org>

Add pci_early function to detect Intel stolen memory.

On some Intel devices BIOS does not properly reserve memory (called
"stolen memory") for the GPU. If the stolen memory is claimed by the
OS, fu

Add pci_early function to detect Intel stolen memory.

On some Intel devices BIOS does not properly reserve memory (called
"stolen memory") for the GPU. If the stolen memory is claimed by the
OS, functions that depend on stolen memory (like frame buffer
compression) can't be used.

A function called pci_early_quirks that is called before the virtual
memory system is started was added. In Linux, this PCI early quirks
function iterates through all PCI slots to check for any device that
require quirks. While this more generic solution is preferable I only
ported the Intel graphics specific parts because I think my
implementation would be too similar to Linux GPL'd solution after
looking at the Linux code too much.

The code regarding Intel graphics stolen memory was ported from
Linux. In the case of Intel graphics stolen memory this
pci_early_quirks will read the stolen memory base and size from north
bridge registers. The values are stored in global variables that is
later read by linuxkpi_gplv2. Linuxkpi stores these values in a
Linux-specific structure that is read by the drm driver.

Relevant linuxkpi code is here:
https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.16/linuxkpi/gplv2/src/linux_compat.c#L37

For now, only amd64 arch is suppor ted since that is the only arch
supported by the new drm drivers. I was told that Intel GPUs are
always located on 0:2:0 so these values are hard coded for now.

Note that the structure and early execution of the detection code is
not required in its current form, but we expect that the code will be
added shortly which fixes the potential BIOS bugs by reserving the
stolen range in phys_avail[]. This must be done as early as possible
to avoid conflicts with the potential usage of the memory in kernel.

Submitted by: Johannes Lundberg <johalun0@gmail.com>
Reviewed by: bwidawsk, imp
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D16719
Differential revision: https://reviews.freebsd.org/D17775

show more ...