| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r314651:
sys/modules: normalize .CURDIR-relative paths to SRCTOP
This simplifies make output/logic
Tested with: `cd sys/modules; make ALL_MODULES=` on amd64
r318439:
Normalize .PATH on SRCTOP
This will help Jenkins dedupe 9 warnings between the static build and
the module build of ipsec(4).
Missed in SRCTOP conversion in r314651.
MFC with: r314651
r318440:
Normalize SYSDIR on SRCTOP instead of .CURDIR
This is being done to simplify pathing for CFLAGS and source files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
options into kern.opts.mk and change all the places where we use
src.opts.mk to pull in the options. Conditionally define SYSDIR and
use SYSDIR/conf/kern.opts.mk instead of a CURDIR path. Replace all
instances of CURDIR/../../etc with STSDIR, but only in the affected
files.
As a special compatibility hack, include bsd.owm.mk at the top of
kern.opts.mk to allow the bare build of sys/modules to work on older
systems. If the defaults ever change between 9.x, 10.x and current for
these options, however, you'll wind up with the host OS' defaults
rather than the -current defaults. This hack will be removed when
we no longer need to support this build scenario.
Reviewed by: jhb
Differential Revision: https://phabric.freebsd.org/D529
|
|
|
|
| |
from the latter.
|
|
|
|
|
|
|
| |
Cards are expensive and so rare, so leave the driver as module.
Submitted by: Ruslan Bukin <br@bsdpad.com>
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
| |
kernel modules that include binary-only code.
More fine-grained control is provided via MK_SOURCELESS_HOST (for native code
that runs on host CPU) and MK_SOURCELESS_UCODE (for microcode).
Reviewed by: julian, delphij, freebsd-arch
Approved by: kib (mentor)
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
| |
Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is the
source code location of the machine, the latter the binary output. In
general, we want to use MACHINE_CPUARCH instead of MACHINE_ARCH unless
we're tesitng for a specific target. The isn't even moot for
i386/amd64 where there's momemntum towards a MACHINE_CPUARCH == x86,
although a specific cleanup for that likely would be needed...
|
| |
|
|
|
|
|
|
| |
hardware.
Submitted by: Marco Trillo
|
|
|
|
| |
Pointed out by: ariff
|
|
|
|
|
|
|
|
| |
which are also likely to be irrelevant for sun4v (there's no SBus on sun4v
and only some EBus devices). While at it fix some style bugs according to
style.Makefile(5) where appropriate.
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for Intel High Definition Audio Controller.
This driver make a special guarantee that "playback" works
on majority hardwares with minimal or without specific vendor
quirk.
This driver is a product of collaborative effort made by:
Stephane E. Potvin <sepotvin@videotron.ca>
Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Wesley Morgan <morganw@chemikals.org>
Daniel Eischen <deischen@FreeBSD.org>
Maxime Guillaud <bsd-ports@mguillaud.net>
Ariff Abdullah <ariff@FreeBSD.org>
....and various people from freebsd-multimedia@FreeBSD.org
Refer to snd_hda(4) for features and issues.
Welcome To HDA.
Sponsored by: Defenxis Sdn. Bhd.
|
| |
|
| |
|
|
|
|
| |
Submitted by: "Konstantin Dimitrov" <kosio.dimitrov@gmail.com>
|
|
|
|
|
|
| |
- Bump __FreeBSD_version, no need to build the port now.
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru> [1]
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on UltraSPARC workstations. The driver is based on OpenBSD's SBus
cs4231 driver and heavily modified to incorporate into sound(4)
infrastructure. Due to the lack of APCDMA documentation, the DMA
code of SBus cs4231 came from OpenBSD's driver.
The driver runs without Giant lock and supports both SBus and EBus
based CS4231 audio controller. Special thanks to marius for providing
feedbacks during the driver writing. His feedback made it possible
to write hiccup free playback code under high system loads.
Approved by: jake (mentor)
Reviewed by: marius (initial version)
Tested by: marius, kwm, Julian C. Dunn(jdunn AT opentrend DOT net)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This driver actually works slightly better on -stable than on -current
(the system locks on detach on -current), so it should be MFC'd somewhat
sooner.
This driver currently points out a difficulty in the sound device framework.
The PCM unregister routine is allowed to refuse the detach if the device is
in use. In the case of a USB device, however, this unregistration is much more
mandatory in nature, since the device is *actually* gone when this call is
made. The sound subsystem really should not refuse an unregistration and
should take its own steps to reject further I/O. As a result, if you detach
a USB sound device while it is in use, you can expect a panic shortly
thereafter.
This device cannot currently record audio. Some routines are unwritten as
of yet in uaudio.c to support recording.
This device hangs my -current box on detach. I don't know why. This does
not happen on my -stable machine.
Obtained from: Hiroyuki Aizu
MFC after: 2 weeks
|
|
|
|
| |
that want them
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the impatient.
Hardware...
Provided by: ps
Lost by: <censored>
Found by: <censored>
Not delivered by: Ashley Penney <ashp@unloved.org>
Retrieved by: greid, Andrew McKay <andy@openirc.co.uk>
Delivered by: Andrew McKay <andy@openirc.co.uk>
PR: kern/25507
Submitted by: Katsurajima Naoto <raven@katsurajima.seya.yokohama.jp>
|
| |
|
|
|
|
| |
OK'ed by: cg
|
|
|
|
| |
Submitted by: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
|
|
|
|
| |
Submitted by: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
|
|
|
|
|
|
| |
amount of GPL'd firmware in the driver, it will only be built as a module.
Approved by: cg
|
| |
|
|
|
|
| |
Approved by: cg
|
| |
|
| |
|
|
|
|
|
| |
recording is still broken, but IMHO that's enough to at least
"hook it up" to the rest of the kernel/module builds.
|
|
once built, 'kld_load snd_driver; kldunload snd_driver' will load all sound
drivers and unload all unattached ones. attached drivers do not yet support
unloading.
|