- 15 Dec, 2015 3 commits
-
-
Takashi Sakamoto authored
In ALSA firewire stack, drivers basically has no control elements. This is due to the fact that each model has own functionality even if they use the same communication chipset. Implementing all of the functionalities in kernel space unreasonably increases our efforts to maintain the stack. In most case, these functionalities can be implemented in userspace via Linux fw character devices. However, ALSA OXFW driver has control elements comes from old firewire-speakers driver. Adding the elements is in a file names as 'oxfw-control.c', while the elements are really model-specific. The name is confusing because it gives an idea to handle control elements for all of OXFW-based models. This commit renames the file so that it's just for models supported by old firewire-speakers driver. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Intel Atom processors seem to have a problem at recording when bdl_pos_adj is set to an odd value. When a value like 1 is used, it may drop the samples unexpectedly. Actually, for the old Atoms, we used to set AZX_DRIVER_SCH type, and this assigns 32 as default. Meanwhile the newer chips, Baytrail and Braswell, are set as AZX_DRIVER_PCH, and the lower default value, 1, is assigned. This patch changes the default values for these chipsets to a safer default, 32, again. Since changing the driver type (AZX_DRIVER_XXX) leads to the rename of the driver string, it would result in a possible regression. So, we can't change the type. Instead, in this patch, manual (ugly) PCI ID checks are added on top. A drawback by this increase is the slight increase of the latency, but it's a sub-ms order in normal situations, so mostly negligible. Reported-and-tested-by: Jochen Henneberg <jh@henneberg-systemdesign.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Just a minor cleanup; instead of passing an array, pass the assigned bdl_pos_adj option value directory in struct azx. Also split the code to get the default bdl_pos_adj value for the change that will follow after this. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 11 Dec, 2015 1 commit
-
-
Julia Lawall authored
The usb_protocol_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 10 Dec, 2015 3 commits
-
-
Takashi Iwai authored
The recent commit [e90247f9: ALSA: hda - Split ELD update code from hdmi_present_sense()] rewrote the HDMI jack handling code, but a slight behavior change sneaked in unexpectedly. When the jack isn't connected, it tries repoll unnecessarily. This patch addresses the flaw, to the right behavior as before. Fixes: e90247f9 ('ALSA: hda - Split ELD update code from hdmi_present_sense()') Reported-and-tested-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Due to the recent change, HDA controller driver for Intel PCH tries to bind i915 audio component always at the probe time no matter whether HDMI/DP codec is found. This is, however, superflulous for old chipsets (e.g. on IVB) where they don't have always the HDMI/DP codecs but often have only a discrete GPU instead. For the newer chipsets, we need already the i915 binding from the beginning due to power well control. Meanwhile, for older chipsets where we don't need power well, we don't need the i915 binding at the controller level. This patch removes again the i915 binding in the HDA controller driver for old Intel PCHs, but adds the binding in HDMI/DP codec driver instead. This allows still the use of the direct notification from the graphics driver while we can avoid the unnecessary load of i915 driver for machines only with another GPU. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The audio component is enabled only when CONFIG_SND_HDA_I915 is set. Give a dummy macro for allowing the compiler optimize out the relevant codes when this Kconfig isn't set. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 09 Dec, 2015 3 commits
-
-
Arnd Bergmann authored
The OSS sound drivers used to rely on virt_to_bus(), but don't any more, so we can remove the Kconfig dependency. As a lot of architectures don't provide VIRT_TO_BUS any more, removing the dependency in sounds/oss/ would make the deprecated drivers appear there, which we probably don't want. Instead I'm replacing the simple dependency with 'VIRT_TO_BUS || RPC || NETWINDER' so we can still build these sound drivers for the platforms that need them, but don't change anything on other architectures. As a follow-up, we can remove the virt_to_bus() implementation and Kconfig symbol in the ARM architecture. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
snd-hda-intel driver tries to bind with i915 audio component always when AZX_DCAPS_I915_POWERWELL is set in the driver caps. This was mostly OK in the past, as the flag was applied only to a limited set of devices, namely, Haswell and Broadwell. On these machines, i915 graphics is almost mandatory as long as HDMI/DP is concerned. Recently the application of i915 binding was widened to more Intel chips. On these chips, the chance of a kernel without i915 graphics is much higher, and such user would hit an error like: snd_hda_intel 0000:00:1b.0: failed to add i915 component master (-19) Although the error itself is harmless, it's certainly superfluous even to try binding with i915, if we already know that there isn't any. This patch fixes it by simply defining AZX_DCAPS_I915_POWERWELL as 0 in the case without i915. Then all codes referring to this flag will be optimized out by the compiler. Fixes: 6603249d ('ALSA: hda - Enable audio component for old Intel PCH devices') Reported-by: kernel test robot <ying.huang@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The recent commit [6603249d: ALSA: hda - Enable audio component for old Intel PCH devices] enabled the i915 binding for HDMI/DP on old Intel PCHs. But many boards are without HDMI/DP, and they actually don't need i915 binding, and yet the driver has a check of i915 binding and complains like Haswell must be built with CONFIG_SND_HDA_I915 This error is false-positive, and it should be put only for HSW/BDW, instead of all devices that may be bound with i915. This patch fixes the condition to check, as well as rephrasing the message specific to HSW/BDW HDMI/DP. Fixes: 6603249d ('ALSA: hda - Enable audio component for old Intel PCH devices') Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 08 Dec, 2015 3 commits
-
-
Takashi Iwai authored
Many codecs, typically found on Realtek codecs, have the analog loopback path merged to the secondary input of the middle of the output paths. Currently, we don't offer the dynamic switching in such configuration but let each loopback path mute by itself. This should work well in theory, but in reality, we often see that such a dead loopback path causes some background noises even if all the elements get muted. Such a problem has been fixed by adding the quirk accordingly to disable aamix, and it's the right fix, per se. The only problem is that it's not so trivial to achieve it; user needs to pass a hint string via patch module option or sysfs. This patch gives a bit improvement on the situation: it adds "Loopback Mixing" control element for such codecs like other codecs (e.g. IDT or VIA codecs) with the individual loopback paths. User can turn on/off the loopback path simply via a mixer app. For keeping the compatibility, the loopback is still enabled on these codecs. But user can try to turn it off if experiencing a suspicious background or click noise on the fly, then build a static fixup later once after the problem is addressed. Other than the addition of the loopback enable/disablement control, there should be no changes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
An exported function snd_hda_parse_nid_path() is used only inside hda_generic.c. Let's make it a static local function for a better code optimization. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
An exported helper function snd_hda_get_nid_path() is nowhere used. Let's remove it. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 07 Dec, 2015 1 commit
-
-
Ravindra Lokhande authored
Compress offload does not support ioctl calls from a 32bit userspace in a 64 bit kernel. This patch adds support for ioctls from a 32bit userspace in a 64bit kernel Signed-off-by: Ravindra Lokhande <rlokhande@nvidia.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 04 Dec, 2015 3 commits
-
-
Takashi Iwai authored
As i915 graphics driver provides the notification via audio component, not only the currently implemented HSW+ and VLV+ platforms but also all other PCH-based platforms (e.g. Cougar Point, Panther Point, etc) can use this infrastructure. It'll improve the reliability and the power consumption significantly, especially once when we implement the ELD notification via component. As a preliminary, this patch enables the usage of audio component for all PCH platforms. The HDA controller just needs to set AZX_DCAPS_I915_POWERWELL flag appropriately. The name of the flag is a bit confusing, but this actually works even on the chips without the powerwell but accesses only the other component ops. In the HDMI/DP codec driver side, we just need to register/unregister the notifier for such chips. This can be identified by checking the audio_component field in the assigned hdac_bus. One caveat is that PCH for Haswell and Broadwell must not be bound with i915 audio component, as there are dedicated HD-audio HDMI controllers on these platforms. Ditto for Poulsbo and Oaktrail as they use gma500 graphics, not i915. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
This is a preliminary patch for the later change to support ELD/jack handling with i915 audio component. This splits the ELD update code from hdmi_present_sense() so that it can be called from other places. Just a code refactoring, no functional change. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Instead of doing in each caller side, snd_hdmi_parse_eld() does zero-clear of the parsed data by itself. This is safer and simplifies the upcoming code changes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 03 Dec, 2015 4 commits
-
-
Takashi Iwai authored
The ALSA PCM, mixer and sequencer OSS emulations provide the 32bit compatible ioctl, but they just call the 64bit native ioctl as is. Although this works in most cases, passing the argument value as-is isn't guaranteed to work on all architectures. We need to convert it via compat_ptr() instead. This patch addresses the missing conversions. Since all relevant ioctls in these functions take the argument as a pointer, we do the pointer conversion in each compat_ioctl and pass it as a 64bit value to the native ioctl. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The ELD notification can be received asynchronously from the graphics side, and this may happen just at the moment the sound driver is processing the suspend or the resume, and it would confuse the whole procedure. Since the ELD and connection states are updated in anyway at the end of the resume, we can skip it when received during PM process. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
-
David Henningsson authored
I've tested it on one device and it works fine, no clicks. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 02 Dec, 2015 1 commit
-
-
Colin Ian King authored
minor change, indenting is one tab out. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 01 Dec, 2015 2 commits
-
-
Takashi Iwai authored
It's supposed to be equivalent with CX20724. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The numbers aren't always linear, just like in the real world. Correct to the right numbers stated in the datasheet (although we can't trust the datasheet as well). Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 30 Nov, 2015 4 commits
-
-
Richard Fitzgerald authored
Make snd_compress_new take an id string (like snd_pcm_new). This string can be included in the procfs info. This patch also updates soc_new_compress() to create an ID based on the stream and dai name, as done for PCM streams. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Richard Fitzgerald authored
This patch implements a procfs info file for compr nodes when SND_VERBOSE_PROCFS is enabled. This is equivalent to what the PCM core already does for pcm nodes. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Julia Lawall authored
The snd_i2c_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Julia Lawall authored
The action_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 27 Nov, 2015 3 commits
-
-
Takashi Iwai authored
The recent addition of ELD notifier for Intel HDMI/DP codec may lead the bad codec connection found as kernel messages like below: Suspending console(s) (use no_console_suspend to debug) hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1 snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 .... snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00 azx_single_wait_for_response: 42 callbacks suppressed This seems appearing when the sound driver went to suspend before i915 driver. Then i915 driver disables HDMI/DP audio bit and calls the registered notifier, and the HDA codec tries to handle it as a hot(un)plug. But since the driver is already in the suspended state, it fails miserably. As this is a sort of spurious wakeup, it can be ignored safely, as long as it's delivered during the system suspend. OTOH, if a notification comes during the runtime suspend, the situation is different: we need to wake up. But during the system suspend, such a notification can't be the reason for a wakeup. This patch addresses it by a simple check of the current sound card status. The skipped notification doesn't matter because the HDA driver will check the plugged status forcibly at the resume in return. Then, why the card status, not a runtime PM status or else? The HDA controller driver is supposed to set the card status to D3 at the system suspend but not at the runtime suspend. So we can see it as a flag that is set only for the system suspend. Admittedly, it's a bit ugly, but it should work well for now. Reported-and-tested-by: "Zhang, Xiong Y" <xiong.y.zhang@intel.com> Fixes: 25adc137 ('ALSA: hda - Wake the codec up on pin/ELD notify events') Cc: <stable@vger.kernel.org> # v4.3+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
-
Takashi Iwai authored
Merge tag 'asoc-fix-v4.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.4 Quite a large batch of fixes have come in since the merge window, mainly driver specific ones but there's a couple of core ones: - A fix for DAPM resume on active streams to ensure everything ends up cleanly in the right state. - Reset the DAPM cache when freeing widgets to fix a crash on driver remove and reload. The PM functions for nau8825 are new code which fix crashes on resume.
-
- 25 Nov, 2015 9 commits
-
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/rt5677', 'asoc/fix/st', 'asoc/fix/sun4i-codec', 'asoc/fix/topology', 'asoc/fix/wm8960' and 'asoc/fix/wm8962' into asoc-linus
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/nau8825', 'asoc/fix/ops', 'asoc/fix/rcar', 'asoc/fix/rl6231', 'asoc/fix/rockchip' and 'asoc/fix/rt5670' into asoc-linus
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/davinci', 'asoc/fix/es8328', 'asoc/fix/fsl', 'asoc/fix/fsl-sai' and 'asoc/fix/intel' into asoc-linus
-
Mark Brown authored
-
Mark Brown authored
-
Mark Brown authored
-
Jeeja KP authored
For DAPM resume, we should first change the power state of the card and then recheck the endpoints. This ensures the dapm is resumed first and then userspace can resume the streams. Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Randy Dunlap authored
Fix kernel-doc warnings in soc-ops.c: ..//sound/soc/soc-ops.c:415: warning: No description found for parameter 'ucontrol' ..//sound/soc/soc-ops.c:415: warning: Excess function parameter 'uinfo' description in 'snd_soc_put_volsw_sx' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Bard Liao authored
Add platform specific data for Terra project. Signed-off-by: Luke_Yin@asus.com <Luke_Yin@asus.com> Signed-off-by: Bard Liao <bardliao@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-