Commit Graph

13 Commits

Author SHA1 Message Date
Adrian Chadd
46634305f4 Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.
The existing API only exposes 'seglen' (the current buffer (segment) length)
with the data buffer pointer set in 'ds_data'.  This is fine for the legacy
DMA engine but it won't work for the EDMA engines.

The EDMA engine has a significantly different TX descriptor layout.

* The legacy DMA engine had a ds_data pointer at the same offset in the
  descriptor for both TX and RX buffers;
* The EDMA engine has no ds_data for RX - the data is DMAed after the
  descriptor;
* The EDMA engine has support for 4 TX buffer/segment pairs in the TX
  DMA descriptor;
* The EDMA TX completion is in a different FIFO, and the driver will
  'link' the status completion entry to a QCU by a "QCU ID".
  I don't know why it's just not filled in by the hardware, alas.

So given that, here are the changes:

* Instead of directly fondling 'ds_data' in ath_desc, change the
  ath_hal_filltxdesc() to take an array of buffer pointers as well
  as segment len pointers;
* The EDMA TX completion status wants a descriptor and queue id.
  This (for now) uses bf_state.bfs_txq and will extract the hardware QCU
  ID from that.
* .. and this is ugly and wasteful; it should change to just store
  the QCU in the bf_state and save 3/7 bytes in the process.

Now, the weird crap:

* The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than
  taking a function argument.  I've tidied that up.
* The multicast queue frames get put on a software TXQ and then that is
  appended to the hardware CABQ when appropriate.  So for now, make sure
  that bf_state->bfs_txq points at the CABQ when adding frames to the
  multicast queue.
* .. but the multicast queue TX path for now doesn't use the software
  queue and instead
  (a) directly sets up the descriptor contents at that point;
  (b) the frames on the vap->avp_mcastq are then just appended wholesale
      to the CABQ.
  So for now, I don't have to worry about making the multicast path
  work with aggregation or the per-TID software queue. Phew.

What's left to do:

* I need to modify the 11n ath_hal_chaintxdesc() API to do the same.
  I'll do that in a subsequent commit.
* Remove bf_state.bfs_txq entirely and store the QCU as appropriate.
* .. then do the runtime "is this going on the right HWQ?" checks using
  that, rather than comparing pointer values.

Tested on:

* AR9280 STA/AP
* AR5416 STA/AP
2012-08-05 10:12:27 +00:00
Adrian Chadd
85f6107b86 Add OS_MEMCMP(). 2012-07-01 02:37:04 +00:00
Adrian Chadd
f13112ff78 Add placeholder methods for WMI command access (USB, perhaps SDIO later)
which will be needed for AR7010 and AR9287 USB access.

The names differ slightly from Linux and Atheros, for the sake of
consistency.

A lot more work is required in order to convert the 11n HAL support to
fully support USB.
2012-04-25 01:42:22 +00:00
Adrian Chadd
36e9589ef3 Add a note that explains what the current state of the register byte order
macros are.
2012-04-25 01:24:39 +00:00
Adrian Chadd
a47f39da1f Stop using the hardware register value byte order swapping for now,
at least until I can root cause what's going on.

The only platform I've seen this on is the AR9220 when attached to
the AR71xx CPUs.  I get immediate PCIe bus errors and all subsequent
accesses cause further MIPS bus exceptions.  I don't have any other
big-endian platforms to test this on.

If I get a chance (or two), I'll try to whack this on a bus analyser
and see exactly what happens.

I'd rather leave this on, especially for slower, embedded platforms.
But the #ifdef hell is something I'm trying to avoid.
2012-04-19 03:26:21 +00:00
Sam Leffler
69ad6b3450 Fix AR5416 and later parts when building with AH_DEBUG or similar defined:
always define OS_REG_UNSWAPPED and use it in ath_hal_reg_{read,write}.

Approved by:	re (kib)
2009-07-06 20:51:54 +00:00
Sam Leffler
b4307a77d2 kill more portability functions that are no longer useful 2009-05-08 00:23:00 +00:00
Sam Leffler
8ab663f305 kill unused OS_GETUPTIME 2009-05-08 00:15:27 +00:00
Sam Leffler
3364462355 Switch to ath hal source code. Note this removes the ath_hal
module; the ath module now brings in the hal support.  Kernel
config files are almost backwards compatible; supplying

device ath_hal

gives you the same chip support that the binary hal did but you
must also include

options AH_SUPPORT_AR5416

to enable the extended format descriptors used by 11n parts.
It is now possible to control the chip support included in a
build by specifying exactly which chips are to be supported
in the config file; consult ath_hal(4) for information.
2008-12-01 16:53:01 +00:00
Sam Leffler
faaedb30ca 5416 and similar chips grew another region in the pci clock domain
where register accesses do not pass through the byte-lane hardware;
extend the register op macros to deal with this

MFC after:	1 week
2008-05-31 22:44:06 +00:00
Sam Leffler
b032f27c36 Multi-bss (aka vap) support for 802.11 devices.
Note this includes changes to all drivers and moves some device firmware
loading to use firmware(9) and a separate module (e.g. ral).  Also there
no longer are separate wlan_scan* modules; this functionality is now
bundled into the wlan module.

Supported by:	Hobnob and Marvell
Reviewed by:	many
Obtained from:	Atheros (some bits)
2008-04-20 20:35:46 +00:00
Sam Leffler
515d617e8d update copyrights to 2007 and convert to be 2-clause bsd-only 2007-06-06 15:49:16 +00:00
Sam Leffler
3fe92528af o move ath hal os glue code from the hal to the driver: this code was
part of the hal distribution early on when the hal was built for
  each os but it's been portable for a long time so move the os-specific
  code out (and off the vendor branch)
o correct the copyright on ah_osdep.?; it was mistakenly given a
  restricted license and not a dual-bsd/gpl license
o remove the module api definition as it was never used
o fixup include paths for move of ah_osdep.h

MFC after:	2 weeks
2006-09-18 16:49:15 +00:00