Unbreak ia64 tinderbox: 64-bit support was made conditional upon
__amd64__, and thus limited. Eliminate 2 trivial conditionals by
casting the 64-bit integral, holding an address, via (uintptr_t)
to (void *) and replace the last remaining check for __amd64__
with a check for __LP64__ instead.
Migrate ath(4) to now use if_transmit instead of the legacy if_start
and if queue mechanism; also fix up (non-11n) TX fragment handling.

This may result in a bit of a performance drop for now but I plan on
debugging and resolving this at a later stage.

Whilst here, fix the transmit path so fragment transmission works.

The TX fragmentation handling is a bit more special.  In order to
correctly transmit TX fragments, there's a bunch of corner cases that
need to be handled:

* They must be transmitted back to back, in the same order..
* .. ie, you need to hold the TX lock whilst transmitting this
  set of fragments rather than interleaving it with other MSDUs
  destined to other nodes;
* The length of the next fragment is required when transmitting, in
  order to correctly set the NAV field in the current frame to the
  length of the next frame; which requires ..
* .. that we know the transmit duration of the next frame, which ..
* .. requires us to set the rate of all fragments to the same length,
  or make the decision up-front, etc.

To facilitate this, I've added a new ath_buf field to describe the
length of the next fragment.  This avoids having to keep the mbuf
chain together.  This used to work before my 11n TX path work because
the ath_tx_start() routine would be handed a single mbuf with m_nextpkt
pointing to the next frame, and that would be maintained all the way
up to when the duration calculation was done.  This doesn't hold
true any longer - the actual queuing may occur at any point in the
future (think ath_node TID software queuing) so this information
needs to be maintained.

Right now this does work for non-11n frames but it doesn't at all
enforce the same rate control decision for all frames in the fragment.
I plan on fixing this in a followup commit.

RTS/CTS has the same issue, I'll look at fixing this in a subsequent
commit.

Finaly, 11n fragment support requires the driver to have fully
decided what the rate scenario setup is - including 20/40MHz,
short/long GI, STBC, LDPC, number of streams, etc.  Right now that
decision is (currently) made _after_ the NAV field value is updated.
I'll fix all of this in subsequent commits.

Tested:

* AR5416, STA, transmitting 11abg fragments
* AR5416, STA, 11n fragments work but the NAV field is incorrect for
  the reasons above.

TODO:

* It would be nice to be able to queue mbufs per-node and per-TID so
  we can only queue ath_buf entries when it's time to assemble frames
  to send to the hardware.

  But honestly, we should just do that level of software queue management
  in net80211 rather than ath(4), so I'm going to leave this alone for now.

* More thorough AP, mesh and adhoc testing.

* Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has
  been negotiated, as we can't do software retransmission of fragments.

* .. set CLRDMASK when transmitting fragments, just to ensure.
Add clock definitions for LCD controller and PWM module
Add SCM registers definitions for AM335x platform
Add PWM module driver for AM335x. Only eCAS subsystem is supported

Export function to configure eCAS submodule from another drivers.
It's used to control LCD panel backlight on AM335x EVM.
AM335x LCD controller driver with syscons support

Limitations:
- Raster mode only
- 24 and 32 bpp only
Add PWM and LCDC nodes to base DTS for AM335x-based devices
Add DTS for AM335x EVM with properly muxed PWM and LCD pins, and
LCD panel description
Fix ONFI chip detection.

Submitted by:	Alexander Fedorov <alexander.fedorov@rtlservice.com>
Workaround for for a problem seen with ATI Technologies EHCI
controller hardware most likely present on UHCI chipsets aswell. The
bug manifests itself when issuing isochronous transfers and bulk
transfers towards the same device simultaneously. From time to time it
happens that either the completion IRQ was missing or that the
completion IRQ was happening before the ITD/SITD was completely
written back to memory. The workaround assumes that double buffered
isochronous transfers are used, and that a second interrupt is
generated at the beginning of the next isochronous transfer to
complete the previous one. Possibly skipping the interrupt at the last
isochronous frame is possible, but will then break single buffered
isochronous transfers. For now we can live with some extra interrupts.

MFC after:	1 week
Fix some regressions caused by the switch from gcc to clang. The fixes
are workarounds for various symptoms of the problem described in clang
bugs 3929, 8100, 8241, 10409, and 12958.

The regression tests did their job: they failed, someone brought it
up on the mailing lists, and then the issue got ignored for 6 months.
Oops. There may still be some regressions for functions we don't have
test coverage for yet.
When handling an exception from the attempt from loading the faulting
context on return from the trap handler, re-enable the interrupts on
i386 and amd64.  The trap return path have to disable interrupts since
the sequence of loading the machine state is not atomic.  The trap()
function which transfers the control to the special handler would
enable the interrupt, but an iret loads the previous eflags with PSL_I
clear.  Then, the special handler calls trap() on its own, which now
sees the original eflags with PSL_I set and does not enable
interrupts.

The end result is that signal delivery and process exiting code could
be executed with interrupts disabled, which is generally wrong and
triggers several assertions.

For amd64, the interrupts are enabled conditionally based on PSL_I in
the eflags of the outer frame, as it is already done for
doreti_iret_fault.  For i386, the interrupts are enabled
unconditionally, the ast loop could have opened a window with
interrupts enabled just before the iret anyway.

Reported and tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
When reporting the fault details, also print %rsp.

Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
The ia32_get_mcontext() does not need to set PCB_FULL_IRET.  The
usermode context state is not changed by the get operation, and
get_mcontext() does not require full iret as well.

Tested by:	dim, pgj
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
The _MC_HASFPXSTATE and _MC_IA32_HASFPXSTATE flags have the same bit
value on purpose, but the ia32 context handling code is logically more
correct to use the _MC_IA32_HASFPXSTATE name for the flag.

Tested by:	dim, pgj
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Use slightly more idiomatic expression to get the address of array.

Tested by:	dim, pgj
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Partially apply the capitalization of the heading word of the sequence
and fix typo.

Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
* Update polynomial coefficients.
* Use ENTERI/RETURNI to allow the use of FP_PE on i386 target.

Reviewed by:	das (and bde a long time ago)
Approved by:	das (mentor)
Obtained from:	bde (polynomial coefficients)
cap_rights_limit(2): CAP_ACCEPT also permits accept4(2).
Change the closeallfds() routine to use closefrom() when it is
available (closefrom() was added to FreeBSD in 8.0-release).
The selection is made at compile-time, as I still compile a
FreeBSD-based version of lpr&friends on other platforms.

While testing I out that (at least on my system) lpd has been
closing 11095 fd's, when there are only 6 fd's open.  The old
code took 120 times more clocktime than calling closefrom().
(although that was still less than 2/1000-ths of a second!)

Reviewed by:	jilles
MFC after:	2 weeks