| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
used with Terasic's DE-4 and other similar FPGA boards. This display
is 800x480 and includes a capacitive touch screen, multi-touch
gesture recognition, etc. This device driver depends on a Cambridge-
provided IP core that allows the MTL device to be hooked up to the
Altera Avalon SoC bus, and also provides a VGA-like text frame buffer.
Although it is compiled as a single device driver, it actually
implements a number of different device nodes exporting various
aspects of this multi-function device to userspace:
- Simple memory-mapped driver for the MTL 24-bit pixel frame buffer.
- Simple memory-mapped driver for the MTL control register set.
- Simple memory-mapped driver for the MTL text frame buffer.
- syscons attachment for the MTL text frame buffer.
This driver attaches directly to Nexus as is common for SoC device
drivers, and for the time being is considered BERI-specific, although
in principle it might be used with other hard and soft cores on
Altera FPGAs.
Control registers, including touchscreen input, are simply memory
mapped; in the future it would be desirable to hook up a more
conventional device node that can stream events, support kqueue(2)/
poll(2)/select(2), etc.
This is the first use of syscons on MIPS, as far as I can tell, and
there are some loose ends, such as an inability to use the hardware
cursor. More fundamentally, it appears that syscons(4) assumes that
either a host is PC-like (i386, amd64) *or* it must be using a
graphical frame buffer. While the MTL supports a graphical frame
buffer, using the text frame buffer is preferable for console use.
Fixing this issue in syscons(4) requires non-trivial changes, as the
text frame buffer support assumes that direct memory access can be
done to the text frame buffer without using bus accessor methods,
which is not the case on MIPS. As a workaround for this, we instead
double-buffer and pretend to be a graphical frame buffer exposing
text accessor methods, leading to some quirks in syscons behaviour.
Sponsored by: DARPA, AFRL
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The driver attempts to support all documented parts, but has only been
tested with the 512Mbit part on the Terasic DE4 FPGA board. It should be
trivial to adapt the driver's attach routine to other embedded boards
using with any parts in the family.
Also import isfctl(8) which can be used to erase sections of the flash.
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which presents a UART-like interface over the Avalon bus that can be
addressed over JTAG. This IP core proves extremely useful, allowing us to
connect trivially to the FreeBSD console over JTAG for FPGA-embedded hard
and soft cores. As interrupts are optionally configured for this soft
core, we support both interrupt-driven and polled modes of operation,
which must be selected using device.hints. UART instances appear in /dev
as ttyu0, ttyu1, etc.
However, it also contains a number of quirks, which make it difficult to
tell when JTAG is connected, and some buffering issues. We work around
these as best we can, using various heuristics.
While the majority of this device driver is not only not BERI-specific,
but also not MIPS-specific, for now add its defines in the BERI files
list, as the console-level parts are aware of where the first JTAG UART
is mapped on Avalon, and contain MIPS-specific address translation, to
use before Newbus and device.hints are available.
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which can be synthesised in Altera FPGAs. An altera_sdcardc device
probes during the boot, and /dev/altera_sdcard devices come and go as
inserted and removed. The device driver attaches directly to the
Nexus, as is common for system-on-chip device drivers.
This IP core suffers a number of significant limitations, including a
lack of interrupt-driven I/O -- we must implement timer-driven polling,
only CSD 0 cards (up to 2G) are supported, there are serious memory
access issues that require the driver to verify writes to memory-mapped
buffers, undocumented alignment requirements, and erroneous error
returns. The driver must therefore work quite hard, despite a fairly
simple hardware-software interface. The IP core also supports at most
one outstanding I/O at a time, so is not a speed demon.
However, with the above workarounds, and subject to performance
problems, it works quite reliably in practice, and we can use it for
read-write mounts of root file systems, etc.
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CPU cores on Altera FPGAs. The device driver allows memory-mapped devices
on Altera's Avalon SoC bus to be exported to userspace via device nodes.
device.hints directories dictate device name, permissible access methods,
physical address and length, and I/O alignment. Devices can be accessed
using read(2)/write(2), but also memory mapped in userspace using mmap(2).
Devices attach directly to the Nexus, as is common for embedded device
drivers; in the future something more mature might be desirable. There is
currently no facility to support directing device-originated interrupts to
userspace.
In the future, this device driver may be renamed to socgen(4), as it can
in principle also be used with other system-on-chip (SoC) busses, such as
Axi on ASICs and FPGAs. However, we have only tested it on Avalon busses
with memory-mapped ROMs, frame buffers, etc.
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
|
| |
on PowerPC support. This was clearly not something syscons was
designed to do (very specific assumptions about the nature of VGA
consoles on PCs), but fortunately others have long since blazed
the way on making it work regardless of that.
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
| |
relative priority of the gxemul console in line with its role as a
"seiral console". This allows it to override video console drivers
that might otherwise take precdence, subject to that boot flag.
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
| |
the default MIPS /etc/ttys.
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
| |
This ensures that any ccbs which immediately start during the call to
xpt_release_devq see an accurate picture of the frozen_lun_mask.
Sponsored by: Intel
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DFS parameters fetched from the HAL.
Check whether the specific chipset supports RADAR reporting before
enabling DFS; or some of the (unset) DFS methods may fail.
Tested:
* AR5210 (correctly didn't enable radar PHY reporting)
* AR5212 (correctly enabled radar PHY reporting w/ the correct default
parameters.)
TODO:
* Now that I have this capability check in place, I could remove the
(empty) DFS methods from AR5210/AR5211.
* Test on AR5416, AR9160, AR9280.
PR: kern/170904
|
|
|
|
|
|
| |
fetching the current DFS configuration.
PR: kern/170904
|
|
|
|
| |
PR: kern/170904
|
| |
|
|
|
|
|
|
| |
I need to check whether new parameters were added for the AR5413 NIC.
PR: kern/170904
|
|
|
|
|
|
|
| |
The only chip this is currently implemented for is the AR5416 HAL family.
A follow-up commit will add AR5212 support.
PR: kern/170904
|
|
|
|
| |
Obtained from: Qualcomm Atheros
|
| |
|
|
|
|
| |
Obtained from: Qualcomm Atheros
|
| |
|
| |
|
|
|
|
| |
Obtained from: Qualcomm Atheros
|
|
|
|
| |
Obtained from: Qualcomm Atheros
|
|
|
|
| |
Obtained from: Qualcomm Atheros
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* mfp support;
* 4.9ghz support in the HAL;
* device type - specifically, the bus type and whether it's a HB63
NIC (which requires some subtle chainmask handling differences
in the AR5416 HAL.)
Obtained from: Qualcomm Atheros
|
|
|
|
| |
bridges do.
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
| |
Report errors indicated by the transport. If this is too chatty, I'll
throw it behind a debug write.
Remove commented out debugs that are no longer useful.
|
|
|
|
| |
Obtained from: Qualcomm Atheros
|
|
|
|
| |
Obtained from: Qualcomm Atheros
|
|
|
|
| |
Obtained from: Device IDs are from Qualcomm Atheros
|
| |
|
|
|
|
|
| |
Submitted by: Dmitry Luhtionov
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses kernel panic observed when sending SCSI UNMAP
commands to SATA disks attached to isci(4).
1) Flesh out callback routines to allocate/free buffers needed for
translating SCSI UNMAP data to ATA DSM data.
2) Add controller-level pool for storing buffers previously allocated
for UNMAP translation, to lessen chance of no buffer available
under memory pressure.
3) Ensure driver properly handles case where buffer pool is empty
and contigmalloc returns NULL.
Sponsored by: Intel
Reported by: Maksim Yevmenkin <max at netflix dot com>
Discussed with: scottl
MFC after: 3 days
|
|
|
|
|
|
| |
evicted from the syncache but a later syncache_expand succeeds because
of syncookies. The TOE driver has to resort to more direct means to
install its hooks in the socket in this case.
|
| |
|
|
|
|
|
| |
Add missing clock settings.
VBUS GPIO IRQ is still missing (TODO).
|
| |
|
|
|
|
| |
some comments while here.
|
|
|
|
| |
setbit/clrbit.
|
|
|
|
|
|
| |
the TOE driver reports that an active open failed. toe_connect_failed is
supposed to handle this but it should be provided the inpcb instead of the
tcpcb which may no longer be around.
|
|
|
|
| |
Submitted by: Yusuke Tanaka
|
|
|
|
|
|
| |
GCC on -9 didn't pick this up; clang did.
Submitted by: David Wolfskill
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
| |
qnum.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: This is totally sub-optimal and a work in progress.
* Support filling an empty FIFO TXQ with frames from the ath_buf queue
in the ath_txq list. However, since there's (currently) no clean, easy
way to separate the frames that are in the FIFO versus just waiting,
the code waits for the FIFO to be totally empty before it attempts to
queue more. This is highly sub-optimal but is enough to get the ball
rolling.
* A _lot_ of the code assumes that the TX status is filled out in the
struct ath_buf bf_status field. So for now, memcpy() the completion over.
* None of the TX drain / reset routines will attempt to complete completed
frames before draining, so it can't be used for 802.11n TX aggregation.
(This won't work anyway, as the aggregation TX descriptor API hasn't
yet been converted; and that'll happen in some future commits.)
* Fix an issue where the FIFO counter wasn't being incremented, leading
to the queue logic just plain not working.
* HAL_EIO means "descriptor wasn't valid", versus "not finished, don't
continue." So don't stop processing descriptors when HAL_EIO is hit.
* Don't service frame completion from the beacon queue. It isn't currently
fully setup like a real queue and the first attempt at accessing the
queue lock will panic the kernel.
Tested:
* AR9380, STA mode
This commit is brought to you by said AR9380 in STA mode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sizeof(struct ath_desc). This isn't correct for EDMA TX descriptors.
This popped up during iperf tests. Ping tests never created frames that
had enough segments to overflow into a second descriptor. However,
an iperf TCP test would do that after a few seconds; the second descriptor
would almost always certainly have garbage.
Tested:
* AR9380, STA mode
* AR9280, STA mode (802.11n TX, legacy TX)
|
| |
|