| Age | Commit message (Collapse) | Author |
|
This change broke the intention of recent changes to pad(4).
The solution to address PR/57436 must be done in bta2dpd(8).
|
|
The previous commit was misleading due to the flag names used.
The rationale for this change is that it is ok to return EAGAIN on first
read as playback has not started. Then it shoud wait on every subsequent read.
This is what makes the high precsision throttling of pad(4), for which these
degree of fine-grained sleeps are not possible in userland. This is a
requirement of users of pad(4) such as bta2dpd(8).
|
|
Addresses PR/57436.
XXX pullup-10.
|
|
|
|
|
|
AUDIO_INTERNAL_BITS.
|
|
Enable interrupts while copying buffers.
|
|
interfaces, make sure that initialization and destruction
follow the proper sequence. This is triggered by the recent
changes to the devsw stuff; per riastradh@ the required call
sequence is:
devsw_attach()
config_init_component() or config_cf*_attach()
...
config_fini_component() or config_cf*_detach()
devsw_detach()
While here, add a few missing calls to some of the detach
routines.
Testing of these changes has been limited to:
1. compile without build break
2. no related test failures from atf
3. modload/modunload work as well as
before.
No functional device testing done, since I don't have any
of these devices. Let me know of any damage I might cause
here!
XXX Some of the modules affected by this commit are already
XXX broken; see kern/56772. This commit does not break
any additional modules (as far as I know).
|
|
Prune a whole lotta dead branches as a result of this. (Some logic
calling this is also wrong for other reasons; devsw_detach is final
-- you should never have any reason to decide to roll it back. To be
cleaned up in subsequent commits...)
XXX kernel ABI change to devsw_detach signature requires bump
|
|
Reported-by: syzbot+917ff3551897f1a99cf6@syzkaller.appspotmail.com
|
|
...and why the kernel lock is not enough.
|
|
|
|
- Don't touch sc_buflen outside sc_intr_lock.
- Omit needless broadcast in pad_halt_output -- nothing wakes on the
new condition (sc_buflen == 0), so this can't make a difference
except possibly in buggy code.
- Sprinkle KASSERTs.
|
|
Should not be possible for it to be pending or firing at this point,
because we have detached the audio(4) child and so it should have
halted output.
|
|
padN numbering never corresponded with audioM numbering except by
accident, so the non-cloning device never worked reliably for
scripting. This simplifies the logic substantially.
While here, fix drvctl detach race.
|
|
|
|
- No need for sc_cond_lock.
- Issue cv_broadcast under the correct lock.
- Use callout_halt, not haphazard callout_stop.
- IPL_SOFTCLOCK for a mutex taken from a callout.
|
|
- Put pseudo-device softc setup/teardown back in pad_attach/detach,
not in the cdev/fops operations which are about file descriptors.
- Remove unnecessary sc_dying flag.
- Omit needless config_deactivate(sc->sc_audiodev); the only effect
of this is already done by config_detach anyway, which is done in
the same context.
- Issue config_detach_children and free softc stuff in the right
order.
- Omit needless `if (sc == NULL) return ENXIO'.
Survives eight parallel t_mixerctl tests many times over on an
8-thread/4-core machine.
XXX TODO:
- Remove padconfig; it is not appropriate to hold a mutex over
sleeping allocation or autoconf config_attach operations. This
should be done another way.
- Fix agreement of sc_condvar with locks: is it sc_cond_lock or
sc_intr_lock? Can't be both; unclear why both exist.
- Determine whether both cdev and fops are really needed -- it is
confusing to have two types of paths into all this logic, and it
seems to me only one of them should be necessary.
|
|
This is not really enough -- the padconfig locking logic violates
rules about sleeping while holding locks, might be deadlocky, and may
also be racy. But, it'll serve to make progress.
|
|
reverts to the same behavior as in -8 and -9. prevents immediate failures
and device timeouts if there's a slight delay in the buffer being
consumed.
this is reproducible with the example in the man page that uses
ffmpeg to record the output of audioplay:
$ ffmpeg -f s16le -ar 44100 -ac 2 -i /dev/pad0 output.wav
$ audioplay -d /dev/audio1 input.wav
if output.wav already exists, ffmpeg will prompt for confirmation
to overwrite as soon as audioplay starts, causing a noticable delay,
followed by a write failure that causes audioplay to immediately
exit.
|
|
make start_output/halt_output optional if the driver has no playback.
And remove such never called functions.
|
|
get_props() of all MD drivers now can be called without sc_lock.
|
|
|
|
- Rename some functions for consistency.
- Rearrange some functions for readability.
- Unify to struct pad_softc.
|
|
|
|
|
|
- Interrupt-oriented system rather than thread-oriented.
- Improve stability, quality and performance.
- Split playback and record cleanly. Improve halfduplex support.
- Many bugs are fixed including deadlocks, resource leaks, abuses, etc.
- Simplify audio filter mechanism. The encoding/channels/frequency
conversions are completely handled in the upper layer. So the hard-
ware driver only converts its hardware encoding (if necessary).
- audio_hw_if changes:
- Obsoletes query_encoding and add query_format instead.
- Obsoletes set_params and add set_format instead.
- Remove drain, setfd, mappage.
- The call sequences are changed.
- ioctl AUDIO_GETFD/SETFD, AUDIO_GETCHAN/SETCHAN are obsoleted.
- ioctl AUDIO_{QUERY,GET,SET}FORMAT are introduced.
- cleanup config attributes: au*conv and mulaw.
- All hardware drivers should follow it (I've done as much as possible).
Some file paths are changed:
- dev/audio.c -> dev/audio/audio.c (rewritten)
- dev/audiovar.h -> dev/audio/audiovar.h
- dev/audio_dai.h -> dev/audio/audio_dai.h
- dev/audio_if.h -> dev/audio/audio_if.h
- dev/audiobell.c -> dev/audio/audiobell.c
- dev/audiobellvar.h -> dev/audio/audiobellvar.h
- dev/mulaw.[ch] -> dev/audio/mulaw.[ch] + dev/audio/alaw.c
|
|
This fixes the following strange output of mixerctl(1):
outputs.master=255,0
inputs.dac=255,0
|
|
I accidentally committed the netbsd-8 branch file in rev.1.54.
|
|
to avoid warnings from the ever friendly compiler... (check that size if
in range was already made).
|
|
|
|
This fixes the following strange output of mixerctl(1):
outputs.master=255,0
inputs.dac=255,0
|
|
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
|
|
|
|
|
|
* Introduce a lock to serialize attach/detach of pad devices.
* Forcefully detach children of pad on close.
* Be more carefull in pad_open with regards to config_detach only
if new instances of the pad device are created and fail to open.
Addresses PR kern/52889.
These changes were developed with and tested by pgoyette@.
|
|
discard its error value when re-attaching the devsw. If the devsw
is successfully re-attached and we return success, the module will
get detached anyway. And, since the device is actually busy, we'll
eventually panic.
Thanks to nat@ for providing the reproduction instructions.
XXX A driver-busy condition will currently still trigger the error
XXX message from config_fini_component()
XXX configure: attachment `pad' of `pad' driver fini failed: 16
XXX This will be addresses separately by having pad maintain its own
XXX ref-count and not relying on config_fini_component() to detect
XXX the busy state.
|
|
structures. (Note that bin/52823 documents the reasons for still
requiring hand-crafted cfattach structures.)
|
|
:)
|
|
|
|
config_{init,fini}_component()
|
|
is built-in to the kernel.
XXX pullup-8?
|
|
|
|
|
|
if it is not already configured.
This improves scriptability as you will know the particular pad(4) device
you have opened.
pad(4) devices still have a cloning interface if pad device (minor
number 254) is opened it will attach the next free device. This action
can be repeated.
XXX update MAKEDEV scripts to make /dev/pad the cloning device.
Ok christos@.
|
|
|
|
This means that only one pad device is required in /dev.
The code contains a compile time limit of 128 units.
Ok christos@.
|
|
returns.
|
|
Ok christos@.
|
|
|