- 04 Mar, 2016 3 commits
-
-
Takashi Iwai authored
Resolved the conflicts with the latest HDA HDMI fixes. Signed-off-by:Takashi Iwai <tiwai@suse.de>
-
Libin Yang authored
Defer to register acomp eld notifier until hdmi audio driver is fully ready. After registering eld notifier, gfx driver can use this callback function to notify audio driver the monitor connection event. However this action may happen when audio driver is adding the pins or doing other initialization. This is not always safe, however. For example, using per_pin->lock before the lock is initialized. Let's register the eld notifier after the initialization is done. Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
-
Libin Yang authored
To make sure audio_ptr is set before intel_audio_codec_enable() or intel_audio_codec_disable() calling pin_eld_notify(), this patch adds wmb barrier to prevent optimizing. Signed-off-by:
-
- 03 Mar, 2016 1 commit
-
-
Simon South authored
This patch applies the microphone-related fix created for the Acer Aspire E1-572 to the E1-472 as well, as it uses the same Realtek ALC282 CODEC and demonstrates the same issues. This patch allows an external, headset microphone to be used and limits the gain on the (quite noisy) internal microphone. Signed-off-by:
Simon South <simon@simonsouth.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 02 Mar, 2016 1 commit
-
-
Sudip Mukherjee authored
While registering pardev, the irq_func was also registered. As a result when we tried to probe for the card, an interrupt was generated and in the ISR we tried to dereference private_data. But private_data is still NULL as we have not yet done portman_create(). Lets probe for the device after card is created. Fixes: e6a1b7e8 ("ALSA: portman2x4 - use new parport device model") Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
- 01 Mar, 2016 3 commits
-
-
Takashi Iwai authored
The OSS sequencer client tries to drain the pending events at releasing. Unfortunately, as spotted by syzkaller fuzzer, this may lead to an unkillable process state when the event has been queued at the far future. Since the process being released can't be signaled any longer, it remains and waits for the echo-back event in that far future. Back to history, the draining feature was implemented at the time we misinterpreted POSIX definition for blocking file operation. Actually, such a behavior is superfluous at release, and we should just release the device as is instead of keeping it up forever. This patch just removes the draining call that may block the release for too long time unexpectedly. BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.comReported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Dennis Kadioglu authored
Plantronics DA45 does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x4" and "cannot get freq at ep 0x84". This patch adds the USB ID of the DA45 to quirks.c and avoids those error messages. Signed-off-by:
Dennis Kadioglu <denk@post.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Libin Yang authored
hdmi_find_pcm_slot return -EBUSY when not no pcm slot found, not -ENODEV. So the caller should compare with -EBUSY. Fixes: a76056f2 ('ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug') Signed-off-by:
-
- 29 Feb, 2016 6 commits
-
-
Takashi Iwai authored
snd-hdsp driver accesses enum item values (int) instead of boolean values (long) wrongly for some ctl elements. This patch fixes them. Cc: <stable@vger.kernel.org> Signed-off-by: -
Takashi Iwai authored
HDSPM driver contains a code issuing zero-division potentially in system sample rate ctl code. This patch fixes it by not processing a zero or invalid rate value as a divisor, as well as excluding the invalid value to be passed via the given ctl element. Cc: <stable@vger.kernel.org> Signed-off-by: -
Takashi Iwai authored
snd-hdspm driver accesses enum item values (int) instead of boolean values (long) wrongly for some ctl elements. This patch fixes them. Cc: <stable@vger.kernel.org> Signed-off-by: -
Takashi Iwai authored
SNDRV_SEQ_IOCTL_{GET|SET}_QUEUE_OWNER and *_{GET|SET}_QUEUE_SYNC ioctls have been never implemented. Get rid of the definitions from uapi header file. Signed-off-by: -
Takashi Iwai authored
Back-merge of for-linus branch for further API/ABI cleanups.
-
Sudip Mukherjee authored
While registering pardev, the irq_func was also registered. As a result when we tried to probe for the card, an interrupt was generated and in the ISR we tried to dereference private_data. But private_data is still NULL as we have not yet done snd_mts64_create(). Lets probe for the card after mts64 is created. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Fixes: 94a57350 ("ALSA: mts64: use new parport device model") Signed-off-by:
-
- 28 Feb, 2016 7 commits
-
-
Takashi Iwai authored
X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes incompatible with IA32. This results in NOTTY error when the ioctl is issued. Meanwhile, this struct in X32 is essentially identical with the one in X86-64, so we can just bypassing to the existing code for this specific compat ioctl. Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by: -
Takashi Iwai authored
The timer user status compat ioctl returned the bogus struct used for 64bit architectures instead of the 32bit one. This patch addresses it to return the proper struct. Cc: <stable@vger.kernel.org> Signed-off-by: -
Takashi Iwai authored
Like the previous fixes for ctl and PCM, we need a fix for incompatible X32 ABI regarding the rawmidi: namely, struct snd_rawmidi_status has the timespec, and the size and the alignment on X32 differ from IA32. This patch fixes the incompatible ioctl for X32. Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by: -
Takashi Iwai authored
Instead of open-coding, use the existing helper to copy a 32bit timespec from/to 64bit. Signed-off-by: -
Takashi Iwai authored
X32 ABI uses the 64bit timespec in addition to 64bit alignment of 64bit values. This leads to incompatibilities in some PCM ioctls involved with snd_pcm_channel_info, snd_pcm_status and snd_pcm_sync_ptr structs. Fix the PCM compat ABI for these ioctls like the previous commit for ctl API. Reported-by:
Steven Newbury <steve@snewbury.org.uk> Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by:
-
Takashi Iwai authored
The X32 ABI takes the same alignment like x86-64, and this may result in the incompatible struct size from ia32. Unfortunately, we hit this in some control ABI: struct snd_ctl_elem_value differs between them due to the position of 64bit variable array. This ends up with the unknown ioctl (ENOTTY) error. The fix is to add the compat entries for the new aligned struct. Reported-and-tested-by:
-
Takashi Sakamoto authored
This commit drops implementation of duplex streams synchronization from ALSA dice driver, due to a reason of hardware design. This patch allows dice-based units to generate sounds correctly when isochronous packet streaming starts at first time. In IEC 61883-6:2005, CIP packetization layer for AM824 data format utilizes the value of SYT field in CIP header of received packet for a reference to phase lock loop. Figure 3 in clause 4.3 describes it. The value is an offset from cycle_time field of every cycle start packet from cycle master on IEEE 1394 bus. The time calculated with these two fields is called as 'presentation timestamp' which represents the time to play data included in the packet. Although, this idea includes some problems due to accuracy of timekeep in cycle master, accuracy of transmission of cycle start packet on the bus with the other units, accuracy of sampling clock in data transmitter side and accuracy of replay in data receiver side. In most case, these accuracies somewhat worse because there's no such ideal hardwares in this world. For the issues, ASICs for Dice include Jitter Elimination Technologies (JET) PLL. The PLL can handle several sources of clock and compensate it with high-precision internal clock source. The sequence of value in syt field of received AMDTP packets is one of the sources, therefore transmitters on IEEE 1394 bus should transfer it. On the other hand, current ALSA dice driver is programmed with a mode of duplex streams with synchronization. In this mode, the driver outputs packets after some incoming packets are handled, to re-use the value of SYT field in incoming packets to the value for outgoing packets. This mode is enabled when source signal of sampling clock is set to internal, and this is a major use case. Thus, in most cases, the unit receives no packets during a short time after packet streaming starts. As long as I experienced, this causes the units to generate no sounds at first time to receive packets. This issue occurs only with Dice II. I guess this is due to a quirk of the PLL. In short, the PLL cannot generate firm signals to ADCs/DACs or the other ICs when no packets are received in the beginning of packet streaming. While, on second time or later, the unit generates sound correctly. I guess that starting packet streaming at first time sets the PLL correctly. Well, still based on my hypothesis and no way to prove it, this commit drops duplex streams synchronization from this driver. At least, the PLL requires the sequence of value in SYT field of received AMDTP packets as one of source of clock signals with internal clock source. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
- 26 Feb, 2016 3 commits
-
-
Takashi Iwai authored
-
Ville Syrjälä authored
azx_probe_continue() uses pm_runtime_put_noidle() to drop the rpm usage_count, which means that if it's the last reference the autosuspend of the controller won't actually happen. So if the codecs autosuspend before the azx_probe_continue() drops the last reference we'll fail to autosuspend the controller. This does happen in practice, but not every time. As can be seen in [1] the controller autosuspend attempt fails due to the usage_count when suspending the codecs. A bit later we see the the contoller usage_count dropping to zero without further attempts at autosuspend. Fix the problem by using pm_runtime_put_autosuspend() instead, which will kick off the autosuspend of the controller even if the codecs are already asleep. As can be seen in [2] the controller autosuspend still fails while suspending the codecs, but later on we see another autosuspend attempt after dropping the usage_count to 0. I was also a bit worried that there might still be a race between the controller autosuspend and the rest of the code in azx_probe_continue(). So I also tried replacing the the put_noidle() with put_sync_suspend(). No explosions occurred, so I'm somewhat satisfied that there are no serious problems in this area. [1] kworker/1:2-122 [001] .... 63.661310: __pm_runtime_suspend: hdaudioC0D0 usage_count 0 kworker/1:2-122 [001] d..2 63.661316: rpm_suspend: hdaudioC0D0 flags-d cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:2-122 [001] d..1 63.661317: rpm_check_suspend_allowed: hdaudioC0D0 retval 0 kworker/1:2-122 [001] d..2 63.661332: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0 kworker/1:1-72 [001] d..2 63.661543: rpm_suspend: hdaudioC0D0 flags-a cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:1-72 [001] d..1 63.661544: rpm_check_suspend_allowed: hdaudioC0D0 retval 0 kworker/1:1-72 [001] .... 63.661545: hda_codec_runtime_suspend: hdaudioC0D0 suspend kworker/1:1-72 [001] d..2 63.661614: rpm_idle: 0000:00:03.0 flags-1 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:1-72 [001] d..1 63.661615: rpm_check_suspend_allowed: 0000:00:03.0 usage_count 1 kworker/1:1-72 [001] d..1 63.661615: rpm_check_suspend_allowed: 0000:00:03.0 retval -11 kworker/1:1-72 [001] d..2 63.661616: rpm_return_int: rpm_idle+0x249/0x487:0000:00:03.0 ret=-11 kworker/1:1-72 [001] d..2 63.661616: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0 kworker/1:2-122 [001] d..2 63.664834: rpm_idle: hdaudioC0D0 flags-8 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:2-122 [001] d..1 63.664835: rpm_check_suspend_allowed: hdaudioC0D0 retval 1 kworker/1:2-122 [001] d..2 63.664836: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11 kworker/1:2-122 [001] d..2 63.664841: rpm_idle: hdaudioC0D0 flags-8 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:2-122 [001] d..1 63.664841: rpm_check_suspend_allowed: hdaudioC0D0 retval 1 kworker/1:2-122 [001] d..2 63.664841: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11 kworker/1:2-122 [001] .... 63.664842: azx_probe_continue: 0000:00:03.0 usage_count=0 [2] kworker/0:0-4 [000] .... 50.354567: __pm_runtime_suspend: hdaudioC0D0 usage_count 0 kworker/0:0-4 [000] d..2 50.354574: rpm_suspend: hdaudioC0D0 flags-d cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.354575: rpm_check_suspend_allowed: hdaudioC0D0 retval 0 kworker/0:0-4 [000] d..2 50.354589: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0 kworker/0:2-135 [000] d..2 50.354809: rpm_suspend: hdaudioC0D0 flags-a cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:2-135 [000] d..1 50.354810: rpm_check_suspend_allowed: hdaudioC0D0 retval 0 kworker/0:2-135 [000] .... 50.354816: hda_codec_runtime_suspend: hdaudioC0D0 suspend kworker/0:2-135 [000] d..2 50.354908: rpm_idle: 0000:00:03.0 flags-1 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:2-135 [000] d..1 50.354909: rpm_check_suspend_allowed: 0000:00:03.0 usage_count 1 kworker/0:2-135 [000] d..1 50.354909: rpm_check_suspend_allowed: 0000:00:03.0 retval -11 kworker/0:2-135 [000] d..2 50.354909: rpm_return_int: rpm_idle+0x249/0x487:0000:00:03.0 ret=-11 kworker/0:2-135 [000] d..2 50.354910: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0 kworker/0:0-4 [000] d..2 50.373791: rpm_idle: hdaudioC0D0 flags-8 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.373792: rpm_check_suspend_allowed: hdaudioC0D0 retval 1 kworker/0:0-4 [000] d..2 50.373793: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11 kworker/0:0-4 [000] d..2 50.373797: rpm_idle: hdaudioC0D0 flags-8 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.373798: rpm_check_suspend_allowed: hdaudioC0D0 retval 1 kworker/0:0-4 [000] d..2 50.373798: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11 kworker/0:0-4 [000] .... 50.373799: __pm_runtime_suspend: 0000:00:03.0 usage_count 0 kworker/0:0-4 [000] d..2 50.373800: rpm_suspend: 0000:00:03.0 flags-d cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.373800: rpm_check_suspend_allowed: 0000:00:03.0 retval 0 kworker/0:0-4 [000] d..2 50.373803: rpm_return_int: rpm_suspend+0x406/0x5e8:0000:00:03.0 ret=0 kworker/0:0-4 [000] d..2 50.385164: rpm_suspend: 0000:00:03.0 flags-a cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.385165: rpm_check_suspend_allowed: 0000:00:03.0 retval 0 kworker/0:0-4 [000] .... 50.385174: azx_runtime_suspend: 0000:00:03.0 azx suspend releaseing power well kworker/0:0-4 [000] .... 50.385179: azx_runtime_suspend: 0000:00:03.0 azx suspend kworker/0:0-4 [000] d..2 50.386872: rpm_return_int: rpm_suspend+0x406/0x5e8:0000:00:03.0 ret=0 Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Takashi Iwai authored
Currently the interrupt handler of HD-audio driver assumes that no irq update is needed while processing the irq. But in reality, it has been confirmed that the HW irq is issued even during the irq handling. Since we clear the irq status at the beginning, process the interrupt, then exits from the handler, the lately issued interrupt is left untouched without being properly processed. This patch changes the interrupt handler code to loop over the check-and-process. The handler tries repeatedly as long as the IRQ status are turned on, and either stream or CORB/RIRB is handled. For checking the stream handling, snd_hdac_bus_handle_stream_irq() returns a value indicating the stream indices bits. Other than that, the change is only in the irq handler itself. Reported-by:
-
- 25 Feb, 2016 3 commits
-
-
Takashi Iwai authored
HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic working. Also, it suffers from the loopback noise problem, so we should disable aamix path as well. Reported-by:
Derick Eddington <derick.eddington@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
David Henningsson authored
On one of the machines we enable, we found that the actual speaker volume did not always correspond to the volume set in alsamixer. This patch fixes that problem. This patch was orginally written by Kailang @ Realtek, I've rebased it to fit sound git master. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1549660Co-Authored-By:
Kailang <kailang@realtek.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Kai-Heng Feng authored
After login to the desktop on Dell Inspiron 3162, there's a very loud background noise comes from the builtin speaker. The noise does not go away even if the speaker is muted. The noise disappears after using the aamix fixup. Codec: Realtek ALC3234 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0255 Subsystem Id: 0x10280725 Revision Id: 0x100002 No Modem Function Group found BugLink: http://bugs.launchpad.net/bugs/1549620Signed-off-by:Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 24 Feb, 2016 2 commits
-
-
Takashi Sakamoto authored
With a previous commit, ALSA oxfw driver retries transferring MIDI messages at transaction failure for scs1x. On the other hand, there're fatal transaction error. Then, no MIDI messages reach to the unit anymore. In this case, MIDI substream should be terminated. This commit stops MIDI transmission after the fatal error occurs. Unfortunately, unlike ALSA PCM functionality, ALSA rawmidi core has no feature to discontinue MIDI substream runtime in kernel side, thus this commit just stops MIDI transmission without notifying it to userspace. Signed-off-by:
-
Takashi Sakamoto authored
Currently, ALSA oxfw driver has a TODO to retry MIDI transferring at transaction failure. This commit achieves it. Current implementation uses snd_rawmidi_transmit() to transfer messages, thus the target MIDI messages are not in buffer when transaction failure is detected. Although we cannot use a pair of snd_rawmidi_transmit_peek() and snd_ramwidi_transmit_ack(), the messages are still in scs1x specific structure and the data is available for retries. This commit adds a member to the structure for the length of buffered messages, and uses the value again at retries. Signed-off-by:
-
- 23 Feb, 2016 2 commits
-
-
Libin Yang authored
eld control is created based on pcm now. When monitor is connected, eld control will be bound to pin automatically. Signed-off-by:
-
Takashi Iwai authored
Since the recent integration of kctl jack and input jack layers, we can basically build the jack layer even without input devices. That is, the jack layer itself can be built with conditional to enable the input device support or not, while the users may enable always CONFIG_SND_JACK unconditionally. For achieving it, this patch changes the following: - A new Kconfig, CONFIG_SND_JACK_INPUT_DEV, was introduced to indicate whether the jack layer supports the input device, - A few items in snd_jack struct and relevant codes are conditionally built upon CONFIG_SND_JACK_INPUT_DEV, - The users of CONFIG_SND_JACK drop the messy dependency on CONFIG_INPUT. This change also automagically fixes a potential bug in HD-audio driver Arnd reported, where the NULL or uninitialized jack instance is dereferenced. Reported-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
- 22 Feb, 2016 2 commits
-
-
Takashi Iwai authored
Some Skylake machines show the codec probe errors in certain situations, e.g. HP Z240 desktop fails to probe the onboard Realtek codec at reloading the snd-hda-intel module like: snd_hda_intel 0000:00:1f.3: spurious response 0x200:0x2, last cmd=0x000000 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: lastcmd=0x000f0000 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... hdaudio hdaudioC0D2: no AFG or MFG node found snd_hda_intel 0000:00:1f.3: no codecs initialized Also, HP G470 G3 suffers from the similar problem, as reported in bugzilla below. On this machine, the codec probe error appears even at a fresh boot. As Libin suggested, the same workaround used for Broxton in the commit [6639484d: ALSA: hda - disable dynamic clock gating on Broxton before reset] can be applied for Skylake in order to fix this problem. The Intel HW team also confirmed that this is needed for SKL. This patch makes the workaround applied to both SKL and BXT platforms. The referred macros are moved and one superfluous macro (IS_BROXTON()) is another one (IS_BXT()) as well. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112731Suggested-by:
-
Sudip Mukherjee authored
Modify mts64 driver to use the new parallel port device model. The advantage of using the device model is that the driver gets binded to the hardware, we get the feature of hotplug, we can bind/unbind the driver at runtime. The changes are in the way the driver gets registered with the parallel port subsystem and the temporary device to probe mts64 card is removed and mts64_probe() is used in the probe callback. Signed-off-by:
-
- 21 Feb, 2016 1 commit
-
-
Lukas Wunner authored
Use shiny new acpi_dev_present() and remove all the boilerplate to search for a particular ACPI device. No functional change. Cf. 2d12b6b3 ("ACPI / utils: Add acpi_dev_present()"). Signed-off-by:
Lukas Wunner <lukas@wunner.de> Acked-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
- 20 Feb, 2016 5 commits
-
-
Takashi Sakamoto authored
In IEC 61883-1, at bus-reset, applications can continue isochronous streaming by updating connections. In ALSA fireworks driver, the operation is executed in 'update' handler for bus driver. The connection resources are also changed in process contexts of PCM/MIDI applications. Therefore, bus-reset handling has race condition against connection. Current ALSA fireworks driver has a bug for the condition. This commit fixes the bug, by expand critical section with mutex. As a result, connection updating operation in bus-reset handler and connection changing operation in process context are serialized. Signed-off-by:
-
Takashi Sakamoto authored
DM1000/DM1100/DM1500 chipsets transfer packets with discontinue value in 'dbc' field of CIP header. For ALSA bebob driver, this makes its bus-reset handler meaningless, because the discontinuity is detected quite earlier than executing the handler. This commit gives up updating streams at the bus reset handler. Signed-off-by:
-
Takashi Sakamoto authored
The counter is incremented/decremented in critical section protected with mutex. Therefore, no need to use atomic_t. This commit changes the type to unsigned int. Signed-off-by:
-
Takashi Sakamoto authored
Currently, critical section is protected by mutex in functions of fireworks_stream.c. Callers increments/decrements substreams counter before calling the functions. Moving mutex to the callers code allows to change type of the substream counter from atomic_t to unsigned int. This commit is a preparation for obsoleting usage of atomic_t for substream counter. Signed-off-by:
-
Takashi Sakamoto authored
At bus-reset, DM1000/DM1100/DM1500 chipsets transfer packets with discontinuous value in 'dbc' field of CIP header. In this case, packet streaming layer in firewire-lib module stops streaming and set XRUN to PCM substream. In ALSA, PCM applications are notified the XRUN status by the return value of ALSA PCM interface. They can recover this state by executing snd_pcm_prepare(), then PCM drivers' prepare handler is called, and start new PCM substream. For ALSA BeBoB driver, the handler establishes new connections and start new AMDTP streaming. Unfortunately, neither the PCM applications nor the driver know the reason of XRUN. The driver gets to know the reason when update handler is called by IEEE 1394 bus driver. As long as I tested, the order of below events are not fixed: * Detecting packet discontinuity in tasklet context of OHCI 1394 driver * Calling prepare handler in process context of ALSA PCM application * Calling update handler in kthread context of IEEE 1394 bus driver The unpredictable order is disadvantage for the driver to be compliant to CMP. In IEC 61883-1, new CMP establish operations should be done 1 sec (isoc_resource_delay) after bus-reset. Within 1 sec, CMP restore operations are allowed. For this reason, in former commit ('b6bc8123: ALSA: bebob/firewire-lib: Add a quirk for discontinuity at bus reset'), the process context is forced to wait for executing update handler. The process context wait for bus-reset up to 1 sec. This commit solves the issue, while causes more disadvantages. For PCM applications, calling snd_pcm_prepare() for recovering XRUN state takes more time and the driver got a bit complicated code, while the recovery is not always successful. As long as I tested, DM1000/DM1100/DM1500 and BeBoB firmware can allow drivers to establish new connections just after bus reset. Furthermore, any FCP transactions are handled correctly. Therefore, the driver don't need to wait for bus reset handler for starting new streaming. This commit removes the codes to reduce maintenance cost. Signed-off-by:
-
- 19 Feb, 2016 1 commit
-
-
Libin Yang authored
On Intel platform, if !dyn_pcm_assign, spec->pcm_rec[].jack is not NULL even after snd_hda_jack_tbl_clear() is called to free snd_jack. This may cause access invalid memory when calling snd_jack_report. Fixes: 25e4abb3 ('ALSA: hda - hdmi jack created based on pcm') Signed-off-by:
-
