sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

efifb: add a tunable to select the framebuffer cache attribute

Mapping the framebuffer with WC (Write Combined) memory type can, in
practice, cause some memory transactions to be rate-limited at a
f

efifb: add a tunable to select the framebuffer cache attribute

Mapping the framebuffer with WC (Write Combined) memory type can, in
practice, cause some memory transactions to be rate-limited at a
fraction of the fb write rate. WC allows one core to queue up many
globally visible write transactions, and in the process some unrelated
transactions may end up having to wait for all of the queued up PCI
writes to be flushed.

Add an hw.efifb.cache_attr tunable to allow mapping the framebuffer as
uncacheable instead. We should likely be taking a more careful approach
of checking the memory map to determine which cacheability attributes
are feasible, but the knob lets us use our historically functional
behavior while offering a convenient way to switch on a stock kernel.

The only valid values for hw.efifb.cache_attr at this time are "uc" and
"wc".

Original patch by Marc De La Gueronniere <mdelagueronniere@verisign.com>
along with previous testing.

Reviewed by: imp
MFC after: 1 week
Sponsored by: Verisign, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D17884

show more ...

pmap_unmapdev/bios: Accept a pointer instead of a vm_offset_t.

This matches the return type of pmap_mapdev/bios.

Reviewed by: kib, markj
Sponsored by: DARPA
Differential Revision: https://reviews.f

pmap_unmapdev/bios: Accept a pointer instead of a vm_offset_t.

This matches the return type of pmap_mapdev/bios.

Reviewed by: kib, markj
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D36548

show more ...

fb: Add new FBTYPE_EFIFB

Currently the type isn't set in the fbtype struct so any userland
program that call the FBIOGTYPE ioctl will think it's a FBTYPE_SUN1BW
which is far from the truth.
No app t

fb: Add new FBTYPE_EFIFB

Currently the type isn't set in the fbtype struct so any userland
program that call the FBIOGTYPE ioctl will think it's a FBTYPE_SUN1BW
which is far from the truth.
No app that I found find checks the type but at least now it's correct.

Reviewed by: emaste, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33221

show more ...

vt: export RGB offsets with FBIO_GETRGBOFFS

Add a new ioctl to vt to make it possible to export RGB offsets
set by vt drivers. This is needed to fix colors on X and Mesa
on some machines, especially

vt: export RGB offsets with FBIO_GETRGBOFFS

Add a new ioctl to vt to make it possible to export RGB offsets
set by vt drivers. This is needed to fix colors on X and Mesa
on some machines, especially on modern PowerPC64 BE ones.

With the appropriate changes in SCFB, to use this ioctl to find
out the correct RGB offsets, this fixes wrong colors on Talos II
and Blackbird, when used with their built-in video cards.

Reviewed by: alfredo
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D29000

show more ...

Remove "All Rights Reserved" from FreeBSD Foundation sys/ copyrights

These ones were unambiguous cases where the Foundation was the only
listed copyright holder (in the associated license block).

S

Remove "All Rights Reserved" from FreeBSD Foundation sys/ copyrights

These ones were unambiguous cases where the Foundation was the only
listed copyright holder (in the associated license block).

Sponsored by: The FreeBSD Foundation

show more ...

efifb,vbefb: implement vd_fini

This removes the pmap entry when switching away to e.g. drm fb.

Differential Revision: https://reviews.freebsd.org/D29020
MFC After: 1 month

efifb: vt_generate_cons_palette() takes max color, not mask

vt_generate_cons_palette() does take max values of RGB component colours, not
mask. Also we need to set info->fb_cmsize, or vt_fb_init() w

efifb: vt_generate_cons_palette() takes max color, not mask

vt_generate_cons_palette() does take max values of RGB component colours, not
mask. Also we need to set info->fb_cmsize, or vt_fb_init() will re-initialize
the info->fb_cmap.

show more ...

vt efifb: add suspend/resume calls

Using the latest NVIDIA driver, upon resuming from suspend with X
running the display remained blank. Additionally OpenGL applications
that were running triggered

vt efifb: add suspend/resume calls

Using the latest NVIDIA driver, upon resuming from suspend with X
running the display remained blank. Additionally OpenGL applications
that were running triggered a number of error messages from the NVIDIA
driver.

This occurred because the vt efifb back-end did not signal the X server
to release the display before suspending (or to re-acquire it after
resuming). The NVIDIA driver includes code for smoothly shutting down
and re-initializing the GPU, which was not getting called.

Since the NVIDIA driver doesn't currently support framebuffer devices
and vt is forced to fall back to the efifb back-end, add vd_suspend and
vd_resume members to connect the suspend/resume path. This ensures the
X server is properly able to re-initialize the display.

PR: 237050
Submitted by: Erik Kurzinger <ekurzinger@nvidia.com>
Reviewed by: markj
MFC after: 2 weeks
Event: Waterloo Hackathon 2019

show more ...

Speed up vt(4) by keeping a record of the most recently drawn character and
the foreground and background colours. In bitblt_text functions, compare
values to this cache and don't re-draw the charac

Speed up vt(4) by keeping a record of the most recently drawn character and
the foreground and background colours. In bitblt_text functions, compare
values to this cache and don't re-draw the characters if they haven't changed.
When invalidating the display, clear this cache in order to force characters
to be redrawn; also force full redraws between suspend/resume pairs since odd
artifacts can otherwise result.

When scrolling the display (which is where most time is spent within the vt
driver) this yields a significant performance improvement if most lines are
less than the width of the terminal, since this avoids re-drawing blanks on
top of blanks.

(Note that "re-drawing" here includes writing to the VGA text mode buffer; on
virtualized systems this can be extremely slow since it triggers a glyph
being rendered onto a 640x480 screen).

On a c5.4xlarge EC2 instance (with emulated text mode VGA) this cuts the time
spent in vt(4) during the kernel boot from 1200 ms to 700ms; on my laptop
(with a 3200x1800 display) the corresponding time is reduced from 970 ms down
to 155 ms.

Reviewed by: imp, cem
Approved by: re (gjb)
Relnotes: Significant speedup in vt(4) and the system boot generally.
Differential Revision: https://reviews.freebsd.org/D16723

show more ...

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

show more ...

sys: use our roundup2/rounddown2() macros when param.h is available.

rounddown2 tends to produce longer lines than the original code
and when the code has a high indentation level it was not really

sys: use our roundup2/rounddown2() macros when param.h is available.

rounddown2 tends to produce longer lines than the original code
and when the code has a high indentation level it was not really
advantageous to do the replacement.

This tries to strike a balance between readability using the macros
and flexibility of having the expressions, so not everything is
converted.

show more ...

As <machine/vm.h> is included from <vm/vm.h>, there is no need to
include it explicitly when <vm/vm.h> is already included.

Reviewed by: alc, kib
Differential Revision: https://reviews.freebsd.org/D

As <machine/vm.h> is included from <vm/vm.h>, there is no need to
include it explicitly when <vm/vm.h> is already included.

Reviewed by: alc, kib
Differential Revision: https://reviews.freebsd.org/D5380

show more ...

As <machine/pmap.h> is included from <vm/pmap.h>, there is no need to
include it explicitly when <vm/pmap.h> is already included.

Reviewed by: alc, kib
Differential Revision: https://reviews.freebsd

As <machine/pmap.h> is included from <vm/pmap.h>, there is no need to
include it explicitly when <vm/pmap.h> is already included.

Reviewed by: alc, kib
Differential Revision: https://reviews.freebsd.org/D5373

show more ...

Improve support for Macs that have a stride not equal to the
horizonal resolution (width). In those cases fb_bpp ended up
completely wrong -- as in 6 bytes per pixel or something like
that. Since we

Improve support for Macs that have a stride not equal to the
horizonal resolution (width). In those cases fb_bpp ended up
completely wrong -- as in 6 bytes per pixel or something like
that. Since we already have a way to calculate fb_depth given
the masks and fb_bpp is effectively the same as fb_depth, all
we need to do is make sure fb_bpp is rounded to the next
multiple of the number of bits in a byte -- we assume we can
divide by the number of bits in a byte throughout vt(4).
While here:
- simplify how we calculate fb_depth.
- use fb_bpp instead of fb_depth to calculate fb_stride;
we know we can divide fb_bpp.
- don't limit fb_width and fb_height by VT_FB_DEFAULT_WIDTH
and VT_FB_DEFAULT_HEIGHT (resp.). Those constants have
not relation to the size of the frame buffer.

This at least fixes "lower-resolution" Macs. We're talking
1280x1024 or so. There still is a problem with 27" Macs,
which typically have a horizontal resolution over 2K.

PR: 193745 (partial)
Ok'd by: emaste@

show more ...

Better support memory mapped console devices, such as VGA and EFI
frame buffers and memory mapped UARTs.

1. Delay calling cninit() until after pmap_bootstrap(). This makes
sure we have PMAP ini

Better support memory mapped console devices, such as VGA and EFI
frame buffers and memory mapped UARTs.

1. Delay calling cninit() until after pmap_bootstrap(). This makes
sure we have PMAP initialized enough to add translations. Keep
kdb_init() after cninit() so that we have console when we need
to break into the debugger on boot.
2. Unfortunately, the ATPIC code had be moved as well so as to
avoid a spurious trap #30. The reason for which is not known
at this time.
3. In pmap_mapdev_attr(), when we need to map a device prior to the
VM system being initialized, use virtual_avail as the KVA to map
the device at. In particular, avoid using the direct map on amd64
because we can't demote by virtue of not being able to allocate
yet. Keep track of the translation.
Re-use the translation after the VM has been initialized to not
waste KVA and to satisfy the assumption in uart(4) that the handle
returned for the low-level console is the same as later returned
when the device is probed and attached.
4. In pmap_unmapdev() remove the mapping from the table when called
pre-init. Otherwise keep the mapping. During bus probe and attach
device resources are mapped and unmapped multiple times, which
would have us destroy the mapping used by the low-level console.
5. In pmap_init(), set pmap_initialized to signal that we're not
pre-init anymore. On amd64, bring the direct map in sync with the
translations created at that time.
6. Implement bus_space_map() and bus_space_unmap() for real: when
the tag corresponds to memory space, call the corresponding
pmap_mapdev() and pmap_unmapdev() functions to construct and
actual handle.
7. In efifb.c and vt_vga.c, remove the crutches and hacks and simply
call pmap_mapdev_attr() or bus_space_map() as desired.

Notes:
1. uart(4) already used bus_space_map() during low-level console
setup but since serial ports have traditionally been I/O port
based, the lack of a proper implementation for said function
was not a problem. It has always supported memory mapped UARTs
for low-level consoles by setting hw.uart.console accordingly.
2. The use of the direct map on amd64 without setting caching
attributes has been a bigger problem than previously thought.
This change has the fortunate (and unexpected) side-effect of
fixing various EFI frame buffer problems (though not all).

PR: 191564, 194952

Special thanks to:
1. XipLink, Inc -- generously donated an Intel Bay Trail E3800
based eval board (ADLE3800PC).
2. The FreeBSD Foundation, in particular emaste@ -- for UEFI
support in general and testing.
3. Everyone who tested the proposed for PR 191564.
4. jhb@ and kib@ for being a soundboard and applying a clue bat
if so needed.

show more ...

- Nuke dupe $FreeBSD$.
- Fix whitespace.

MFC after: 3 days

Partially revert "vt: register the memory regions used by the vt drivers"

Revert the EFI part of r276064 until I can test it properly on a real EFI
system. This was causing problems to people bootin

Partially revert "vt: register the memory regions used by the vt drivers"

Revert the EFI part of r276064 until I can test it properly on a real EFI
system. This was causing problems to people booting using UEFI and vt.

Reported by: O. Hartmann <ohartman@zedat.fu-berlin.de>

show more ...

vt: register the memory regions used by the vt drivers

Current VT drivers don't register the memory regions they use with the
nexus. This patch makes vt_vga and vt_efifb register the memory regions

vt: register the memory regions used by the vt drivers

Current VT drivers don't register the memory regions they use with the
nexus. This patch makes vt_vga and vt_efifb register the memory regions they
use.

This is needed (at least) for Xen support, since the FreeBSD kernel will try
to use the holes in the memory map to map memory from other domains and
setup it's grant table.

Sponsored by: Citrix Systems R&D
Reported by: sbruno
Tested by: emaste
Reviewed by: ray
PR: 195537
Differential Revision: https://reviews.freebsd.org/D1291

show more ...

vt(4): Use vt_fb_drawrect() and vt_fb_setpixel() in all vt_fb-derivative

Review: https://reviews.freebsd.org/D789
Reviewed by: nwhitehorn
Approved by: nwhitehorn
MFC after: 2 days

vt(4): Add vd_bitblt_bmp_t callback

The code was already there in all backends, we just expose it. This is
used to display the splash screen.

MFC after: 1 week

vt_fb: Implement vd_bitblt_text_t for vt_fb and derivatives

MFC after: 1 week

vt(4): Colors are indexed against a console palette, not a VGA palette

Rename vt_generate_vga_palette() to vt_generate_cons_palette() and
change it to build a palette where the color index is the sa

vt(4): Colors are indexed against a console palette, not a VGA palette

Rename vt_generate_vga_palette() to vt_generate_cons_palette() and
change it to build a palette where the color index is the same than in
terminal escape codes, not the VGA index. That's what TCHAR_CREATE()
uses and passes to vt(4).

The main differences between both orders are:
o Blue and red are swapped (1 <-> 4)
o Yellow and cyan are swapped (3 <-> 6)

The problem remained unnoticed, because the RGB bit indexes passed to
vt_generate_vga_palette() were reversed. This inversion was cancelled
by the colors inversions in the generated palette. For instance, red
(0xff0000) and blue (0x0000ff) have bytes in opposite order, but were
swapped in the palette. But after changing the value of blue (see last
paragraph), the modified color was in fact the red one.

This commit includes a fix to creator_vt.c, submitted by Nathan
Whitehorn: fb_cmsize is set to 16. Before this, the generated palette
would be overwritte. This fixes colors on sparc64 with a Creator3D
adapter.

While here, tune the palette to better match console colors and improve
the readability (especially the dark blue).

Submitted by: nwhitehorn (fix to creator_vt.c)
MFC after: 1 week

show more ...