routines. The arguments are commented out. The #defininitions
are a temporary measure that will help me commit changes to the
device suspend/resume/detach methods in my the tree piecemeal,
instead of all at once.
allocated by the AGP driver in the case of Intel chipset graphics.
This is different from the patch by Yorick Hardy circulated a while ago
in that it doesn't change the semantics of reference counting within
the (3rd-party) DRM code -- it just bypasses it.
Needless to say that it is uglier, but it eases future updates to
the DRM code because the change there is just 2 LOC.
Imo, a cleaner solution for all that would be to attach "agp" to "vga"
in the intel chipset graphics case, which better reflects how the hardware
is structured. This would still need a hack to the DRM code, but
it would be confined to childs of the "vga" device, without need for
global variables.
Since there is a variety of intel chipsets with AGP and/or builtin
graphics options, this would need a considerable testing effort.
implementations based on the suggestions I made for DragonFly's libc
ages ago. For charset with more than one entry and iterating over the
first two characters of s, this is consistently faster on amd64.
Use a field in the pcb itself (since it's basically free) and keep track of
what pmap "owns" a pcb (for consistency checking). use M_ZERO as appropriate.
-use an aligned pci config space address as everyone else -- I'm sorry
about that because I like gson's way a lot -- it keeps the address
offset due to alignment visually close to the data shift --, but since
aligned addresses are used everywhere else in definitions, this
causes confusion
-the mask applied to the data didn't make much sense, a look at the
FreeBSD code where this code originates from suggests that there
was just a mistake -- one trailing zero missing --
anyway, the datasheet tells that the error bits are all write-one-
to-clear, so just write back the value and we are done
are switched to (was harmless because we don't do D2 yet and also
don't (hmm - shouldn't) access devices in D3 (which would only make
sense if we'd support D3hot)
-zero the io/mem/master enable bits before entering D3
(The special handling of PCI_CLASS_DISPLAY devices is questionable
here -- we can't care about the console if we are seriously follow
the spec, and upstream bridges aren't considered anyway.)
-add exact references to the PCI PM spec
the pmf API can't deal with all the different suspend/resume/reboot
cases well yet, so better keep suspend/resume and reboot/halt/poweroff
clearly seperated
BSD Lisc as part of the perflib project.
http://sourceforge.net/projects/ppcperflib/
Tested the new functions with microbenchmarks on a number of different
CPU types, and found that most cpus either benefited greatly, or were
unaffected. Primarily G4 CPU's were unaffected, and all others showed
speedups. My 7044 (POWER3) went from a 70.6 to a 73.2 (thats good) in
bytebench with a complete release built with these. Also passed
regression tests.
- atomic_cas_ni() does an implicit membar_exit()
- all other atomic operations do an implicit membar_sync()
While this might seem kind of arbitrary it's the basis for some important
optimizations.
dyoung