| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
okay millert@, nicm@ ...
(thx others for pointing out stupidity in intermediate patches...)
|
|
ok oga kettenis
committed in the skys over the continental us :-)
|
|
|
|
and then, we can have a default facet when locales are not
defined.
(this lets std::istringstream work again)
|
|
|
|
|
|
|
|
ok millert
|
|
'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.
|
|
requested sample rate, scale the block/buffer sizes so the block/
buffer sizes the hardware will use are the same amount of *time*
as the requested block/buffer sizes.
ok ratchov@
|
|
|
|
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@
|
|
|
|
is only referenced from inline asm.
ok jsg@
|
|
ok miod@
|
|
as suggested by miod.
ok miod@
|
|
pointer deref if we actually went through this code path (reload, does
not work yet so it is disabled)
|
|
devio.us.
ok jmc
|
|
|
|
|
|
|
|
|
|
but this makes things less painful for people for the time being.
ok kettenis@ robert@
|
|
|
|
Based on dale's idea.
(please install this file now, so you won't get errors when we commit the
rest).
|
|
the weird "pass by reference" that causes problems with gcc4.
ok nicm@, tom@
|
|
functions in our libc and continues to provide the function name to
__stack_smash_handler().
ok miod@
|
|
|
|
ok kettenis@
|
|
builtin atomic operations.
ok robert@
|
|
Apparently gcc4 uses them in cases where gcc3 didn't. Fixes segmentation
faults with gcc4 because the space for the slots was colliding with
the space for dl_data that we allocated on the stack.
ok miod@
|
|
|
|
with a VIA 686 southbridge.
Features:
- 686 setup code (no thanks to PMON for not initializing the beast).
- work in progress ISA interrupt handling code.
- support for vga(4) compatible devices as console, in PC-compatible text mode.
- move legacy (ISA) support code out of bonito(4) to make things clearer.
- support more than 256MB on 2E-based systems.
Tested on a generic 2E-based evaluation board by someone who wishes to remain
anonymous; you know who you are, thank you very much for testing.
|
|
numbers are a PITA in the long run; from NetBSD.
|
|
If userland asks to allocate an object large enough that two that size
could not fit around the pinned objects, disallow it with EFBIG.
This prevents mmap of large objects that big and copying between them
putting the machine into infinite thrashing. with a patch to the ddx (on
my git branch) that allocates a non-accelerated pixmap when it gets that
return code, matthieu@s test huge image works happily when before it
DOSed the kernel.
The correct fix would be to fall back to mmaping the backing pages for
objects that big (radeondrm will need such ability anyway). This however
is a lot more complicated and I am still working out how to do it
correctly hence this commit for now.
|
