evbarm/am18xx: sdmmc driver
A first version of the SD card driver for the TI am1808. The driver works fine, but the performance is lower than expected.
evbarm/ti_edma: clear events before transfer
The sdmmc controller on the am18xx fires dma events even in PIO mode. Clear these event before starting a DMA transfer.
newport: ensure a valid ri_stride is provided to rasops_init()
The x resolution is calculated by timings programmed into VC2, rather
than some kind of hard coded width/height from the framebuffer.
Newport always supports up to 1280x1024 regardless of what your monitor
resolution is.
However for some monitor detection timings, the resulting geometry
is not ENTIRELY correct for rasops to work with. So just round it up
to a multiple of four so a newport console will always show up regardless
of said monitor timing.
Submitted by Imre Kaloz <kaloz at dune.hu> .
Fixes PR port-sgimips/60585 .
vdrain: Recompute target after each iteration.
This way if sysctl -w kern.maxvnodes=N fails, the vdrain task doesn't
perpetually keep trying to attain the unattainable.
Doesn't fix everything about racy access to desiredvnodes, but it
should help with the major symptom.
PR kern/60603: Sisyphean vdrain task
Do not require the display device to identify as VGA subclass.
If it's a display device and has AGP capability, we can trust it's a
proper AGP master. This fixes attachment for my Permedia 2 AGP board,
which identifies as subclass miscellaneous (0x80).
ddb(4)/crash(8): Print lock symbols in `show all locks'.
Reorder columns so the variable-width symbol comes last.
PR kern/60030: ddb/crash: show all locks without LOCKDEBUG
crash(8): Add support for `mach cpu N' on x86.
Requires core dump to have the registers saved on cpuN. This happens
with the ddb `sync' command, but not with the kern.dump_on_panic=1
ddb.onpanic=0 path yet -- TBD.
PR bin/58010: crash(8) doesn't support `mach cpu N' to examine
registers/stack of other CPUs
dwc2: Bring dwc2_wait_for_mode from upstream and use in dwc2_force_mode.
dwc2_wait_for_mode will wait upto 110milliseconds for the controller
to enter the expected mode.
This hopefully fixes
port-evbarm/60613: Recent dwc2 commit breaks usb based ethernet device...
Pull up following revision(s) (requested by rin in ticket #1327):
sys/dev/pci/pciconf.c: revision 1.57
sys/dev/pci/pciconf.c: revision 1.58
sys/dev/pci/pciconf.c: revision 1.59
pciconf: Fix alignments of device memory and I/O resources
Resources must be their-size-aligned. While here:
- Switch *align variable from int to more suitable integer types.
- Make some conditions clearer (NFC).
pciconf: Fix round-up logics for total sizes of bridge resources
The previous ones are valid only if alignments are 4K or 1M,
for I/O or memory, respectively.
pciconf: Sort resource windows in order of decreasing alignment
instead of size.
[8 lines not shown]
Pull up following revision(s) (requested by rin in ticket #418):
sys/dev/pci/pciconf.c: revision 1.57
sys/dev/pci/pciconf.c: revision 1.58
sys/dev/pci/pciconf.c: revision 1.59
pciconf: Fix alignments of device memory and I/O resources
Resources must be their-size-aligned. While here:
- Switch *align variable from int to more suitable integer types.
- Make some conditions clearer (NFC).
pciconf: Fix round-up logics for total sizes of bridge resources
The previous ones are valid only if alignments are 4K or 1M,
for I/O or memory, respectively.
pciconf: Sort resource windows in order of decreasing alignment
instead of size.
[8 lines not shown]
Pull up following revision(s) (requested by skrll in ticket #417):
sys/external/bsd/dwc2/dwc2.c: revision 1.84
PR/60021: USB-only boot: uhub0 attaches but uhub1 never appears...
Update the dwc2 intial reset sequence to more closely match the upstream
driver - it's changed a bit in the last 10 years.
This reset sequence gets the device out of the state it's left in by the
RaspberryPI firmware when booting from USB.
Pull up following revision(s) (requested by gutteridge in ticket #1326):
external/gpl2/grep/dist/src/grep.c: revision 1.6
external/gpl2/grep/dist/src/grep.c: revision 1.7
grep.c: fix ctype(3) issue leading to segfault
Addresses PR bin/60552 from Chavdar Ivanov, fix supplied by RVP.
grep.c: match upstream coding style for previous change (NFC)
Pull up following revision(s) (requested by gutteridge in ticket #416):
external/gpl2/grep/dist/src/grep.c: revision 1.6
external/gpl2/grep/dist/src/grep.c: revision 1.7
grep.c: fix ctype(3) issue leading to segfault
Addresses PR bin/60552 from Chavdar Ivanov, fix supplied by RVP.
grep.c: match upstream coding style for previous change (NFC)
Pull up following revision(s) (requested by riastradh in ticket #2045):
sys/kern/vfs_subr.c: revision 1.504
vflushbuf: Print `vflushbuf: dirty' warning only once per call.
And do it only under DEBUG, and rate-limit it globally.
This can happen when vflushbuf is competing with an onslaught of
concurrent I/O on a snapshot or block device (which is done without
holding the vnode lock, despite what the comment says). That
concurrent I/O might be happening indefinitely, so we are likely to
have to print a _lot_ of warnings, potentially overwhelming the
console, until the underlying problem is fixed by teaching vflushbuf
to wait only for the writes that began before have completed, not
also all writes that have begun since.
This stop-gap measure intended to be low-risk for pullup to release
branches.
[2 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1325):
sys/kern/vfs_subr.c: revision 1.504
vflushbuf: Print `vflushbuf: dirty' warning only once per call.
And do it only under DEBUG, and rate-limit it globally.
This can happen when vflushbuf is competing with an onslaught of
concurrent I/O on a snapshot or block device (which is done without
holding the vnode lock, despite what the comment says). That
concurrent I/O might be happening indefinitely, so we are likely to
have to print a _lot_ of warnings, potentially overwhelming the
console, until the underlying problem is fixed by teaching vflushbuf
to wait only for the writes that began before have completed, not
also all writes that have begun since.
This stop-gap measure intended to be low-risk for pullup to release
branches.
[2 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #415):
sys/kern/vfs_subr.c: revision 1.504
vflushbuf: Print `vflushbuf: dirty' warning only once per call.
And do it only under DEBUG, and rate-limit it globally.
This can happen when vflushbuf is competing with an onslaught of
concurrent I/O on a snapshot or block device (which is done without
holding the vnode lock, despite what the comment says). That
concurrent I/O might be happening indefinitely, so we are likely to
have to print a _lot_ of warnings, potentially overwhelming the
console, until the underlying problem is fixed by teaching vflushbuf
to wait only for the writes that began before have completed, not
also all writes that have begun since.
This stop-gap measure intended to be low-risk for pullup to release
branches.
[2 lines not shown]
