| Age | Commit message (Collapse) | Author |
|---|
|
busses.
tested by krw@
|
|
space and not noticing because they only test on amd64. So enforce alignment
there as well, at least for a little while such that we find those bugs and
force people to fix them.
|
|
separate functions and install them as route/unroute functions for the
MIS pseudo-PIC.
|
|
From Brad.
|
|
|
|
|
|
behind a prehistoric Intel host bridge. Disable MSI on these contortion.
|
|
chipsets. All of those that support 64-bit CPUs should support MSI as well.
Explicitly disable MSI on chipsets that connect to the CPU over HyperTransport.
Enabling MSI on those systems is handled by the HyperTransport support code
in our PCI subsystem.
|
|
|
|
this code differs somewhat from the i386 code because the amd64 interrupt
subsystem is quite different. Still disabled like on i386.
|
|
interrupts. It is irreleveant, confuses people and the information is
available in pcidump(8) output anyway.
ok oga@, jsg@, deraadt@
|
|
addresses >4GB to 64-bit BARs have started to appear. But as long as machines
still support running 32-bit operating systems we don't expect to see BARs
that aren't addressable using PAE. Fixes a panic reported by william@.
ok deraadt@
|
|
With current strategies to put memory in the ``correct'' place it isn't
needed. There's also the problem that it did not work on all machines,
failing completely on some and utterly breaking DMA. So just remove it.
If anyone needs it it will be in the Attic.
ok deraadt@
|
|
devices on AMD Family 0Fh processors.
|
|
advertised in the MCFG table, and fall back on the traditional method for
other busses. Fixes issue reported by henning@.
|
|
access to PCIe extended configuration space access on modern i386 and amd64
machines.
|
|
given pcitag_t configuration address space. Currently, all pci controllers
will return the usual 0x100 bytes of PCI configuration space, but this will
eventually change on PCIe-capable controlers.
ok kettenis@
|
|
tested by naddy@, ok dlg@
|
|
compiler from doing stupid things like reordering stores around it. There is
some debate whether this will be enough for newer versions of GCC and LLVM.
If this is indeed deemed necessary, this will be addressed in a future diff.
ok miod@, oga@
|
|
DVACT_SUSPEND, therefore DVACT_QUIECE can do standard sleeping operations
to get ready.
Discussed quite a while back with kettenis and jakemsr, oga suddenly needed
it as well and wrote half of it, so it was time to finish it.
proofread by miod.
|
|
|
|
ok kettenis
|
|
Simplify resource parsing function to use buffer argument
Convert namespace linked lists to use queue macros
ok marco@, deraadt@
|
|
|
|
|
|
ok kettenis, deraadt
|
|
ok dlg@
|
|
things that there really isn't a decent api for elsewhere.
Since on recent intel IGPs the gtt aperture is too big (256meg is not
uncommon) to be mapped on a kva-constrained arch like i386, introduce an agp
mapping api that does things depending on arch.
On amd64 which can afford the space (and will use the direct mapping
again soon)just do bus_space_map() on init, then parcels things out
using bus_space_subregion(), thus avoiding map/unmap overhead on every
call (this is how inteldrm does things right now).
On i386, we do bus_space_map() and bus_space_unmap as appropriate. Linux
has some tricks here involving ``atomic'' maps that are on only one cpu
and that you may not sleep with to avoid the ipi overhead for tlb
flushing. For now we don't go down that route but it is being
considered.
I am also considering if it is worth abstracting this a little more,
improving the api and making it a general MD interface.
Tested by myself on i386 and amd64 and by drahn@ (who has one of the
machines with an aperture that is too big) on i386.
|
|
if supported.
When we do memory management on intel this would lead to a LOT of
wbinvd() to deal with gpu->cpu incoherency. no one wants that.
Needed for sanity of inteldrm memory management which is coming up next.
|
|
keep attaching bus 0 forever.
tested by mk@
|
|
didn't quite work since the bridge seems to end up largely unconfigured, and
our PCI resource configuration code isn't quite smart enough (yet) to fix
things up. So instead switch it only into PCI-PCI bridge mode long enough to
snoop the bus number, and attach pci(4) using that number.
This is probably safer anyway, since ACPI may not like us switching things
around behind its back. Fixes PR 6253 & 6304.
|
|
|
|
This should prevent problems on systems where these areas are not reserved in
the BIOS memory map.
ok miod@, oga@, marco@
|
|
that makes the PCIE device show up as a host bridge instead of a
PCI-PCI bridge. As a result any devices sitting behind it won't be
detected. Whack the device into PCI-PCI mode such that we can walk the
PCI bus hierarchy the normal way and detect all devices. Fixes PR 6215.
ok dlg@
|
|
Tested by myself, sthen, oga, kettenis, and jasper.
Input from sthen and jasper.
ok kettenis
(Manpage follows shortly.)
|
|
logic to be chipset dependent; no functional change yet.
ok kettenis@
|
|
ok deraadt@ kettenis@
|
|
aperture, which will take your memory, bind it to agp, and return you the
aperture address. It's essentially the same as iommu on amd64 in the way it
works.
This will be used by the upcoming (works but is slow and will not be
enabled at first) drm memory management code for intel igp chipsets.
Right now the sync function for intagp is really slow (doing a wbinvd()
on every sync), this is in the process of getting fixed, but the size of
the diffs in my trees was getting silly.
|
|
|
|
|
|
Tested on multiple i386 and it works, amd64 works also with a few
exceptions that will get fixed.
The initial effort of importing was done by oga@, thanks!
Lots of testing and debugging by mlarkin@ and me.
Okay deraadt@, oga@, mlarkin@.
|
|
unwanted matching logic.
ok oga@ deraadt@ miod@
|
|
amas defaults to disabled on both amd64 and i386.
"Go for it!" kettenis@
|
|
the type we bind to an iommu or a GART is paddr_t, by definition, on the
other hand, the type we get out of it is not a vaddr_t, it's bus_addr_t.
fix up sparc64 iommu, amd64 iommu and the sg_dma backedn that uses it to
realise this.
ok kettenis@
|
|
can only address the first 64K but BARs can contain garbage and addresses
beyond the end of the extent would cause a panic.
|
|
see the ancient mode 2 on machines capable of running OpenBSD/amd64.
ok deraadt@, toby@, oga@
|
|
mapping to the gart than the old code, and shouldn't conflict with
bouncebuffers when they're added.
This is essentially the sparc64 iommu code that's been modularised a bit
so I can eventually use the same code for agp-based dma for memory
managed drm drivers.
Now, this would overflow ramdiskA, so iommu and sg_dma are now #ifndef
SMALL_KERNEL.
ok kettenis@, marco@. SMALL_KERNEL discussions with deraadt.
|
|
|
|
Replaces pchb with amas for the AMD64 address map.
amas0 at pci0 dev 24 function 1 "AMD AMD64 0Fh Address Map" rev 0x00
Currently disabled (causing pchb to attach instead).
ok art@
|
|
enable it (I have found the code that does enable it problematic on
quite a few machines, however, that's a different issue). So provide
some code that so if the bios initialised the iommu for us, we'll use
what it gave us. Makes iommu work on a machine of todd's.
while i'm here, we don't need to scan all pci functoins to find the
hypertransport bridge. the gart is always on function 3, so just scan
for all the bridges and not iterate over the functions too.
Thanks to todd for his infinite patience while I gave him diffs that
went ``Boom!''.
|
