Page MenuHomeFreeBSD

Commit candidate for D16719
ClosedPublic

Authored by kib on Oct 31 2018, 3:56 AM.

Details

Summary

This is what I intend to commit. Changed to D16719 are that I moved pci_early_quirks.* to amd64/pci, moved the function prototype to amd64 machine/md_var.h, added printf() to show results of quirks under bootverbose, and did some additional minor style adjustments.

If you are fine with these last editings, confirm and I will commit the patch.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 20530

Event Timeline

This revision is now accepted and ready to land.Oct 31 2018, 8:59 AM

these look good to me. Just a question over putting intel_ in a name for a facility that looks like it might be more generic than that...

sys/x86/pci/pci_early_quirks.c
57–58

So these variable names are set by the LinuxKPI?
The question that comes to mind is would we ever have something similar for AMD? Would it use the same name? Does that matter?

sys/x86/pci/pci_early_quirks.h
33

I was going to flag exactly this issue... Thanks for the comment...

sys/x86/pci/pci_early_quirks.c
57–58

In Linux this is a public struct resource called intel_graphics_stolen_res so it's intended for single use.

What if we have systems with internal Intel GPU and external AMD GPU where both need to be defined...

kib marked an inline comment as done.Oct 31 2018, 3:36 PM
kib added inline comments.
sys/x86/pci/pci_early_quirks.c
57–58

This stuff is not relevant to the PCIe-connected AMD chips, by its definition. The vars provide the information about UMA region of the physical memory consumed by the north bridge/graphics part of the chip. On-cpu AMD graphic chips use UMA as well, so they should have something similar, but I am sure that there is no 1:1 correspondence between hardware reporting facilities on intel and amd n/b. So it does make sense to have dedicated vars.