All those kernels have a line for both tun and bridge, and if either is
commented out, tap is commented out also. With the exception of i386's
GENERIC_TINY.
XXX: we _need_ some way of making this more simple.
audio framework
Summary of changes:
* struct audio_params
- remove sw_code, factor, factor_denom, hw_sample_rate,
hw_encoding ,hw_precision, and hw_channels. Conversion information
is conveyed by stream_filter_list_t.
- change the type of sample_rate: u_long -> u_int
- add `validbits,' which represents the valid data size in
precision bits. It is required in order to distinguish 24/32bit
from 24/24bit or 32/32bit.
* audio_hw_if
- add two parameters to set_params()
stream_filter_list_t *pfil, stream_filter_list *rfil
A HW driver should set filter recipes for requested formats
- constify audio_params parameters of trigger_output() and
trigger_input(). They represent audio formats for the hardware.
- make open() and close() optional
- add int (AUMODE_PLAY or AUMODE_RECORD) and audio_params_t parameters
to round_blocksize()
* sw_code is replaced with stream_filter_t.
stream_filer_t converts audio data in an input buffer and writes
into another output buffer unlike sw_code, which converts data in
single buffer.
converters in dev/auconv.c, dev/mulaw.c, dev/aurateconv.c,
dev/tc/bba.c, dev/ic/msm6258.c, and arch/arm/iomd/vidcaudio.c are
reimplemented as stream_filter_t
* MI audio
- audiosetinfo() builds filter pipelines from stream_filter_list_t
filled by audio_hw_if::set_params()
- audiosetinfo() returns with EINVAL if mmapped and set_params()
requests filters
- audio_write(), audio_pint(), and audio_rint() invoke a filter
pipeline.
- ioctl() for FIONREAD, AUDIO_WSEEK, AUDIO_GETIOFFS,
AUDIO_GETOOFFS, and audio_prinfo::{seek,samples} for
AUDIO_GETINFO handle values for a buffer nearest to userland.
* add `struct device *' parameter to ac97_attach()
* all of audio HW drivers follow audio_hw_if and ac97 changes
seem to occur fairly often under normal operation with HPC1.5.
Also, do not return if the interrupt is unexpected, but see if
there is anything to handle regardless, which appears to always
be the case with HPC1.5.
HPC1 does not mark transmitted descriptors like HPC3. We must
query the HPC1 chip to determine what it expects the next
descriptor to be, reclaim used ones, and restart if necessary. Each
revision's corresponding logic now lives in its own
sq_txring_hpc{1,3} function.
HPC1's transmit interrupt conditions also differ from HPC3, so
remove the INTR bits from descriptors when tagging new packets on
to the end of the chain in order to avoid unwanted interrupts.
Also, be extra careful when restarting the transmit ring. Since
transmit interrupts seem to be relatively slow on HPC1, sq_start
may be called while the DMA engine is quiescent, and before a
transmit interrupt is asserted. We cannot behave like HPC3, which
begins transmission from the first packet pulled from IFQ if the
DMA engine is quiescent as this would skip enqueued packets. It
appears that sq_start is never called before HPC3 asserts an
interrupt, which restarts the transmit queue at the appropriate
place. However, this often happens with HPC1 and we cannot assume
that if DMA is inactive in sq_start, then all previously queued
packets have fled the coop.
XXX Is there a similar race possible with HPC3?
HPC3 logic should remain functionally unchanged, and HPC1 should
finally work properly.
true on the transmit side, which appears to be significantly slower at
interrupting than HPC3.
XXX I used to be able to occasionally wedge the chip with
SQ_NTXDESC == 32, but have not yet been able to reproduce that
behaviour this evening with a larger value.
multiple seeq interfaces may exist. While here, add a few trace
actions, move the related macros into sqvar.h, and enhance the
sq_trace_dump output a bit.
Assume defaults for file images that match what a vnd would have used.
Native use will still use the standard NetBSD label to get this data.
Fixes PR#25996
Note that devices are defined in the IP2x configuration file; the IP12 is
99.5% the same as the IP20/22/24. Indeed, the only reason to have a separate
config file for IP12 is to sort out the MIPS1/MIPS3 locore bits.
To that end, the wrappers include the IP2x GENERIC config, undefine a few
directives, and define the appropriate bits for IP12.
