- 26 Jun, 2018 1 commit
-
-
Mauro Carvalho Chehab authored
This script is mentioned at multisound Kconfig and files. As the driver still exists, it probably makes sense to restore it. Fixes: 727dede0 ("sound: Retire OSS") Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 25 Jun, 2018 20 commits
-
-
Takashi Iwai authored
Currently patch_alc269() calls the fixup with HDA_FIXUP_ACT_PRE_PROBE before setting up the codec model-specific setups (e.g. setting codec_variant or mixer_nid setup). This is rather confusing as others do call the *_PRE_PROBE fixup after such a setup. Due to this disorder, we have to override spec->shutup not at the usual HDA_FIXUP_ACT_PRE_PROBE but the unusual HDA_FIXUP_ACT_PROBE time. This patch corrects the fixup call orders in patch_alc269(), and also corrects the action to set up spec->shutup accordingly. No functional changes but just refactoring. Signed-off-by: -
Takashi Iwai authored
In this patch, the remaining static init verbs in VIA codec driver are converted to the standard snd_hda_add_verbs() calls. The conversion is straightforward, but one change to be noted is the place of calls: since these verbs are supposed to be executed at the beginning of the init / resume procedure, we need to add snd_hda_add_verbs() calls before calling the other parsers. This is merely a cleanup, no functional changes. Signed-off-by: -
Takashi Iwai authored
This patch replaces the control element creations in VIA codec driver with the standard snd_hda_gen_add_kctl() calls as a cleanup. There are two major fields targeted by this patch: the beep controls and static init controls. The former is converted just like other codec drivers do. The spec->beep_amp field can be eliminated by this change as well. The latter, static init controls, are replaced simply with explicit snd_hda_gen_add_kctl() calls. After these conversions, via_build_controls() becomes superfluous and replaced with snd_hda_gen_build_controls(), too. Signed-off-by: -
Takashi Iwai authored
Currently VIA codec driver invokes via_free() at each place of the error path. Move the error handling to the end of each function commonly and do goto-error as a standard idiom. This is a preliminary patch for the further cleanups, and no functional changes. Signed-off-by: -
Takashi Iwai authored
This patch moves the mixer creation code in Cirrus codec driver from its own build_controls callback to snd_hda_gen_add_kctl() for simplification. As a bonus, this allows us to remove the cs421x_build_controls as it becomes identical with snd_hda_gen_build_controls(). Signed-off-by: -
Takashi Iwai authored
Like the previous commit for Realtek codec, the similar cleanup work can be applied to Conexant codec, too. A slight difference is that the call of cx_auto_parse_beep() is moved after snd_hda_gen_parse_auto_config(). It's not strictly needed, but it'd be good to make the creation of such beep mixers at the end, which matches with the former situation. Along with this conversion, cx_auto_build_controls() becomes just calling snd_hda_gen_build_controls(), so it's simply replaced with snd_hda_gen_build_controls. Signed-off-by: -
Takashi Iwai authored
In the Realtek codec driver, we used to build kctl elements for beep mixer in the own build_controls callback. This is an open-code and can be covered by the standard feature of the generic parser with snd_hda_gen_add_kctl() instead. Also, after the conversion, spec->beep_amp becomes superfluous; hence it's removed along with the conversion. Signed-off-by: -
Takashi Iwai authored
The beep mixer controls are the only remaining stuff that uses spec->mixers[] array, and they can be well converted to the standard helper in the generic parser, snd_hda_gen_add_kctl(). This simplifies the code, especially the superfluous mixers and num_mixers fields can be now removed from alc_spec. Signed-off-by: -
Takashi Iwai authored
The ALC660VD_FIX_ASUS_GPIO1 quirk requires to set up GPIO bit0 ON while bit 1 OFF. Implement the fixup function and convert from the static init verbs. Signed-off-by: -
Takashi Iwai authored
Dell XPS13 has multi-step fixups, and one of them (ALC288_FIXUP_DELL_XPS_13_GPIO6) corresponds to the management of GPIO bit6 (0x40). It used to be a static init verbs (to turn *off* the bit6). In this patch, we convert it as the gpio_mask and gpio_dir initializations folded in the existing fixup function. With this change, ALC288_FIXUP_DELL_XPS_13_GPIO6 becomes superfluous, thus it's removed. Signed-off-by: -
Takashi Iwai authored
This patch converts the remaining static init verbs for GPIO bits with the common gpio_* fields management. Only the verbs setting the GPIO data bits are targeted in this patch. The rest will be changed in later patches. Signed-off-by: -
Takashi Iwai authored
Now we can simplify the mute LED GPIO handling as well. Each fixup dealing with GPIO for the mute LED controls defined the static init verbs, and they are converted to the common GPIO bit fields with the new helper, alc_fixup_hp_gpio_led(). Signed-off-by: -
Takashi Iwai authored
The fixup for Macbook Pro is nothing but setting the GPIO bits as usual but with one exception: it adds some delay at writing the GPIO bits. Add a flag to put the conditional delay in the common helper, and clean up alc885_fixup_macpro_gpio() with the new flag. Signed-off-by: -
Takashi Iwai authored
Until now, two fields, gpio_data and gpio_led, coexist in alc_spec although basically both of them serve for the same purpose -- the GPIO data bits. This patch consolidates both usages and eliminates the superfluous gpio_led field. Signed-off-by: -
Takashi Iwai authored
For updating GPIO bits dynamically, provide a new helper, and use it from the alc260 automute hook. This helper will be used by other places in future, too. Signed-off-by: -
Takashi Iwai authored
Currently the GPIO bits are managed by individual verbs in some cases while toggled dynamically in other cases. For simplifying the GPIO management, define the GPIO mask, dir and data bits in alc_spec fields, and refer to / set them consistently from all places. As a first step, along with the definition of the new gpio_* fields, this patch replaces the static verbs that are used at initialization and fixups with the common helper functions. Signed-off-by: -
Takashi Iwai authored
Some devices have the overrides of spec->init_amp at HDA_FIXUP_ACT_PROBE just because alc_ssid_check() gives the false-positive values from the SSID. For more consistent behavior, define the logic in the following way: - Define ALC_INIT_UNDEFINED as the default value before calling alc_ssid_check() - Each fixup may set up spec->init_amp with another value at HDA_FIXUP_ACT_PRE_PROBE - At detection, check whether spec->init_amp is ALC_INIT_UNDEFINED or not; if it's different, we skip the detection Also, it turned out that ASUS TX300 requires the spec->init_amp override, too; currently it ignores the GPIO bits implicitly by its static init verb, but this will be changed in the later patchset. Signed-off-by: -
Takashi Iwai authored
-
Robert Jarzmik authored
Add a devicetree binding for codecs. This is especially useful if the AC97 bitclk clock is provided by the codec, as it has to be described in the devicetree description for the ac97 bus code to aquire it. Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Robert Jarzmik authored
Add the generic ac97 bus binding, especially for ac97 codecs discovered by ac97 hardware probing. Signed-off-by:
-
- 21 Jun, 2018 8 commits
-
-
Takashi Iwai authored
alc269_fixup_hp_line1_mic1_led() can be simplified more with the existing helper code. Signed-off-by: -
Takashi Iwai authored
There are a couple of places setting cap_sync_hook in the codec drivers, and they just overwrite the value. Add a sanity check via WARN_ON() in case if an old non-NULL value is overridden and forgotten. Signed-off-by: -
Takashi Iwai authored
To simplify the code and to get the mic-mute LED behavior control, use the new helper function for controlling the mic mute LED instead of open-codes. Signed-off-by: -
Takashi Iwai authored
Instead of refusing, allow the configuration with the multiple ADCs (thus multiple capture switches) for enabling the mic mute LED. This has been done for Sigmatel/IDT codecs, and we treat the OR-ed values from all capture switches as the boolean condition. Signed-off-by: -
Takashi Iwai authored
Convert to use the common helper for controlling the mic mute LED for HP laptops, just as we've done for Realtek codecs. This will give the mic mute LED enum as gratis. Signed-off-by: -
Takashi Iwai authored
Similar as the previous commit, convert to use the common helper for controlling the mic mute LED for HP and other machines in the Realtek codec driver, too. This will give the mic mute LED enum as gratis. Signed-off-by: -
Takashi Iwai authored
Use the new common helper for setting up and controlling the mic mute LED over thinkpad_acpi. This also provides a new mixer enum "Mic Mute-LED Mode" (that was present only for Dell models), which allows user to choose the mic mute LED behavior. For example, if you want the mic mute LED turned on only while mic is on, choose "Follow Capture" there. Tested-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
-
Takashi Iwai authored
Move the code for setting up and controlling the mic mute LED hook from dell-wmi helper to the generic parser, so that it can be referred from the multiple driver codes. No functional change. Tested-by:
-
- 19 Jun, 2018 5 commits
-
-
Takashi Sakamoto authored
This commit adds support for MOTU Traveler, launched in 2005, discontinued quite before. As a result, transmission of PCM frame and MIDI messages is available via ALSA PCM and RawMIDI/Sequencer interfaces. This model supports sampling transmission frequency up to 192.0 kHz, and AES/EBU on XLR interface and ADAT on optical interface. Unlike Motu 828MkII, Windows driver can switch fetching mode for DSP, like mute/unmute feature. Although this commit enables high sampling transmission frequency, actual sound from this model is not good. As long as I tested, it's silence at 176.4 kHz, and it includes hissing noise at 192.0 kHz. In my opinion, as I reported at 3526ce7f9ba7 ('ALSA: firewire-motu: add MOTU specific protocol layer'), timestamping on source packet header (SPH) may not still be good for this model as well. $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 04106505 bus_info_length 4, crc_length 16, crc 25861 404 31333934 bus_name "1394" 408 20001000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4) 40c 0001f200 company_id 0001f2 | 410 0001f32f device_id 000001f32f | EUI-64 0001f2000001f32f root directory ----------------------------------------------------------------- 414 0004c65c directory_length 4, crc 50780 418 030001f2 vendor 41c 0c0083c0 node capabilities per IEEE 1394 420 8d000006 --> eui-64 leaf at 438 424 d1000001 --> unit directory at 428 unit directory at 428 ----------------------------------------------------------------- 428 00035955 directory_length 3, crc 22869 42c 120001f2 specifier id 430 13000009 version 434 17107800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 000206b2 leaf_length 2, crc 1714 43c 0001f200 company_id 0001f2 | 440 0001f32f device_id 000001f32f | EUI-64 0001f2000001f32f Signed-off-by:Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
Takashi Sakamoto authored
For MOTU protocol version 2, this driver arranges the number of data chunks to align chunks to quadlet data channel. However, MOTU Traveler has padding bytes in the end of data block at high clock mode. This commit removes the arrangement. Fortunately, at low and middle clock mode, supported model for v2 protocol (828mkII) gets no influence from this change because all of combination for data chunks are just aligned to quadlet data channel. Signed-off-by:
-
Takashi Sakamoto authored
MOTU Traveler supports AES/EBU on XLR interface and data block of rx/tx packet includes two chunk for the interface. This commit adds a flag for this purpose. Signed-off-by:
-
Takashi Sakamoto authored
This driver explicitly assumes that all of supported models have main data chunk separated from chunk for analog ports. However, MOTU Traveler doesn't support the separated main data chunk. This commit adds a flag for the separated main data chunk. Signed-off-by:
-
Takashi Sakamoto authored
In MOTU firewire protocol, data block consists of 24 bit data chunks except for one quadlet for source packet header (SPH). The number of data chunk in a data block is different between three clock modes; low, middle and high. When unit supports ADAT on optical interface, the data block includes some chunks for ADAT channels. These ADAT chunks are unavailable at high mode. This driver has local functions to calculate the number of ADAT chunks. But They uses stack for three clock modes. This is useless for higher mode. Signed-off-by:
-
- 18 Jun, 2018 3 commits
-
-
Arnd Bergmann authored
The get_seconds() function is deprecated because it truncates the timestamp to 32 bits, so all users should change to ktime_get_seconds() or ktime_get_real_seconds(). The firmware interface for passing the timestamp is also limited to 32 bits, so this patch only has the cosmetic effect of avoiding the old interface. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Stefan Agner authored
Currently a variable of type enum CT_AMIXER_CTL is used for enum CT_SUM_CTL values. This leads to warnings when using clang: sound/pci/ctxfi/ctmixer.c:945:32: warning: implicit conversion from enumeration type 'enum CT_SUM_CTL' to different enumeration type 'enum CT_AMIXER_CTL' [-Wenum-conversion] for (i = AMIXER_MASTER_F, j = SUM_IN_F; ~ ^~~~~~~~ sound/pci/ctxfi/ctmixer.c:975:29: warning: implicit conversion from enumeration type 'enum CT_SUM_CTL' to different enumeration type 'enum CT_AMIXER_CTL' [-Wenum-conversion] for (i = AMIXER_PCM_F, j = SUM_IN_F; i <= AMIXER_PCM_S; i++, j++) { ~ ^~~~~~~~ Introduce enum CT_SUM_CTL k and it instead. Signed-off-by:Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Stefan Agner authored
This fixes a warning seen with clang: sound/pci/ice1712/prodigy_hifi.c:321:28: warning: variable 'wm_vol' is not needed and will not be emitted [-Wunneeded-internal-declaration] static const unsigned char wm_vol[256] = { ^ Signed-off-by:
-
- 17 Jun, 2018 3 commits
-
-
Alastair Bridgewater authored
The commentary says to use various parameters, and lays out what the mapping is... The code used a 32KHz rate when the comment says that it needs to use a 48KHz rate. And this has been the case since day one. On the Alienware M17x R4, the DMic used to have exceptionally quiet pickup and a lot of noise. Changing the data rate fixes both of these issues. Searching the kernel bug tracker for ca0132-related issues shows no mention of this being an issue for other hardware, and I have no other hardware to test with, so a quirk is used to limit the effect to just the M17x R4. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
-
Alastair Bridgewater authored
Commit 009b8f97 conditionalized adding the "CA0132 Analog Mic-In2" PCM with a comment to the effect that, "desktops don't use this ADC", but the test was set up such that the ADC was only created for desktops. Invert the test. Fixes: 009b8f97 ("ALSA: hda/ca0132: update core functions for sbz + r3di") Signed-off-by:
-
Alastair Bridgewater authored
QUIRK_NONE is, quite explicitly, the default case. The entire point of a quirks system is to allow "programming by difference" from a given base case, which requires that merely defining a new quirk for some piece of hardware should not change the behavior of the driver for that hardware. In turn, this means that testing for QUIRK_NONE explicitly is a violation of that implicit contract. Change a test for QUIRK_NONE and QUIRK_ALIENWARE to default, and add a test for QUIRK_SBZ to disable the default behavior in that instance. Signed-off-by:
-
