src-test2/sys/dev/fb, branch release/11.3.0

Revert r330897:

2018-03-29T02:50:57Z

This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code. Revert with prejudice. This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes. Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes. Requested by: gjb (re)

MFC r315986:

2018-03-19T07:03:02Z

Fix 3 entries in mode tables related to mono and 90-column text modes. Newer VGAs don't support any mono modes, but bugs in the tables created 2 virtual mono modes (#45 90x43 and #112 80x43) that behaved more strangely than crashing. 90-column modes are tweaked 80-column ones and also fail to work on newer VGAs. #45 did crash (hang) on some hardware.

Partial merge of the SPDX changes

2018-03-14T03:19:51Z

These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg

MFC r317196:

2017-04-27T12:12:33Z

Write-combine framebuffer writes through user-space mappings, if possible.

MFC r306555:

2016-10-19T01:35:21Z

Provide way for framebuffer driver to request mmap(2) mapping type On ARM if memattr is not overriden mmap(2) maps framebuffer memory as WBWA which means part of changes to content in userland end up in cache and appear on screen gradually as cache lines are evicted. This change adds configurable memattr that hardware fb implementation can set to get the memory mapping type it requires: - Add new flag FB_FLAG_MEMATTR that indicates that framebuffer driver overrides default memattr - Add new field fb_memattr to struct fb_info to specify requested memattr Reviewed by: ray Differential Revision: https://reviews.freebsd.org/D8064

MFC 303076,303225: Use MTX_SYSINIT for the VESA lock.

2016-08-06T23:52:09Z

303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb)

Fix NULL-dereference panic if VESA reports zero modes.

2016-05-17T19:00:09Z

MFC after: 1 week

sys/dev: minor spelling fixes.

2016-05-03T03:41:25Z

Most affect comments, very few have user-visible effects.

sys: Make use of our rounddown() macro when sys/param.h is available.

2016-04-30T14:41:18Z

No functional change.

sys/dev: extend use of the howmany() macro when available.

2016-04-26T15:03:15Z

We have a howmany() macro in the header that is convenient to re-use as it makes things easier to read.