| Age | Commit message (Collapse) | Author |
|---|
|
|
|
ok miod@, thib@, oga@, jsing@
|
|
pmap_{copy,zero}_page, but use direct mapped pages instead.
|
|
fix OpenBSD/sparc operation in QEMU, which only provides the frame buffer
memory and none of the accelerated stipple and blit spaces.
|
|
more to come later)
Specfically, there is no reason to reserve a special virtual address just so we
can do boot dump, we have a direct map of every page anyway.
since pmap_map is deprecated and MD only anyway, this means we can remove that
interface too. If anything this should increase reliability since pmap_enter
won't fail under memory pressure during dump (unlikely but possible). It is also
simpler and smaller ;)
Tested by myself and ckuethe, no regressions.
ok miod@
|
|
do not attach to the Gen2b devices yet as it is not clear wether or
not they have their own hardware revision type.
|
|
|
|
turns out the Rx gain tables are the same as 2.0 (and the Tx gain
registers too), which saves us a few bytes.
|
|
|
|
|
|
it's queued in the Tx FIFO.
otherwise we might end up losing the reference to the Tx buffer
if we return on error in ar{5008,9003}_tx().
cleanup some dma sync calls while i'm here.
|
|
Tested (and initial tweaked diff) from Erik Mugele; thanks!
|
|
|
|
Tested (and inital patch that I tweaked) from Erik Mugele; thanks!
|
|
This is needed because pf_state_peer_hton() skips some fields in certain
situations which could result in garbage beeing sent to the other peer.
This seems to fix the pfsync storms seen by stephan@ and so dlg owes me
a whiskey.
OK dlg@, stephan@
|
|
opposite) and on AR9380 2.0.
tested on my AR9280 2.1 with a NETGEAR WNHDE111 AP.
|
|
|
|
#ifndef IEEE80211_NO_HT for consistency.
|
|
- the ROM deviceCap field is now 8 bits (instead of 16), so the number
of entries in the key cache is always 0; just use the default value.
- AR_CR_RXE is equal to 0 on AR9003.
- do not use ``m'' unititialized in ar9003_rx_process.
- if an Rx descriptor is not valid (bad signature), skip it instead of
leaving it at the head of the FIFO.
- update the Rx software descriptor with new virtual and physical address
of Rx descritor when mapping a new buffer.
|
|
see http://marc.info/?l=linux-wireless&m=127354213505700&q=raw
for the list of changes.
|
|
OK sthen@
|
|
where it is not necessary to guess protocols by looking at the first nibble.
in_gif_output() will encapsulate the packet but not send it. Because of
etherip support and the way the bridge works a minimal hack is needed in
gif_start() to ensure that the bridged packets are encapsulated as well.
This actually started with the idea to add MPLS support but that turned out
to be not as simple as in the gre(4) case.
Tested by myself (IP, IPv6, etherip, MPLS), sthen@ (IP, IPv6), naddy (IPv6)
OK sthen@
|
|
OK sthen@
|
|
is defined.
|
|
This enabled GEM for the intel driver unconditionally. The legacy
codepaths will be removed in approximately one week since they are now
completely unused.
After discussion with matthieu@, drahn@, kettenis@ and marco@ (well,
mostly nagging from marco ;).
|
|
(reading back the relocation).
It doesn't add any real security and when we actually need to map the
buffer on demand to read/write it makes things cripplingly slow. The
correct way to make this utterly incorruptible is a radeon-kms-like
command checker to the command streams. This is on my todo list.
Thanks to drahn@ for additional testing.
|
|
Makes gcc4 happy.
ok miod@
|
|
this driver to work on machine with low kva and large apertures.
tested by myself and drahn@
|
|
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.
|
|
ok millert@
|
|
some adapters labelled RT3090 have a MAC version equal to RT3071.
still no luck receiving frames on my AzureWave AW-NE762H though :(
|
|
|
|
chips (AR9003), which differs from the currently supported
families (AR5008, AR9001 and AR9002).
The main differences (from a driver point of view) are:
* DMA:
Tx and Rx descriptors have changed.
A single Tx descriptor can now reference up to 4 scatter/gather
DMA segments.
There is now a DMA ring for reporting Tx status with separate
Tx status descriptors (this ring is used to report Tx status for
all the Tx FIFOs).
Rx status descriptors are now put at the beginning of Rx buffers
and do not need to be allocated separately from buffers.
There are two Rx FIFOs (low priority and high priority) instead
of one.
* ROM:
The AR9003 family uses OTP-ROM instead of EEPROM.
Reading the ROM is totally insane since vendors can provide only
the chunks of ROM that differ from a default image (and thus the
default image has to be stored in the driver).
This is referenced as "compressed ROM" in the Linux driver, though
there is no real compression involved, at least for the moment.
* PHY registers:
All PHY registers have changed.
Some registers offsets do not fit on 16 bits anymore, but
since they are 32-bit aligned, we can still make them fit on
16 bits to save .rodata space in initialization tables.
* MAC registers:
Some MAC registers offsets have changed (GPIO, interrupt masks)
which is quite annoying (though ~98% remain the same.)
* Initialization values:
Initialization values are now split in mac/soc/bb/radio blocks
and pre/core/post phases in the Linux driver. I have chosen to
not go that road and merge these blocks in modal and non-modal
initialization values (similar to the other families).
The initialization order remains exactly the same as the Linux
driver though.
To manage these differences, I have split athn.c in two backends:
ar5008.c contains the bits that are specific to the AR5008,
AR9001 and AR9002 families (used by ar5416.c, ar9280.c,
ar9285.c and ar9287.c) and that were previously in athn.c.
ar9003.c contains the bits that are specific to the new
AR9003 family (used by ar9380.c only for now.)
I have introduced a thin hardware abstraction layer (actually
a set of pointers to functions) that is used in athn.c.
My intent is to keep this abstraction layer as thin as possible
and not to create another ugly pile of abstraction layers a la
MadWifi.
I think I've managed to keep things sane, probably at the expense
of duplicating some code in both ar5008.c and ar9003.c, but at
least we do not have to dig through layers and layers of virtual
descriptors to figure out what is mapped to the hardware.
Tested for non-regression on various AR5416 (sparc64+i386), AR9281
and AR9285 (i386 only) adapters.
AR9380 part is not tested (hardware is not available to the general
public yet).
Committed over my AR9285 2.0.
|
|
'possibility', 'optins' -> 'options', 'resposne' -> 'response', 'unecessary' -> 'unnecessary', 'desination' -> 'destination'. Collected from various misc@
and tech@ postings, many by Brad Tilley.
|
|
but i suspect it is common to all SPI mpi parts.
problem found and problem diff verified by landry.
ok krw@ landry@ jasper@
|
|
code is derived and makes gcc4 happy by avoiding a conflict with the builtin
for the standard C99 round(3).
ok miod@
|
|
|
|
code is derived and makes gcc4 happy by avoiding a conflict with the builtin
for the standard C99 round(3).
ok miod@
|
|
it static here. Makes gcc4 happier.
|
|
ok jsg
|
|
Tested by Jan Stary; thanks!
|
|
Tested by Jan Stary, thanks!
|
|
a (missing) second serial port to ioc(4), read spdmem(4) records from the
right index, and query the Ethernet address from the I-Brick eeprom instead
of the C-Brick eeprom.
Tested by Sebastian Reitenbach, thanks!
|
|
on the bus, to workaround timeout problems, according to IRIX knowledge which
made its way to Linux.
|
|
bit before we enter a signal handler.
"if you say so" miod@, "seems to make sense" jsing@
|
|
the syscall gateway page, which doesn't work since that page is shared
between processes, this makes us step over that bit by setting a breakpoint
on the instruction where the system call returns.
ok miod@, jsing@
|
|
ok miod@
|
|
as suggested by miod.
ok miod@
|
|
|
|
the weird "pass by reference" that causes problems with gcc4.
ok nicm@, tom@
|
