| Age | Commit message (Collapse) | Author |
|---|
|
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!''.
|
|
bus address space. Fixes a problem reported by david@.
|
|
based on the BIOS memory map.
|
|
processors, so the registers to configure addition HyperTransport links
are absent. Don't try attaching addition pci busses on these processors
to avoid probing non-existant registers.
|
|
SiS chipset that we'll never see on and amd64 machine.
ok oga@
|
|
|
|
|
|
11h (Turion) still needs testing, so isn't part of this commit.
ok reyk@, marco@
|
|
Firstly, don't keep identical data for each of the GARTs (we keep them
in sync, but there is one per cpu socket), all that varies is the
pci_tag_t, so just keep an array of those and have the rest of the
information once.
Secondly, don't keep the softc as a global, use the _cookie field of the
dmatag_t, that's what it's there for.
Finally, use dmamap_map to map the page tables, instead of the direct NC
map. This is because later changes to support PAT will be a lot easier
with one direct map (where we change the cacheability if needed), since
otherwise it's just asking for illegal cache aliases.
More changes will be upcoming.
Tested by a few people, with an without bigmem, thanks to those.
weingart@ liked the direction this is going, marco@ and kettenis@ oked it.
|
|
a define needed to get to ``private'' functions that needs to be defined
5 or more times isn't much use and may cause namespace issues anyway.
Other archs will probably follow.
Discussed in portugal. "Hell yes" weingart@, ok kettenis@, no
objections miod@
|
|
mutex with ipl set to IPL_HIGH. While i'm here, unify the code with
i386, by giving the same lock to the i386 code.
This lock is mostly for MP, but could actually prevent a race where a
process is doing pci_conf_{read,write}, and then an interrupt fire and
also does pci_conf_{read,write}. Since this is a two stage process, the
interrupt could race with the one, causing the value to the written to
the wrong place, or the wrong value to be written.
Tested by many. "go ahead" kettenis@.
|
|
#ifdef __i386__ code that can go now things have been cleaned up.
|
|
pick a new one from the list of possible routings if it isn't or if a pin is
currently not routed. Delay re-routing interrupts until we establish a
handler for it. This prevents us from messing with unused interrupt pins
which may have fatal consequences (some machines spontaniously reboot).
The heuristics for picking an interrupt from the list of possibe ones
probably needs some tweaking still, but this makes several NVIDIA-based
boards work much better than before.
tested by many, ok marco@
|
|
and even then it didn't work. we have higher standards than this.
|
|
|
|
pointless and just makes the code different for no reason. This moves i386 and
amd64 bus_dma to being a lot closer to identical.
suggestion to just remove the prefix instead of merge them from deraadt@.
no objections art@, kettenis@, ok weingart@
|
|
tag and pin. Reduces the differences between the two architectures and I need
it to fix acpiprt(4)-based interrupt routing.
ok toby@, jordan@
|
|
previously, we had a static list of pcidevs and which agp driver would
be interanlly attached. Instead, split the agp drivers so they work like
audio(4), where we attach a driver, which sets up some callbacks and
initial state, then attaches the interface (agp(4)). Since this allows
us to attach different drivers in different places, and give them
/proper/ probe functions move most of the drivers back to attaching at
pchb, where they should, and intagp (formerly agp_i810) stays attaching
at vga, since it's part of the intel integrated graphics chips.
Diff shrinks the kernel slightly, gets rid of the annoying "no integrated
graphics" warning, and allows more cleanup later.
Tested by many. fix for alpha build (the only other vga_pci.c consumer)
suggested by miod.
|
|
Tested on ASUS P5E-VM DO motherboard.
ok oga
|
|
ok jsg@
|
|
Not sure what's more surprising: how long it took for NetBSD to
catch up to the rest of the BSDs (including UCB), or the amount of
code that NetBSD has claimed for itself without attributing to the
actual authors.
OK deraadt@
|
|
Initial information, half the diff, and testing from Andrew Lutomirski,
thanks!
|
|
with 10h and 11h families of AMD CPU's.
ok kettenis@
|
|
|
|
|
|
seems silly to have a seperate .h file for 4 defines.
nuke the NetBSD __KERNEL_RCSID macro while there, we have that
rcsid at the top of the file...
ok toby@, brad@
|
|
Tested on i386 with a Gigabyte G33M-DS2R motherboard (Intel GMA 3100).
Based on NetBSD code.
ok oga@
|
