- fix multiple initialization of the first codec (support for more than
one codec should be added in the future)
- use spicds instead of ak452x module
Submitted by: "Konstantin Dimitrov" <kosio.dimitrov@gmail.com>
stripping was disabled due to being in promisc mode. This is a hardware
bug. Update comment to explicitly state the reason the manual vlan tag
insertion in this case. See rev. 1.53 for further information as well.
Noticed by: jhb
generic vlan_start() takes care of it when vlan hardware insertion is disabled.
In em_set_promisc() add a note that BPF may also be enabled without going into
promisc mode.
Reviewed by: jfv
IP options and add skeleton IPv6 support. The new code structure can also be
easily enhanced to support new/more protocols (SCTP) in the future.
Reviewed by: jfv
and add skeleton IPv6 support. The new code structure can also be easily
enhanced to support new/more protocols (SCTP) and IP fragmentation in the
future.
In em_encap() only try to do TSO if 'dotso' is true.
Reviewed by: jfv
- EFBIG means the mbuf chain was too long and bus_dma ran out of segments.
Defragment the mbuf chain and try again. (Already existed, not changed.)
- ENOMEM means bus_dma could not obtain enough bounce buffers at this point
in time. Defer sending and try again later.
- All other errors, in particular EINVAL, are fatal and prevent the mbuf
chain from ever going through. Drop it and report error.
- Checking (nsegs == 0) is unnecessary as bus_dmamap_load_mbuf_sg() always
reports an error if it is < 1.
This prevents broken packets from clogging the interface queue indefinately.
Discussed with: scottl
Reviewed by: jfv
commit.
1) sys/dev/sound/pcm/sound.h
sys/dev/sound/pcm/channel.c
* Be more specific: SD_F_SOFTVOL -> SD_F_SOFTPCMVOL
2) sys/dev/sound/pcm/mixer.[ch]
* Implement
mix_setparentchild()
mix_setrealdev()
mix_getparent()
mix_getchild()
The purpose of these functions is implement relative volume
adjustment, such as to tie two or more mixer device into a
single logical device. Usefull for the upcoming HDA driver
and few AC97 codec (such as AD1981B) where the master volume
"vol" need to be implemented using this logical manner.
3) sys/dev/sound/pcm/ac97_patch.[ch]
* Patch for AD1981B codec to enable (automuting) headphone jack sense.
4) sys/dev/sound/pcm/ac97.c
* Implement proper logical master volume for AD9181B codec
through various mix_set{parentchild,realdev}(). Tie both
"ogain" (headphone volume) and "phone" (speaker/lineout) to
a logical "vol".
5) sys/dev/sound/pcm/usb/uaudio_pcm.c
* ditto, for "vol" -> { "pcm" }.
MFC after: 1 month
ioctls passing integer arguments should use the _IOWINT() macro.
This fixes a lot of ioctl's not working on sparc64, most notable
being keyboard/syscons ioctls.
Full ABI compatibility is provided, with the bonus of fixing the
handling of old ioctls on sparc64.
Reviewed by: bde (with contributions)
Tested by: emax, marius
MFC after: 1 week
The key problem was that the aperture size detection using the MSAC bit
doesn't work -- the bit appears to be set even when it shouldn't be. Linux
takes a different approach, testing for a bit of the GMADR (PCIR_BAR(2)) being
set. However, as I don't think that's a safe way to test aperture size, we
just allocate the resource and check its size. This also pointed out that
agp_generic_attach hadn't been allocating our aperture resource, which may
have caused problems in some cases.
Also corrected is a minor copy-and-pasteo in an error case.
PR: kern/103079
Submitted by: mnag
Tested on: i945GM, i915GM
MFC after: 2 weeks
The goal was to sync with the OSSv4 API 4Front Technologies uses in their
proprietary OSS driver. This was successful as far as possible. The part
of the API which is stable is implemented, for the rest there are some
stubs already.
New system ioctls:
- SNDCTL_SYSINFO - obtain audio system info (version, # of audio/midi/
mixer devices, etc.)
- SNDCTL_AUDIOINFO - fetch details about a specific audio device
- SNDCTL_MIXERINFO - fetch details about a specific mixer device
New audio ioctls:
- Sync groups (SNDCTL_DSP_SYNCGROUP/SNDCTL_DSP_SYNCSTART) which allow
triggered playback/recording on multiple devices (even across processes
simultaneously).
- Peak meters (SNDCTL_DSP_GETIPEAKS/SNDCTL_DSP_GETOPEAKS) - can query
audio drivers for peak levels (needs driver support, disabled for now).
- Per channel playback/recording levels -
SNDCTL_DSP_{GET,SET}{PLAY,REC}VOL. Note that these are still in name
only, just wrapping around the AC97-style mixer at the moment. The next
step is to push them down to the drivers.
Audio ioctls still under development by 4Front (for which stubs may exist
in this commit):
- SNDCTL_GETNAME, SNDCTL_{GET,SET}{SONG,LABEL}
- SNDCTL_DSP_{GET,SET}_CHNORDER
- SNDCTL_MIX_ENUMINFO, SNDCTL_MIX_EXTINFO - (might be documented enough in
the OSS releases to work on this. These ioctls cover the cool "twiddle
any knob on your card" features.)
Missing:
- SNDCTL_DSP_COOKEDMODE -- this ioctl is used to give applications direct
access to a card's buffers, bypassing the feeder architecture. It's
a toughy -- "someone" needs to decide :
(a) if this is desireable, and (b) if it's reasonably feasible.
Updates for driver writers:
So far, only two routines to the channel class (in channel_if.m) are added.
One is for fetching a list of discrete supported playback/recording rates
of a channel, and the other is for fetching peak level info (useful for
drawing peak meters). Interested parties may want to help pushing down
SNDCTL_DSP_{GET,SET}{PLAY,REC}VOL into the drivers.
To use the new stuff you need to rebuild the sound drivers or your kernel
(depending on if you use modules or not) and to install soundcard.h (a
buildworld/installworld handles this).
Sponsored by: Google SoC 2006
Submitted by: ryanb
Many thanks to: 4Front Technologies for their cooperation, explanations
and the nice license of their soundcard.h.
- Split out the communication protocols into their own files and use
a couple of function pointers in the softc that the commuication
protocols setup in their own attach routine.
- Add support for the SSIF interface (talking to IPMI over SMBus).
- Add an ACPI attachment.
- Add a PCI attachment that attaches to devices with the IPMI interface
subclass.
- Split the ISA attachment out into its own file: ipmi_isa.c.
- Change the code to probe the SMBIOS table for an IPMI entry to just use
pmap_mapbios() to map the table in rather than trying to setup a fake
resource on an isa device and then activating the resource to map in the
table.
- Make bus attachments leaner by adding attach functions for each
communication interface (ipmi_kcs_attach(), ipmi_smic_attach(), etc.)
that setup per-interface data.
- Formalize the model used by the driver to handle requests by adding an
explicit struct ipmi_request object that holds the state of a given
request and reply for the entire lifetime of the request. By bundling
the request into an object, it is easier to add retry logic to the various
communication backends (as well as eventually support BT mode which uses
a slightly different message format than KCS, SMIC, and SSIF).
- Add a per-softc lock and remove D_NEEDGIANT as the driver is now MPSAFE.
- Add 32-bit compatibility ioctl shims so you can use a 32-bit ipmitool
on FreeBSD/amd64.
- Add ipmi(4) to i386 and amd64 NOTES.
Submitted by: ambrisko (large portions of 2 and 3)
Sponsored by: IronPort Systems, Yahoo!
MFC after: 6 days
Unfortunately, the QUEUE FULL event only tells you Bus && Target.
It doesn't tell you lun. In order for the XPT_REL_SIMQ action to
work, we have to have a real lun. But which one? For now, just
iterate over MPT_MAX_LUNS.
Practically speaking, this is only going to be happening for lower
quality SAS or SATA drives behind the SAS controller, which means
only lun 0, so it's not so bad.
Helpful Reminder Nagging from: John Baldwin, Fred Whiteside
MFC after: 5 days
of the chip to let ASF/IPMI firmware to respond to IPMI after attaching
and when the chip is down. David looked at it but could really say
what they right minimal config. stuff would be. It's not documented.
I figured this out via trial and error.
Reviewed by: davidch
is incorrect, and causes endianness bugs on 64-bit big-endian
machines (sparc64), it's the best choice for now, as many of
these IOCTLs are used inside the kernel, and bogusly pass an
argument as "int *" which results in unaligned access panics
on sparc64 when attempting to dereference them via *(intptr_t *).
(Several of us are working on a real fix, which is uneasy.)