Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

MFC r265102:
Fix one cases of recursive acquisitions of the vm object lock, only
possible in rare failure situations. The second part of r265102 is
not applicable to stable/9 since vm_page_insert() cannot fail there.

MFC 219886, 226100, 226111, 226341, 242529, 259015, 259016, 259019, 259049,
259071, 259102, 259110, 259129, 259130, 259178, 259179, 259203, 259221,
259261, 259532, 259615, 259650, 259651, 259667, 259680, 259727, 259761,
259772, 259776, 259777, 259830, 259882, 259915, 260160, 260449, 260450,
260688, 260888, 260953, 261269, 261547, 261551, 261552, 261553, 261585
o Merge vt(4) virtual terminal (a.k.a. newcons) to stable/9.
o Merge teken updates.
o Add few more tty methods required by vt(4).
o Update syscons(4) to work with fresh teken.

Sponsored by: The FreeBSD Foundation

MFC changes to atomic.h usage in DRM code

This commit follows the merge of atomic.h changes in r262807 and r262823.
The original work is from Jung-uk Kim (jkim@).

The following revisions were merged in this single commit:

r255009:
Fix a compiler warning. With this fix, a negative time can be converted to
a struct timeval and back to the original nanoseconds correctly.

r255012:
Fix a compiler warning and add couple of VM map types.

r255013:
Correct atomic operations in i915.

r255037:
Fix atomic operations on context_flag without altering semantics.

r255039:
- Remove test_and_set_bit() macro. It is unused since r255037.
- Relax atomic_read() and atomic_set() macros. Linux does not require any
memory barrier. Also, these macros may be even reordered or optimized away
according to the API documentation:

https://www.kernel.org/doc/Documentation/atomic_ops.txt

r255041:
Clarify confusions between atomic_t and bitmap. Fix bitmap operations
accordingly.

r255042:
Fix the incomplete conversion from atomic_t to long for test_bit().

r255044:
Partially revert r254880. The bitmap operations actually use long type now.

r255045:
'u_long' is consistently spelled 'unsigned long' in this file. Fix it.

MFC r254818:

drm: Move definition of EREMOTEIO to drmP.h

It will be used by both i915 and radeon drivers.

Add ERESTARTSYS definition at the same time.

MFC r254797:

drm: Const'ify the 1st "drm_display_mode" passed to "mode_fixup" callbacks

This will be needed by the Radeon KMS driver.

MFC r254796:

drm/i915: Import Linux commit 71244653a8fb0f46bc12ae421f1d5f72af6a75da

Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jun 4 18:39:20 2012 +0200

drm/i915: adjusted_mode->clock in the dp mode_fixup

... instead of changing mode->clock, which we should leave as-is.

After the previous patch we only touch that if it's a panel, and then
adjusted mode->clock equals adjusted_mode->clock. Outside of
intel_dp.c we only use ajusted_mode->clock in the mode_set functions.

Within intel_dp.c we only use it to calculate the dp dithering
and link bw parameters, so that's the only thing we need to fix
up.

As a temporary ugliness (until the cleanup in the next patch) we
pass the adjusted_mode into dp_dither for both parameters (because
that one still looks at mode->clock).

Note that we do overwrite adjusted_mode->clock with the selected dp
link clock, but that only happens after we've calculated everything we
need based on the dotclock of the adjusted output configuration.

Outside of intel_dp.c only intel_display.c uses adjusted_mode->clock,
and that stays the same after this patch (still equals the selected dp
link clock). intel_display.c also needs the actual dotclock (as
target_clock), but that has been fixed up in the previous patch.

v2: Adjust the debug message to also use adjusted_mode->clock.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

MFC r249041, r249249:

drm and i915: Left-shift iic_msg.slave at creation time

This is required because, in the radeon driver, we can't left-shift in a
central place, like it was done in the i915 driver.

Reviewed by: kib@, kan@, avg@
Tested by: kib@, avg@,
Olivier Cochard-Labbé <olivier@cochard.me>

MFC 253471,253620,254430,254538:
Change mmap() to more optimally use superpages and provide support for
tweaking alignment of virtual mappings.
- Add a new address space allocation method (VMFS_OPTIMAL_SPACE) for
vm_map_find() that will try to alter the alignment of a mapping to match
any existing superpage mappings of the object being mapped. If no
suitable address range is found with the necessary alignment,
vm_map_find() will fall back to using the simple first-fit strategy
(VMFS_ANY_SPACE).
- Change mmap() without MAP_FIXED, shmat(), shm_map(), and the GEM mapping
ioctl to use VMFS_OPTIMAL_SPACE instead of VMFS_ANY_SPACE.
- MAP_ALIGNED(n) requests a mapping aligned on a boundary of (1 << n).
Requests for n >= number of bits in a pointer or less than the size of
a page fail with EINVAL. This matches the API provided by NetBSD.
- MAP_ALIGNED_SUPER is a special case of MAP_ALIGNED. It can be used
to optimize the chances of using large pages. By default it will align
the mapping on a large page boundary (the system is free to choose any
large page size to align to that seems best for the mapping request).
However, if the object being mapped is already using large pages, then
it will align the virtual mapping to match the existing large pages in
the object instead.
- Internally, VMFS_ALIGNED_SPACE is now renamed to VMFS_SUPER_SPACE, and
VMFS_ALIGNED_SPACE(n) is repurposed for specifying a specific alignment.
MAP_ALIGNED(n) maps to using VMFS_ALIGNED_SPACE(n), while
MAP_ALIGNED_SUPER maps to VMFS_SUPER_SPACE.
- mmap() of a device object now uses VMFS_OPTIMAL_SPACE rather than
explicitly using VMFS_SUPER_SPACE. All device objects are forced to
use a specific color on creation, so VMFS_OPTIMAL_SPACE is effectively
equivalent.

PR: ports/184173 (exp-run)

MFC r256848:
Use plain register read for waiting of the reset completion
notification, to avoid gt_lock recursion.

MFC r253709:
The pmap_qenter() and pmap_qremove() perform TLB invalidation on its
own, no need to call pmap_invalidate_range() one more time.

MFC r253497:
Use the right name for the vm_map_find(9) flag to specify shared mapping.

MFC r251961:
Disable wait for the retrace if KMS is activated.

MFC r251960:
Since the gem pagefault handler relocks the vm object lock, other
thread might fault on the same GTT offset meantime and instantiate the
mapping. Recheck that the mgt device object still does not have a
page at the current offset after relocking, and return a possibly
installed page.

MFC r251959:
Remove stray empty line.

MFC r251591:
The vm_page lock is not needed around the call to vm_page_insert().

MFC r240917:
Reduce delays in several wait loops from 10ms to 10us, same is it is done
in Linux. This substantially increases graphics performance on Ivy Bridge.

Submitted by: avg@
Reviewed by: kib@

MFC r239375:
Add drm and i915 ioctl translations for 32 bit process on 64 bit host.

MFC r237131:
Use right size when freeing unneeded GTT mapping.

MFC r236183:
Disable end of buffer fixup by default.

MFC r236182:
Fix calculation of the execution buffer end in the mapped pages
when it is spilled into the next page.

MFC r235925 (by dim):
Fix a clang warning in drm2.

MFC r235783:
Add the code for new Intel GPU driver, which supports GEM, KMS and
works with new generations of GPUs (IronLake, SandyBridge and
supposedly IvyBridge).

The driver is not connected to the build yet.

Add the code for new Intel GPU driver, which supports GEM, KMS and
works with new generations of GPUs (IronLake, SandyBridge and
supposedly IvyBridge).

The driver is not connected to the build yet.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week