ansi

Fix indentation. No binary change.

free(x, 0) cleanup:
- set size argument of free()
- remove pointless if expression around free() call

ok guenther@

fairly simple sizes for free()

remove unused isa_nodefaultirq; ok kettenis, mlarkin

Add bus_dmamem_alloc_range(9) to allow drivers to allocate DMA'able memory
within a range that is more (or less) restrictive than the default range.

ok deraadt@, stsp@

bcopy -> memcpy, as in amd64

The correct place to call _bus_dmamap_sync() is after we copy data *to* the
bounce buffer and before we copy data *from* the bounce buffer. Currently
_bus_dmamap_sync() is a no-op, but keeping it #i

The correct place to call _bus_dmamap_sync() is after we copy data *to* the
bounce buffer and before we copy data *from* the bounce buffer. Currently
_bus_dmamap_sync() is a no-op, but keeping it #ifdef'ed out in the wrong
place makes no sense.

ok deraadt@, miod@

show more ...

add a size argument to free. will be used soon, but for now default to 0.
after discussions with beck deraadt kettenis.

IPL_VM is "mpsafe" now as well.

To prevent lock ordering problems with the kernel lock, we need to make sure
we block all interrupts that can grab the kernel lock. The simplest way to
achieve this is to make sure mutexes always ra

To prevent lock ordering problems with the kernel lock, we need to make sure
we block all interrupts that can grab the kernel lock. The simplest way to
achieve this is to make sure mutexes always raise the ipl to the highest
level that has interrupts that grab the kernel lock. This will allow us
to have "mpsafe" interrupt handlers at lower priority levels.

No change for non-MULTIPROCESSOR kernels.

ok matthew@

show more ...

Implement a mechanism to establish interrupt handlers that don't grab the
kernel lock upon entry through a new IPL_MPSAFE flag/level.

More than a decade ago, interrupt handlers on sparc started returning 0
(interrupt was not for me), 1 (positive interrupt was for me), or -1
(i am not sure...). We have continued with this practice

More than a decade ago, interrupt handlers on sparc started returning 0
(interrupt was not for me), 1 (positive interrupt was for me), or -1
(i am not sure...). We have continued with this practice in as many
drivers as possible, throughout the tree.

This makes some of the architectures use that information in their
interrupt handler calling code -- if 1 is returned (and we know
this specific machine does not have edge-shared interrupts), we
finish servicing other possible handlers on the same pin. If the
interrupt pin remains asserted (from a different device), we will
end up back in the interrupt servicing code of course... but this is
cheaper than calling all the chained interrupts on a pin.

This does of course count on shared level interrupts being properly
sorted by IPL.

There have been some concerns about starvation of drivers which
incorrectly return 1. Those drivers should be hunted down so that
they return -1.

ok and help from various people. In snaps for about a week now.

show more ...

typo

Get rid of evcount's support for arranging counters in a tree
hierarchy. Everything attached to a single root node anyway, so at
best we had a bush.

"i think it is good" deraadt@

Make the i386 and amd64 bus_dma functions for isa less stupid:

1) when you have a wrapper function in a dmatag that just calls the
_bus_dmamem original, you don't need it, just put the original func

Make the i386 and amd64 bus_dma functions for isa less stupid:

1) when you have a wrapper function in a dmatag that just calls the
_bus_dmamem original, you don't need it, just put the original function
in the tag

2) don't trunc_page the avail_end/ISA_BOUNCE_THRESHOLD stuff (see icb
for a discussion of why this is wrong about 00:00 gmt). make i386 and
amd64 both do this the same (the amd64 way is cleaner and makes the
third diff actually possible without a lot of pain). just do
dmamem_alloc_range(0, threshold) and if that fails do a alloc_range(0,
-1) and assume we'll bounce to pick up the pieces. Also using avail_end
for alloc_range is not nice (miod has been trying to avoid these abuses
iirc), so just use (paddr_t)-1, which is equivalent since you want "any"
memory.

3) now this is the funny one. consider point 2. then considering why
using the same bloody function to allocate your bouncebuffer is just
f'ing wrong. instead allocate with alloc_range(0, threshold) to make
sure that our bouncebuffer is actually uner 16megs.

ok deraadt@, kettenis@. Tested by several people.

show more ...

Constify the what/name parameter of pci_intr_establish().

Tested by myself, sthen, oga, kettenis, and jasper.
Input from sthen and jasper.

ok kettenis

(Manpage follows shortly.)

remove the _BUS_DMA_PRIVATE define from amd64 and i386.

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.

remove the _BUS_DMA_PRIVATE define from amd64 and i386.

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@

show more ...

Kill the $ARCH prefix for isa_dma_cookie. With this change, the i386 and
amd64 isa dma code is identical save for some formatting, and a slight
difference in bus_dmamem_alloc.

"Die x86_!" krw@.

both x86 platforms isa bus_dma implementations handle bus_dmamap_sync
incorrectly.

The spec (manpage) states that using two PRE or two POST ops together is
entirely valid, but mixing pre and post is

both x86 platforms isa bus_dma implementations handle bus_dmamap_sync
incorrectly.

The spec (manpage) states that using two PRE or two POST ops together is
entirely valid, but mixing pre and post is invalid. The way this was
handled before with a switch statement meant that only individual
commands actually would be recognised, so move to just checking the
commands indidually using "if (op & $command)". Additionally, add a
DIAGNOSTIC check and panic for the mixing of pre and post operations
(this is done on several other architectures already).

tested by several people; thanks!

ok dlg@, kettenis@, "the diff made sense" deraadt.

show more ...

Remove the x86 and i386 prefixes to the bus_dma types. It's really quite
pointless and just makes the code different for no reason. This moves i386 and
amd64 bus_dma to being a lot closer to identica

Remove the x86 and i386 prefixes to the bus_dma types. It's really quite
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@

show more ...

First pass at removing clauses 3 and 4 from NetBSD licenses.

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 t

First pass at removing clauses 3 and 4 from NetBSD licenses.

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@

show more ...

Remove softast; it's no longer used.

ok krw@

Use M_ZERO in a few more places to shave bytes from the kernel.

eyeballed and ok dlg@

Remove a duplicate copyright statement.