| Age | Commit message (Collapse) | Author |
|---|
|
so remove the former and include the latter instead of pulling it
in <dev/pci/agpvar.h>. This header already requires various other
types anyway. While here remove unneeded headers.
|
|
all by itself.
|
|
inteldrm(4) manages the GTT by itself.
ok miod@
|
|
kernel resumes normal (non-cold, able to run processes, etc) operation.
Previously we were relying on specific DVACT_RESUME op's in drivers
creating callback/threads themselves, but that has become too common,
indicating the need for a built-in mechanism.
ok dlg kettenis, tested by a sufficient amount of people
|
|
for PCI devices. This hook should be called twice, before and after
changing the power state of a PCI device.
Before setting the device to the new state, the ACPI layer will notify
every power resources linked to the device for that state and make sure
they are turned "_ON". After changing the state of the device, it will
decrement the reference of every power resources linked to that device
for the old state and turn them "_OFF" if they are no longer referenced.
This fixes the no-USB after resume problem seen on various ThinkPad,
problem initialy diagnosed with Alexander Polakov.
ok kettenis@, deraadt@
|
|
is should return D3. It should return the current power state.
ok kettenis mlarkin
|
|
cleaning up some shutdown-hook related code on the way.
(A few drivers related to sparc are still skipped at kettenis' request)
ok kettenis mlarkin, tested by many others too
|
|
support to reload bindings after suspend/resume and to update cachability
flags in the address translation table entries.
|
|
ok guenther millert kettenis
|
|
but reserve everything above 36 bits so that the erroneous extent
allocation will fail but not panic the system. Fixes the notorious
IBM x3100 panic where one of the PCI BARs is programmed with an
incorrect 64 bit address.
Idea and OK kettenis@, tested by Walter Souza, thanks!
|
|
paths are reflexive. It is now possible to fail part-way through a
suspend sequence, and recover along the resume code path.
Split DVACT_SUSPEND by adding a new DVACT_POWERDOWN method is used
after hibernate (and suspend too) to finish the job. Some drivers
must be converted at the same time to use this instead of shutdown hooks
(the others will follow at a later time)
ok kettenis mlarkin
|
|
|
|
|
|
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@
|
