- 03 9月, 2019 1 次提交
-
-
由 Jian-Hong Pan 提交于
Original pin node values of ASUS UX431FL with ALC294: 0x12 0xb7a60140 0x13 0x40000000 0x14 0x90170110 0x15 0x411111f0 0x16 0x411111f0 0x17 0x90170111 0x18 0x411111f0 0x19 0x411111f0 0x1a 0x411111f0 0x1b 0x411111f0 0x1d 0x4066852d 0x1e 0x411111f0 0x1f 0x411111f0 0x21 0x04211020 1. Has duplicated internal speakers (0x14 & 0x17) which makes the output route become confused. So, the output volume cannot be changed by setting. 2. Misses the headset mic pin node. This patch disables the confusing speaker (NID 0x14) and enables the headset mic (NID 0x19). Link: https://lore.kernel.org/r/20190902100054.6941-1-jian-hong@endlessm.comSigned-off-by: NJian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 02 9月, 2019 1 次提交
-
-
由 Sam Bazley 提交于
HP Pavilion 15 (AMD Ryzen-based model) with 103c:84e7 needs the same quirk like HP Envy/Spectre x360 for enabling the mute LED over Mic3 pin. [ rearranged in the SSID number order by tiwai ] Signed-off-by: NSam Bazley <sambazley@fastmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 30 8月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
The recent change to shuffle the codec initialization procedure for Realtek via commit 607ca3bd ("ALSA: hda/realtek - EAPD turn on later") caused the silent output on some machines. This change was supposed to be safe, but it isn't actually; some devices have quirk setups to override the EAPD via COEF or BTL in the additional verb table, which is applied at the beginning of snd_hda_gen_init(). And this EAPD setup is again overridden in alc_auto_init_amp(). For recovering from the regression, tell snd_hda_gen_init() not to apply the verbs there by a new flag, then apply the verbs in alc_init(). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727 Fixes: 607ca3bd ("ALSA: hda/realtek - EAPD turn on later") Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 29 8月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
Since the chained quirks via chained_before flag is applied before the depth check, it may lead to the endless recursive calls, when the chain were set up incorrectly. Fix it by moving the depth check at the beginning of the loop. Fixes: 1f578250 ("ALSA: hda - Add chained_before flag to the fixup entry") Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 26 8月, 2019 1 次提交
-
-
由 Takashi Sakamoto 提交于
When userspace application calls ioctl(2) to configure hardware for PCM playback substream, ALSA OXFW driver handles incoming AMDTP stream. In this case, outgoing AMDTP stream should be handled. This commit fixes the bug for v5.3-rc kernel. Fixes: 4f380d00 ("ALSA: oxfw: configure packet format in pcm.hw_params callback") Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 25 8月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
The input pool of a client might be deleted via the resize ioctl, the the access to it should be covered by the proper locks. Currently the only missing place is the call in snd_seq_ioctl_get_client_pool(), and this patch papers over it. Reported-by: syzbot+4a75454b9ca2777f35c7@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 22 8月, 2019 2 次提交
-
-
由 Takashi Iwai 提交于
The bmControls (for UAC1) or bmMixerControls (for UAC2/3) bitmap has a variable size depending on both input and output pins. Its size is to fit with input * output bits. The problem is that the input size can't be determined simply from the unit descriptor itself but it needs to parse the whole connected sources. Although the uac_mixer_unit_get_channels() tries to check some possible overflow of this bitmap, it's incomplete due to the lack of the evaluation of input pins. For covering possible overflows, this patch adds the bitmap overflow check in the loop of input pins in parse_audio_mixer_unit(). Fixes: 0bfe5e43 ("ALSA: usb-audio: Check mixer unit descriptors more strictly") Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
I forgot to release the allocated object at the early error path in line6_init_pcm(). For addressing it, slightly shuffle the code so that the PCM destructor (pcm->private_free) is assigned properly before all error paths. Fixes: 34501219 ("ALSA: line6: Fix write on zero-sized buffer") Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 21 8月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
The quirk function snd_emuusb_set_samplerate() has a NULL check for the mixer element, but this is useless in the current code. It used to be a check against mixer->id_elems[unitid] but it was changed later to the value after mixer_eleme_list_to_info() which is always non-NULL due to the container_of() usage. This patch fixes the check before the conversion. While we're at it, correct a typo in the comment in the function, too. Fixes: 8c558076 ("ALSA: usb-audio: Clean up mixer element list traverse") Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 20 8月, 2019 3 次提交
-
-
由 Paweł Rekowski 提交于
This patch adds a new PCI subsys ID for the SBZ, as found and tested by me and some reddit users. Link: https://lore.kernel.org/lkml/20190819204008.14426-1-p.rekowski@gmail.comSigned-off-by: NPaweł Rekowski <p.rekowski@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Behringer UFX1604 requires the similar quirk to apply implicit fb like another Behringer model UFX1204 in order to fix the noisy playback. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204631 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Jeronimo Borque 提交于
"enabled" parameter historically referred to the device input or output, not to the led indicator. After the changes added with the led helper functions the mic mute led logic refers to the led and not to the mic input which caused led indicator to be negated. Fixing logic in cxt_update_gpio_led and updated cxt_fixup_gpio_mute_hook Also updated debug messages to ease further debugging if necessary. Fixes: 184e302b ("ALSA: hda/conexant - Use the mic-mute LED helper") Suggested-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NJeronimo Borque <jeronimo@borque.com.ar> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 16 8月, 2019 1 次提交
-
-
由 Hui Peng 提交于
`check_input_term` recursively calls itself with input from device side (e.g., uac_input_terminal_descriptor.bCSourceID) as argument (id). In `check_input_term`, if `check_input_term` is called with the same `id` argument as the caller, it triggers endless recursive call, resulting kernel space stack overflow. This patch fixes the bug by adding a bitmap to `struct mixer_build` to keep track of the checked ids and stop the execution if some id has been checked (similar to how parse_audio_unit handles unitid argument). Reported-by: NHui Peng <benquike@gmail.com> Reported-by: NMathias Payer <mathias.payer@nebelwelt.net> Signed-off-by: NHui Peng <benquike@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 15 8月, 2019 1 次提交
-
-
由 Hui Peng 提交于
The `uac_mixer_unit_descriptor` shown as below is read from the device side. In `parse_audio_mixer_unit`, `baSourceID` field is accessed from index 0 to `bNrInPins` - 1, the current implementation assumes that descriptor is always valid (the length of descriptor is no shorter than 5 + `bNrInPins`). If a descriptor read from the device side is invalid, it may trigger out-of-bound memory access. ``` struct uac_mixer_unit_descriptor { __u8 bLength; __u8 bDescriptorType; __u8 bDescriptorSubtype; __u8 bUnitID; __u8 bNrInPins; __u8 baSourceID[]; } ``` This patch fixes the bug by add a sanity check on the length of the descriptor. Reported-by: NHui Peng <benquike@gmail.com> Reported-by: NMathias Payer <mathias.payer@nebelwelt.net> Cc: <stable@vger.kernel.org> Signed-off-by: NHui Peng <benquike@gmail.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 14 8月, 2019 2 次提交
-
-
由 Hui Wang 提交于
Make codec enter D3 before rebooting or poweroff can fix the noise issue on some laptops. And in theory it is harmless for all codecs to enter D3 before rebooting or poweroff, let us add a generic reboot_notify, then realtek and conexant drivers can call this function. Cc: stable@vger.kernel.org Signed-off-by: NHui Wang <hui.wang@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Hui Wang 提交于
We have 3 new lenovo laptops which have conexant codec 0x14f11f86, these 3 laptops also have the noise issue when rebooting, after letting the codec enter D3 before rebooting or poweroff, the noise disappers. Instead of adding a new ID again in the reboot_notify(), let us make this function apply to all conexant codec. In theory make codec enter D3 before rebooting or poweroff is harmless, and I tested this change on a couple of other Lenovo laptops which have different conexant codecs, there is no side effect so far. Cc: stable@vger.kernel.org Signed-off-by: NHui Wang <hui.wang@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 13 8月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
HP Envy x360 (AMD Ryzen-based model) with 103c:8497 needs the same quirk like HP Spectre x360 for enabling the mute LED over Mic3 pin. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204373 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 10 8月, 2019 1 次提交
-
-
由 Wenwen Wang 提交于
In snd_hda_parse_generic_codec(), 'spec' is allocated through kzalloc(). Then, the pin widgets in 'codec' are parsed. However, if the parsing process fails, 'spec' is not deallocated, leading to a memory leak. To fix the above issue, free 'spec' before returning the error. Fixes: 352f7f91 ("ALSA: hda - Merge Realtek parser code to generic parser") Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 09 8月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
MSI MPG X570 board is with another AMD HD-audio controller (PCI ID 1022:1487) and it requires the same workaround applied for X370, etc (PCI ID 1022:1457). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 08 8月, 2019 2 次提交
-
-
由 Wenwen Wang 提交于
In iso_packets_buffer_init(), 'b->packets' is allocated through kmalloc_array(). Then, the aligned packet size is checked. If it is larger than PAGE_SIZE, -EINVAL will be returned to indicate the error. However, the allocated 'b->packets' is not deallocated on this path, leading to a memory leak. To fix the above issue, free 'b->packets' before returning the error code. Fixes: 31ef9134 ("ALSA: add LaCie FireWire Speakers/Griffin FireWave Surround driver") Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu> Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Cc: <stable@vger.kernel.org> # v2.6.39+ Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Wenwen Wang 提交于
In sound_insert_unit(), the controlling structure 's' is allocated through kmalloc(). Then it is added to the sound driver list by invoking __sound_insert_unit(). Later on, if __register_chrdev() fails, 's' is removed from the list through __sound_remove_unit(). If 'index' is not less than 0, -EBUSY is returned to indicate the error. However, 's' is not deallocated on this execution path, leading to a memory leak bug. To fix the above issue, free 's' before -EBUSY is returned. Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 07 8月, 2019 2 次提交
-
-
由 Takashi Iwai 提交于
A long-time problem on the recent AMD chip (X370, X470, B450, etc with PCI ID 1022:1457) with Realtek codecs is the crackled or distorted sound for capture streams, as well as occasional playback hiccups. After lengthy debugging sessions, the workarounds we've found are like the following: - Set up the proper driver caps for this controller, similar as the other AMD controller. - Correct the DMA position reporting with the fixed FIFO size, which is similar like as workaround used for VIA chip set. - Even after the position correction, PulseAudio still shows mysterious stalls of playback streams when a capture is triggered in timer-scheduled mode. Since we have no clear way to eliminate the stall, pass the BATCH PCM flag for PA to suppress the tsched mode as a temporary workaround. This patch implements the workarounds. For the driver caps, it defines a new preset, AXZ_DCAPS_PRESET_AMD_SB. It enables the FIFO- corrected position reporting (corresponding to the new position_fix=6) and enforces the SNDRV_PCM_INFO_BATCH flag. Note that the current implementation is merely a workaround. Hopefully we'll find a better alternative in future, especially about removing the BATCH flag hack again. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Wenwen Wang 提交于
In hiface_pcm_init(), 'rt' is firstly allocated through kzalloc(). Later on, hiface_pcm_init_urb() is invoked to initialize 'rt->out_urbs[i]'. In hiface_pcm_init_urb(), 'rt->out_urbs[i].buffer' is allocated through kzalloc(). However, if hiface_pcm_init_urb() fails, both 'rt' and 'rt->out_urbs[i].buffer' are not deallocated, leading to memory leak bugs. Also, 'rt->out_urbs[i].buffer' is not deallocated if snd_pcm_new() fails. To fix the above issues, free 'rt' and 'rt->out_urbs[i].buffer'. Fixes: a91c3fb2 ("Add M2Tech hiFace USB-SPDIF driver") Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 06 8月, 2019 5 次提交
-
-
由 Takashi Iwai 提交于
The commit bfcba288 ("ALSA - hda: Add support for link audio time reporting") introduced the conditional PCM hw info setup, but it overwrites the global azx_pcm_hw object. This will cause a problem if any other HD-audio controller, as it'll inherit the same bit flag although another controller doesn't support that feature. Fix the bug by setting the PCM hw info flag locally. Fixes: bfcba288 ("ALSA - hda: Add support for link audio time reporting") Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Wenwen Wang 提交于
In snd_usb_get_audioformat_uac3(), a structure for channel maps 'chmap' is allocated through kzalloc() before the execution goto 'found_clock'. However, this structure is not deallocated if the memory allocation for 'pd' fails, leading to a memory leak bug. To fix the above issue, free 'fp->chmap' before returning NULL. Fixes: 7edf3b5e ("ALSA: usb-audio: AudioStreaming Power Domain parsing") Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Merge tag 'asoc-fix-v5.3-rc3-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.3 Incremental fix removing executable bits added in a prior patch accidentally.
-
由 Takashi Iwai 提交于
Merge tag 'asoc-fix-v5.3-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.3 A relatively large batch of mostly unremarkable fixes here, a couple of small core fixes for fairly obscure issues, more comment/email updates with no code impact than usual and a bunch of small driver fixes. The support for new sample rates in the max98373 driver is a fix for the fact that the driver declared support for those rates but would in fact return an error if these rates were selected.
-
由 Mark Brown 提交于
Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 03 8月, 2019 2 次提交
-
-
由 Vijendar Mukunda 提交于
We shouldn't assume CPU physical address we get from page_to_phys() is same as DMA address we get from dma_alloc_coherent(). On x86_64, we won't run into any problem with the assumption when dma_ops is nommu_dma_ops. However, DMA address is IOVA when IOMMU is enabled. And it's most likely different from CPU physical address when AMD IOMMU is not in passthrough mode. This patch fixes page faults when IOMMU is enabled. Signed-off-by: NVijendar Mukunda <vijendar.mukunda@amd.com> Link: https://lore.kernel.org/r/1564753899-17124-2-git-send-email-Vijendar.Mukunda@amd.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Vijendar Mukunda 提交于
AMD platform device acp3x_rv_i2s created by parent PCI device driver. Pass struct device of the parent to snd_pcm_lib_preallocate_pages() so dma_alloc_coherent() can use correct dma_ops. Otherwise, it will use default dma_ops which is nommu_dma_ops on x86_64 even when IOMMU is enabled and set to non passthrough mode. Signed-off-by: NVijendar Mukunda <vijendar.mukunda@amd.com> Link: https://lore.kernel.org/r/1564753899-17124-1-git-send-email-Vijendar.Mukunda@amd.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 31 7月, 2019 3 次提交
-
-
由 fengchunguo 提交于
88200 and 96000 sampling rate was not enabled on driver, so can't be played. The error information: max98373 3-0031:rate 96000 not supported max98373 3-0031:ASoC: can't set max98373-aif1 hw params: -22 Signed-off-by: Nfengchunguo <chunguo.feng@amlogic.com> Link: https://lore.kernel.org/r/20190731074156.5620-1-chunguo.feng@amlogic.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Marcus Cooper 提交于
The A64 audio codec uses the original I2S block but the SR and WSS computation currently assigned is for the newer block. Fixes: 619c15f7 (ASoC: sun4i-i2s: Change SR and WSS computation) Signed-off-by: NMarcus Cooper <codekipper@gmail.com> Link: https://lore.kernel.org/r/20190729152130.27955-1-codekipper@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Cezary Rojewski 提交于
Adding myself to Intel ASoC drivers maintainers list. Signed-off-by: NCezary Rojewski <cezary.rojewski@intel.com> Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190726181517.27655-1-cezary.rojewski@intel.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 30 7月, 2019 2 次提交
-
-
由 Hillf Danton 提交于
syzbot found the following crash on: general protection fault: 0000 [#1] SMP KASAN RIP: 0010:snd_usb_pipe_sanity_check+0x80/0x130 sound/usb/helper.c:75 Call Trace: snd_usb_motu_microbookii_communicate.constprop.0+0xa0/0x2fb sound/usb/quirks.c:1007 snd_usb_motu_microbookii_boot_quirk sound/usb/quirks.c:1051 [inline] snd_usb_apply_boot_quirk.cold+0x163/0x370 sound/usb/quirks.c:1280 usb_audio_probe+0x2ec/0x2010 sound/usb/card.c:576 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 really_probe+0x281/0x650 drivers/base/dd.c:548 .... It was introduced in commit 801ebf10 for checking pipe and endpoint types. It is fixed by adding a check of the ep pointer in question. BugLink: https://syzkaller.appspot.com/bug?extid=d59c4387bfb6eced94e2Reported-by: Nsyzbot <syzbot+d59c4387bfb6eced94e2@syzkaller.appspotmail.com> Fixes: 801ebf10 ("ALSA: usb-audio: Sanity checks for each pipe and EP types") Cc: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: NHillf Danton <hdanton@sina.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Yuki Tsunashima 提交于
lost wakeup can occur after enabling irq, therefore put task into interruptible before enabling interrupts, without this change, task can be put to sleep and snd_pcm_drain will delay Fixes: f2b3614c ("ALSA: PCM - Don't check DMA time-out too shortly") Signed-off-by: NYuki Tsunashima <ytsunashima@jp.adit-jv.com> Signed-off-by: NSuresh Udipi <sudipi@jp.adit-jv.com> [ported from 4.9] Signed-off-by: NAdam Miartus <amiartus@de.adit-jv.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 27 7月, 2019 1 次提交
-
-
由 Samuel Thibault 提交于
Distribution installation images such as Debian include different sets of modules which can be downloaded dynamically. Such images may notably include the hda sound modules but not the i915 DRM module, even if the latter was enabled at build time, as reported on https://bugs.debian.org/931507 In such a case hdac_i915 would be linked in and try to load the i915 module, fail since it is not there, but still wait for a whole minute before giving up binding with it. This fixes such as case by only waiting for the binding if the module was properly loaded (or module support is disabled, in which case i915 is already compiled-in anyway). Fixes: f9b54e19 ("ALSA: hda/i915: Allow delayed i915 audio component binding") Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 26 7月, 2019 4 次提交
-
-
由 Peter Ujfalusi 提交于
The slot_width is a property for the bus while the constraint for SNDRV_PCM_HW_PARAM_SAMPLE_BITS is for the in memory format. Applying slot_width constraint to sample_bits works most of the time, but it will blacklist valid formats in some cases. With slot_width 24 we can support S24_3LE and S24_LE formats as they both look the same on the bus, but a a 24 constraint on sample_bits would not allow S24_LE as it is stored in 32bits in memory. Implement a simple hw_rule function to allow all formats which require less or equal number of bits on the bus as slot_width (if configured). Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20190726064244.3762-2-peter.ujfalusi@ti.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Cheng-Yi Chiang 提交于
This reverts commit db51707b. Revert "ASoC: rockchip: i2s: Support mono capture" Previous discussion in https://patchwork.kernel.org/patch/10147153/ explains the issue of the patch. While device is configured as 1-ch, hardware is still generating a 2-ch stream. When user space reads the data and assumes it is a 1-ch stream, the rate will be slower by 2x. Revert the change so 1-ch is not supported. User space can selectively take one channel data out of two channel if 1-ch is preferred. Currently, both channels record identical data. Signed-off-by: NCheng-Yi Chiang <cychiang@chromium.org> Link: https://lore.kernel.org/r/20190726044202.26866-1-cychiang@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Christophe JAILLET 提交于
Fix some typo to have the filaname given in a comment match the real name of the file. Some 'acpi' have erroneously been written 'apci' Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20190725053523.16542-1-christophe.jaillet@wanadoo.frSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Peter Ujfalusi 提交于
When running McASP as master capture alone will not record any audio unless a parallel playback stream is running. As soon as the playback stops the captured data is going to be silent again. In McASP master mode we need to set the PDIR for the clock pins and fix the mcasp_set_axr_pdir() to skip the bits in the PDIR registers above AMUTE. This went unnoticed as most of the boards uses McASP as slave and neither of these issues are visible (audible) in those setups. Fixes: ca3d9433 ("ASoC: davinci-mcasp: Update PDIR (pin direction) register handling") Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20190725083423.7321-1-peter.ujfalusi@ti.comSigned-off-by: NMark Brown <broonie@kernel.org>
-