- 20 Jun, 2017 7 commits
-
-
Takashi Iwai authored
The ALSA PCM core refers to the appl_ptr value stored on the mmapped page that is shared between kernel and user-space. Although the reference is performed in the PCM stream lock, it doesn't guarantee the atomic access when the value gets updated concurrently from the user-space on another CPU. In most of codes, this is no big problem, but still there are a few places that may result in slight inconsistencies because they access runtime->control->appl_ptr multiple times; that is, the second read might be a different value from the first value. It can be even backward or jumping, as we have no control for it. Hence, the calculation may give an unexpected value. Luckily, there is no security vulnerability by that, as far as I've checked. But still we should address it. This patch tries to reduce such possible cases. The fix is simple -- we just read once, store it to a local variable and use it for the rest calculations. The READ_ONCE() macro is used for it in order to avoid the ill-effect by possible compiler optimizations. Reviewed-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
When the codec device is unregistered / freed, it may release the resource while being used in an unsolicited event like the jack detection work. This leads to use-after-free. The fix here is to unregister the device at first, i.e. removing the codec from the list, then flushing the pending works to assure that all unsol events are gone. After this point, we're free from accessing the codec via unsol events, thus can release the resources gracefully. The issue was spotted originally by Intel CI, but it couldn't be reproduced reliably by its nature. So let's hope this fix really addresses the whole issues. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196045Reported-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Takashi Iwai authored
We checked the quirks specific to the recent Intel chips by checking the PCI IDs manually, but it's becoming messy with lots of IS_SKL() and other macros, as the amount accumulated. For simplification, here the new AZX_DRIVER_SKL type is introduced, and check chip->driver_type instead of the manual PCI ID. The short name for this is still "HDA Intel PCH", so that it doesn't break the existing user-space unnecessarily. Suggested-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Takashi Iwai authored
-
Takashi Iwai authored
Broxton-T was a forgotten child and we didn't apply the quirks for Skylake+ properly. Meanwhile, a quirk for reducing the DMA latency seems specific to the early Broxton model, so we leave as is. Cc: <stable@vger.kernel.org> Signed-off-by: -
Hans P. Möller Ebner authored
Remove Initialization from POD HD500X because it's not needed. Every time the device is connected dmesg gives the following output: "receive length failed (error -11)". To solve this problem, another flags is introduced (LINE6_CAP_CONTROL_INFO) and it is only used for PODX3 in: sysfs entries, call podhd_startup_finalize(pod) and disconnection. With this patch the error disappear. Signed-off-by:
Hans P. Moller <hmoller@uc.cl> Signed-off-by:
-
Hans P. Möller Ebner authored
Add support for the Line6 POD HD500X multi effect processor for playback and capture (in/out audio) through USB. Signed-off-by:
-
- 19 Jun, 2017 1 commit
-
-
Takashi Sakamoto authored
At Linux v3.5, packet processing can be done in process context of ALSA PCM application as well as software IRQ context for OHCI 1394. Below is an example of the callgraph (some calls are omitted). ioctl(2) with e.g. HWSYNC (sound/core/pcm_native.c) ->snd_pcm_common_ioctl1() ->snd_pcm_hwsync() ->snd_pcm_stream_lock_irq (sound/core/pcm_lib.c) ->snd_pcm_update_hw_ptr() ->snd_pcm_udpate_hw_ptr0() ->struct snd_pcm_ops.pointer() (sound/firewire/*) = Each handler on drivers in ALSA firewire stack (sound/firewire/amdtp-stream.c) ->amdtp_stream_pcm_pointer() (drivers/firewire/core-iso.c) ->fw_iso_context_flush_completions() ->struct fw_card_driver.flush_iso_completion() (drivers/firewire/ohci.c) = flush_iso_completions() ->struct fw_iso_context.callback.sc (sound/firewire/amdtp-stream.c) = in_stream_callback() or out_stream_callback() ->... ->snd_pcm_stream_unlock_irq When packet queueing error occurs or detecting invalid packets in 'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()' is called on local CPU with disabled IRQ. (sound/firewire/amdtp-stream.c) in_stream_callback() or out_stream_callback() ->amdtp_stream_pcm_abort() ->snd_pcm_stop_xrun() ->snd_pcm_stream_lock_irqsave() ->snd_pcm_stop() ->snd_pcm_stream_unlock_irqrestore() The process is stalled on the CPU due to attempt to acquire recursive lock. [ 562.630853] INFO: rcu_sched detected stalls on CPUs/tasks: [ 562.630861] 2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140 [ 562.630862] (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933) [ 562.630866] Task dump for CPU 2: [ 562.630867] alsa-source-OXF R running task 0 6619 1 0x00000008 [ 562.630870] Call Trace: [ 562.630876] ? vt_console_print+0x79/0x3e0 [ 562.630880] ? msg_print_text+0x9d/0x100 [ 562.630883] ? up+0x32/0x50 [ 562.630885] ? irq_work_queue+0x8d/0xa0 [ 562.630886] ? console_unlock+0x2b6/0x4b0 [ 562.630888] ? vprintk_emit+0x312/0x4a0 [ 562.630892] ? dev_vprintk_emit+0xbf/0x230 [ 562.630895] ? do_sys_poll+0x37a/0x550 [ 562.630897] ? dev_printk_emit+0x4e/0x70 [ 562.630900] ? __dev_printk+0x3c/0x80 [ 562.630903] ? _raw_spin_lock+0x20/0x30 [ 562.630909] ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm] [ 562.630914] ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm] [ 562.630918] ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm] [ 562.630922] ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib] [ 562.630925] ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci] [ 562.630928] ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci] [ 562.630932] ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core] [ 562.630935] ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib] [ 562.630938] ? pcm_capture_pointer+0x19/0x20 [snd_oxfw] [ 562.630943] ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm] [ 562.630945] ? poll_select_copy_remaining+0x150/0x150 [ 562.630947] ? poll_select_copy_remaining+0x150/0x150 [ 562.630952] ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm] [ 562.630956] ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm] [ 562.630960] ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm] [ 562.630962] ? futex_wake+0x90/0x170 [ 562.630966] ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm] [ 562.630970] ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm] [ 562.630972] ? do_vfs_ioctl+0xa3/0x610 [ 562.630974] ? vfs_read+0x11b/0x130 [ 562.630976] ? SyS_ioctl+0x79/0x90 [ 562.630978] ? entry_SYSCALL_64_fastpath+0x1e/0xad This commit fixes the above bug. This assumes two cases: 1. Any error is detected in software IRQ context of OHCI 1394 context. In this case, PCM substream should be aborted in packet handler. On the other hand, it should not be done in any process context. TO distinguish these two context, use 'in_interrupt()' macro. 2. Any error is detect in process context of ALSA PCM application. In this case, PCM substream should not be aborted in packet handler because PCM substream lock is acquired. The task to abort PCM substream should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is returned at 'struct snd_pcm_ops.pointer()'. Suggested-by:Clemens Ladisch <clemens@ladisch.de> Fixes: e9148ddd("ALSA: firewire-lib: flush completed packets when reading PCM position") Cc: <stable@vger.kernel.org> # 4.9+ Signed-off-by:
-
- 16 Jun, 2017 6 commits
-
-
Takashi Iwai authored
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations in order to improve grep-ability. - Move EXPORT_SYMBOL*() to the position right after its definition - Remove superfluous blank line before EXPORT_SYMBOL*() lines Signed-off-by: -
Takashi Iwai authored
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations in order to improve grep-ability. - Move EXPORT_SYMBOL*() to the position right after its definition Signed-off-by: -
Takashi Iwai authored
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations in order to improve grep-ability. - Move EXPORT_SYMBOL*() to the position right after its definition - Remove superfluous blank line before EXPORT_SYMBOL*() lines Signed-off-by: -
Takashi Iwai authored
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations in order to improve grep-ability. - Remove superfluous blank line before EXPORT_SYMBOL*() lines Signed-off-by: -
Kailang Yang authored
Add this functions, it could support ALC256 for HP depop functions. It also can solve some ALC256 machine plug headset cause power off issue. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
-
Christoph Hellwig authored
Use dma_alloc_attrs directly instead of the dma_alloc_noncoherent wrapper. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
- 14 Jun, 2017 10 commits
-
-
Takashi Iwai authored
The standard PCM chmap helper callbacks treat the NULL info->chmap as a fatal error and spews the kernel warning with stack trace when CONFIG_SND_DEBUG is on. This was OK, originally it was supposed to be always static and non-NULL. But, as the recent addition of Intel LPE audio driver shows, the chmap content may vary dynamically, and it can be even NULL when disconnected. The user still sees the kernel warning unnecessarily. For clearing such a confusion, this patch simply removes the snd_BUG_ON() in each place, just returns an error without warning. Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by: -
Takashi Sakamoto authored
SNDRV_PCM_IOCTL1_GSTATE was firstly introduced in v0.9.0, however never be used and the purpose is missing. This commit removes the long-abandoned command, bye. Signed-off-by:
-
Takashi Sakamoto authored
Drivers can implement 'struct snd_pcm_ops.ioctl' to handle some requests from ALSA PCM core. These requests are internal purpose in kernel land. Usually common set of operations are used for it. SNDRV_PCM_IOCTL1_INFO is one of the requests. According to code comment, it has been obsoleted in the old days. We can see old releases in ftp.alsa-project.org. The command was firstly introduced in v0.5.0 release as SND_PCM_IOCTL1_INFO, to allow drivers to fill data of 'struct snd_pcm_channel_info' type. In v0.9.0 release, this was obsoleted by the other commands for ioctl(2) such as SNDRV_PCM_IOCTL_CHANNEL_INFO. This commit removes the long-abandoned command, bye. Signed-off-by:
-
Megha Dey authored
Coffelake is another Intel part, so need to add PCI ID for it. Signed-off-by:
Megha Dey <megha.dey@intel.com> Signed-off-by:
Subhransu S. Prusty <subhransu.s.prusty@intel.com> Acked-by:
-
Takashi Iwai authored
We call ack callback whenever appl_ptr gets updated via pcm_lib_apply_appl_ptr(). There are various code paths to call this function. A part of them are for read/write/forward/rewind, where the appl_ptr is always changed and thus the call of ack is mandatory. OTOH, another part of code paths are from the explicit user call, e.g. via SYNC_PTR ioctl. There, we may receive the same appl_ptr value, and in such a case, calling ack is obviously superfluous. This patch adds the check of the given appl_ptr value, and returns immediately if it's no real update. Reviewed-by:
-
Takashi Iwai authored
Just a code cleanup. Reviewed-by:
-
Takashi Iwai authored
Calling PREPARE ioctl to the stream in either PAUSED or SUSPENDED state may confuse some drivers that don't handle the state properly. Instead of fixing each driver, PCM core should take care of the proper state change before actually trying to (re-)prepare the stream. Namely, when the stream is in PAUSED state, it triggers PAUSE_RELEASE, and when in SUSPENDED state, it triggers STOP, before calling prepare callbacks. Reviewed-by:
-
Takashi Iwai authored
So far, the PCM core refuses DROP ioctl when the stream in the suspended state. This was basically to avoid the invalid state change *during* the suspend. But since we protect the power change globally in the common PCM ioctl caller side, it's guaranteed that snd_pcm_drop() is called at the right power state. So we can assume that the drop of stream is safe immediately after SUSPENDED state. Reviewed-by:
-
Takashi Iwai authored
All PCM common ioctls should run only in the powered up state, but currently only a few ioctls do the proper snd_power_lock() and snd_power_wait() invocations. Instead of adding to each place, do it commonly in the caller side, so that all these ioctls are assured to be operated at the power up state. Reviewed-by:
-
Takashi Iwai authored
Use snd_pcm_action_lock_irq() helper instead of open coding. No functional change. Reviewed-by:
-
- 13 Jun, 2017 1 commit
-
-
Takashi Iwai authored
-
- 12 Jun, 2017 4 commits
-
-
Takashi Sakamoto authored
As long as I know, in userspace, '%c' format on printing format for tracepoint is replaced with '>c<' by existent tracing program; i.g. 'perf-trace' and 'trace-cmd'. This is inconvenient. This commit replaces the format with '%s'. The length of letters in the format string is not changed, thus this commit doesn't increase object size. In theory, I should work for improvements of these tracing programs, but here I'd like to save my time to work for the other projects. Signed-off-by:
-
Takashi Sakamoto authored
In design of ALSA PCM core, status and control data for runtime of ALSA PCM substream are shared between kernel/user spaces by page frame mapping with read-only attribute. Both of hardware-side and application-side position on PCM buffer are maintained as a part of the status data. In a view of ALSA PCM application, these two positions can be updated by executing ioctl(2) with some commands. There's an event of tracepoint for hardware-side position; 'hwptr'. On the other hand, no events for application-side position. This commit adds a new event for this purpose; 'applptr'. When the application-side position is changed in kernel space, this event is probed with useful information for developers. I note that the event is not probed for all of ALSA PCM applications, When applications are written by read/write programming scenario, the event is surely probed. The applications execute ioctl(2) with SNDRV_PCM_IOCTL_[READ|WRITE][N/I]_FRAMES to read/write any PCM frame, then ALSA PCM core updates the application-side position in kernel land. However, when applications are written by mmap programming scenario, if maintaining the application side position in kernel space accurately, applications should voluntarily execute ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR to commit the number of handled PCM frames. If not voluntarily, the application-side position is not changed, thus the added event is not probed. There's a loophole, using architectures to which ALSA PCM core judges non cache coherent. In this case, the status and control data is not mapped into processe's VMA for any applications. Userland library, alsa-lib, is programmed for this case. It executes ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR command every time to requiring the status and control data. ARM is such an architecture. Below is an example with serial sound interface (ssi) on i.mx6 quad core SoC. I use v4.1 kernel released by fsl-community with patches from VIA Tech. Inc. for VAB820, and my backport patches for relevant features for this patchset. I use Ubuntu 17.04 from ports.ubuntu.com as user land for armhf architecture. $ aplay -v -M -D hw:imx6vab820sgtl5,0 /dev/urandom -f S16_LE -r 48000 --period-size=128 --buffer-size=256 Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono Hardware PCM card 0 'imx6-vab820-sgtl5000' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 256 period_size : 128 period_time : 2666 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 128 period_event : 0 start_threshold : 256 stop_threshold : 256 silence_threshold: 0 silence_size : 0 boundary : 1073741824 appl_ptr : 0 hw_ptr : 0 mmap_area[0] = 0x76f98000,0,16 (16) $ trace-cmd record -e snd_pcm:hwptr -e snd_pcm:applptr $ trace-cmd report ... 60.208495: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256 60.208633: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256 60.210022: hwptr: pcmC0D0p/sub0: IRQ: pos=128, old=1536, base=1536, period=128, buf=256 60.210202: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256 60.210344: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256 60.210348: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256 60.210486: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256 60.210626: applptr: pcmC0D0p/sub0: prev=1792, curr=1920, avail=0, period=128, buf=256 60.211002: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256 60.211142: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256 60.211146: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256 60.211287: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256 60.212690: hwptr: pcmC0D0p/sub0: IRQ: pos=0, old=1664, base=1536, period=128, buf=256 60.212866: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256 60.212999: hwptr: pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256 60.213003: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256 60.213135: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256 60.213276: applptr: pcmC0D0p/sub0: prev=1920, curr=2048, avail=0, period=128, buf=256 60.213654: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256 60.213796: hwptr: pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256 60.213800: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256 60.213937: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256 60.215356: hwptr: pcmC0D0p/sub0: IRQ: pos=128, old=1792, base=1792, period=128, buf=256 60.215542: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256 60.215679: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1920, base=1792, period=128, buf=256 60.215683: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256 60.215813: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256 60.215947: applptr: pcmC0D0p/sub0: prev=2048, curr=2176, avail=0, period=128, buf=256 ... We can surely see 'applptr' event is probed even if the application run for mmap programming scenario ('-M' option and 'hw' plugin). Below is a result of strace: 02:44:15.886382 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.887203 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) 02:44:15.887471 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.887637 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.887805 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.887969 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.888132 read(3, "..."..., 256) = 256 02:44:15.889040 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.889221 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.889431 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.889606 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) 02:44:15.889833 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.889998 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.890164 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891048 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891228 read(3, "..."..., 256) = 256 02:44:15.891497 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891661 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891829 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 02:44:15.891991 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}]) 02:44:15.893007 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0 We can see 7 calls of ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR per loop with call of poll(2). 128 PCM frames are transferred per loop of one poll(2), because the PCM substream is configured with S16_LE format and 1 channel (2 byte * 1 * 128 = 256 bytes). This equals to the size of period of PCM buffer. Comparing to the probed data, one of the 7 calls of ioctl(2) is actually used to commit the number of copied PCM frames to kernel space. The other calls are just used to check runtime status of PCM substream; e.g. XRUN. The tracepoint event is useful to investigate this case. I note that below modules are related to the above sample. * snd-soc-dummy.ko * snd-soc-imx-sgtl5000.ko * snd-soc-fsl-ssi.ko * snd-soc-imx-pcm-dma.ko * snd-soc-sgtl5000.ko My additional note is lock acquisition. The event is probed under acquiring PCM stream lock. This means that calculation in the event is free from any hardware events. Signed-off-by: -
Takashi Sakamoto authored
In a series of recent work, ALSA PCM core got some arrangements to handle application-side position on PCM buffer. However, relevant codes still disperse to two translation units This commit unifies these codes into a helper function. Signed-off-by:
-
Takashi Iwai authored
Many drivers bind the sequencer stuff in off-load by another driver module, so that it's loaded only on demand. In the current code, this mechanism doesn't work when the driver is built-in while the sequencer is module. We check with IS_REACHABLE() and enable only when the sequencer is in the same level of build. However, this is basically a overshoot. The binder code (snd-seq-device) is an individual module from the sequencer core (snd-seq), and we just have to make the former a built-in while keeping the latter a module for allowing the scenario like the above. This patch achieves that by rewriting Kconfig slightly. Now, a driver that provides the manual sequencer device binding should select CONFIG_SND_SEQ_DEVICE in a way as select SND_SEQ_DEVICE if SND_SEQUENCER != n Note that the "!=n" is needed here to avoid the influence of the sequencer core is module while the driver is built-in. Also, since rawmidi.o may be linked with snd_seq_device.o when built-in, we have to shuffle the code to make the linker happy. (the kernel linker isn't smart enough yet to handle such a case.) That is, snd_seq_device.c is moved to sound/core from sound/core/seq, as well as Makefile. Last but not least, the patch replaces the code using IS_REACHABLE() with IS_ENABLED(), since now the condition meets always when enabled. Signed-off-by:
-
- 11 Jun, 2017 2 commits
-
-
Takashi Sakamoto authored
At present, trace events are probed even if corresponding parameter is not actually changed. This is inconvenient. This commit improves the behaviour. Signed-off-by:
-
Takashi Sakamoto authored
When refining mask/interval parameters, helper functions can return error code. This error is not handled immediately. This seems to return parameters to userspace applications in its meddle of processing. However, in general, when receiving error from system calls, the application might not handle argument buffer. It's reasonable to judge the above design as superfluity. This commit handles the error immediately. Signed-off-by:
-
- 09 Jun, 2017 9 commits
-
-
Takashi Iwai authored
Instead of the non-standard way to enable the build of snd-emux-synth module inside Makefile, rewrite Kconfig to select the item explicitly from each driver (sbawe and emu10k1). This is the standard way. Signed-off-by: -
Takashi Iwai authored
This is a slightly intensive rewrite of Kconfig and Makefile about ALSA sequencer stuff. The first major change is that the kconfig items for the sequencer are moved to sound/core/seq/Kconfig. OK, that's easy. The substantial change is that, instead of hackish top-level module selection in Makefile, we define a Kconfig item for each sequencer module. The driver that requires such sequencer components select exclusively the kconfig items. This is more straightforward and standard way. Signed-off-by: -
Takashi Iwai authored
Currently OSS sequencer emulation is tied with ALSA sequencer core, both are built in the same level; i.e. when CONFIG_SND_SEQUENCER=y, the OSS sequencer emulation is also always built-in, even though the functionality can be built as an individual module. This patch changes the rule and allows users to build snd-seq-oss module while others are built-in. Essentially, it's just a few simple changes in Kconfig and Makefile. Some driver codes like opl3 need to convert from the simple ifdef to IS_ENABLED(). But that's all. You might wonder how about the dependency: right, it can be messy, but it still works. Since we rewrote the sequencer binding with the standard bus, the driver can be bound at any time on demand. So, the synthesizer driver module can be loaded individually from the OSS emulation core before/after it. Signed-off-by: -
Takashi Iwai authored
Currently CONFIG_SND_OSSEMUL is selected by each config like CONFIG_SND_PCM_OSS. But, as see in the raw MIDI code that is built conditionally with CONFIG_SND_OSSEMUL, we should rather make CONFIG_SND_OSSEMUL user-selectable as the top kconfig item, and leave the rest depending on it. Signed-off-by: -
Takashi Sakamoto authored
Use the same print format of snd_pcm_debug_name() for userspace tracing program. Suggested-by:
-
Takashi Sakamoto authored
Results of ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE and SNDRV_PCM_IOCTL_HW_PARAMS are different, because the latter has single value for several parameters; e.g. channels of PCM substream. Selection of the single value is done independently of application of constraints. It's helpful for developers to trace the selection process. This commit adds tracepoints to snd_pcm_hw_params_choose() for the purpose. Signed-off-by:
-
Takashi Sakamoto authored
As of v4.12, snd_pcm_hw_params_choose() is just called in a process context of ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS. The function locates in a different file, which has no tracepoints. This commit moves the function to a file with the tracepoints for later commit. Signed-off-by:
-
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by: -
Takashi Iwai authored
snd_pcm_hw_constraint_list(), *_ratnums() and *_ratdens() receive the const pointers. Constify the corresponding static objects for better hardening. Signed-off-by:
-
