CVS log for src/sys/dev/pci/pci_resource.c

Up to [cvs.NetBSD.org] / src / sys / dev / pci

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

pci_resource(9): Handle multiple bus ranges too.

Seen on orion o6.

Prompted by:

PR port-amd64/59118: Thinkpad T495s - iwm PCI BAR is zero

pci_resource(9): Handle multiple ranges of the same type.

Rather than having the caller fill in an array indexed by range type
of a single start/end pair for each type, the caller will now do:

	struct pci_resource_info info;

	memset(&info, 0, sizeof(info));

	pci_resource_add_range(&info, PCI_RANGE_MEM, mstart1, mend1);
	pci_resource_add_range(&info, PCI_RANGE_MEM, mstart2, mend2);
	pci_resource_add_range(&info, PCI_RANGE_MEM, mstart3, mend3);
	pci_resource_add_range(&info, PCI_RANGE_PMEM, pstart1, pend1);
	pci_resource_add_range(&info, PCI_RANGE_IO, iostart1, ioend1);
	...

While here, fix a format string -- 0x% or %# is enough to say that
the output is hexadecimal; we don't need to belabour the point by
printing a `0x0x' prefix!

XXX While this handles multiple io/mem/prefetchable-mem ranges, it
doesn't yet handle multiple bus ranges, which we have seen in
practice, e.g. on orion o6.  TBD.

ok jmcneill@

PR port-amd64/59118: Thinkpad T495s - iwm PCI BAR is zero

Pull up following revision(s) (requested by jmcneill in ticket #735):

	sys/dev/pci/pci_resource.c: revision 1.5
	sys/arch/arm/pci/pci_msi_machdep.c: revision 1.10
	sys/arch/aarch64/include/vmparam.h: revision 1.21
	sys/dev/acpi/acpi_resource.c: revision 1.43

pci_resource: Make unexpected bus numbers in bridges non-fatal.

Firmware bugs happen. Log a warning and continue instead of panicing.
acpi: Ignore producer/consumer bit for fixed memory resources.

The requirement to honour the producer/consumer bit in fixed memory
resource descriptors was dropped at some point in a revision to the ACPI
2.0 specification because too many firmware implementations got it wrong.

aarch64: Bump VM_PHYSSEG_MAX to match DRAM_BANKS / FDT_MEMORY_RANGES.

On aarch64 there is a single free list, so VM_PHYSSEG_MAX needs to be
the same as FDT_MEMORY_RANGES (which needs to be the same as DRAM_BANKS).

Future cleanup should be done to fold these into a single define.

arm: pci: Fix ITS ID lookup for MSIs.
pci_get_frameid expects a BDF requestor ID as input, not a Device ID.

Fixes MSI/MSI-X support on Ampere Altra systems.

Sync with HEAD.

pci_resource: Make unexpected bus numbers in bridges non-fatal.

Firmware bugs happen. Log a warning and continue instead of panicing.

Pull up following revision(s) (requested by jmcneill in ticket #483):

	sys/dev/pci/pci_resource.c: revision 1.4

pci: Improve resource allocation for non-prefetchable BARs.

When allocating resources for PCI devices, use the following criteria:
  - Prefetchable memory must be allocated from the prefetchable range
    of the parent bridge.
  - For 64-bit MMIO, try the prefetchable range first, and fallback to
    the non-prefetchable range. The idea here is to preserve 32-bit resources
    for 32-bit BARs.
  - For 32-bit MMIO, try the non-prefetchable range first. If that fails,
    make one last attempt at allocating from the prefetchable range, in the
    event that it has resources below 4GB.

pci: Improve resource allocation for non-prefetchable BARs.

When allocating resources for PCI devices, use the following criteria:
 - Prefetchable memory must be allocated from the prefetchable range
   of the parent bridge.
 - For 64-bit MMIO, try the prefetchable range first, and fallback to
   the non-prefetchable range. The idea here is to preserve 32-bit resources
   for 32-bit BARs.
 - For 32-bit MMIO, try the non-prefetchable range first. If that fails,
   make one last attempt at allocating from the prefetchable range, in the
   event that it has resources below 4GB.

pci_resource(9): Fix whitespace.

pci_resource(9): vmem_create and vmem_add never fail with VM_SLEEP.

Prune dead error branches.

Add a PCI resource manager and use it on Arm ACPI platforms.

The Arm ACPI code relied on PCI_NETBSD_CONFIGURE to configure devices that
were not enabled by system firmware. This is not safe to do unless the
firmware explicitly permits it using a device specific method defined in
the PCI firmware spec.

Introduce a new PCI resource manager that discovers what has already been
configured by firmware and allocates from the remaining space. This will
ensure that devices setup by firmware are untouched and only will program
BARs of devices that are not enabled at boot time.

The current implementation assumes that the parent PCI-PCI bridge's
are already configured. A worthwhile improvement in the future would be
to support programming windows for bridges that are not fully configured.