linux-dev/sound/pci/echoaudio/echoaudio.h, branch master

ALSA: echoaudio: Allocate resources with device-managed APIs

2021-07-19T14:16:55Z

This patch converts the resource management in PCI echoaudio drivers with devres as a clean up. Each manual resource management is converted with the corresponding devres helper, the page allocations are done with the devres helper, and the card object release is managed now via card->private_free instead of a lowlevel snd_device. The irq handler is still managed manually because it's re-acquired at PM suspend/resume. This should give no user-visible functional changes. Link: https://lore.kernel.org/r/20210715075941.23332-33-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: echoaduio: Drop superfluous volatile modifier

2020-08-11T12:21:49Z

The dsp_registers field of struct echoaduio has the volatile modifier, but it's basically superfluous; the field is accessed only for the base pointer of readl() and writel(), hence marking with __iomem alone should suffice. OTOH, having the volatile prefix causes a compile warning like: sound/pci/echoaudio/echoaudio.c:1878:14: warning: passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers] So it's better to drop this superfluous modifier. Link: https://lore.kernel.org/r/20200803143958.24324-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: echoaudio: Address bugs in the interrupt handling

2020-07-09T10:59:24Z

Distorted audio appears occasionally, affecting either playback or capture and requiring the affected substream to be closed by all applications and re-opened. The best way I have found to reproduce the bug is to use dmix in combination with Chromium, which opens the audio device multiple times in threads. Anecdotally, the problems appear to have increased with faster CPUs. I ruled out 32-bit counter wrapping; it often happens much earlier. Since applying this patch I have not had problems, where previously they would occur several times a day. The patch targets the following issues: * Check for progress using the counter from the hardware, not after it has been truncated to the buffer. This is a clean way to address a possible bug where if a whole ringbuffer advances between interrupts, it goes unnoticed. * Move last_period state from chip to pipe This more logically belongs as part of pipe, and code is reasier to read if it is "counter position last time a period elapsed". Now the code has no references to period count. A period is just when the regular counter crosses a threshold. This increases readability and reduces scope for bugs. * Treat period notification and buffer advance independently: This helps to clarify what is the responsibility of the interrupt handler, and what is pcm_pointer(). Removing shared state between these operations means race conditions are fixed without introducing locks. Synchronisation is only around the read of pipe->dma_counter. There may be cache line contention around "struct audiopipe" but I did not have cause to profile this. Pay attention to be robust where dma_counter wrapping is not a multiple of period_size or buffer_size. This is a revised patch based on feedback from Takashi and Giuliano. Signed-off-by: Mark Hills Link: https://lore.kernel.org/r/20200708101848.3457-5-mark@xwax.org Signed-off-by: Takashi Iwai

ALSA: echoaudio: Race conditions around "opencount"

2020-07-09T10:58:35Z

Use of atomics does not make these statements robust: atomic_inc(&chip->opencount); if (atomic_read(&chip->opencount) > 1 && chip->rate_set) chip->can_set_rate=0; and if (atomic_read(&chip->opencount)) { if (chip->opencount) { changed = -EAGAIN; } else { changed = set_digital_mode(chip, dmode); It would be necessary to atomically increment or decrement the value and use the returned result. And yet we still need to prevent other threads making use of "can_set_rate" while we set it. However in all but one case the atomic is misleading as they are already running with "mode_mutex" held. Decisions are made on mode setting are often intrinsically connected to "opencount" because some operations are not permitted unless there is sole ownership. So instead simplify this, and use "mode_mutex" as a lock for all reference counting and mode setting. Signed-off-by: Mark Hills Link: https://lore.kernel.org/r/20200708101848.3457-2-mark@xwax.org Signed-off-by: Takashi Iwai

ALSA: echoaudio: Proper endian notations

2018-07-27T07:06:09Z

Many data fields defined in echoaudio drivers are in little-endian, hence they should be defined with __le16 or __le32. This makes it easier to catch the forgotten conversions. Spotted by sparse, a warning like: sound/pci/echoaudio/echoaudio_dsp.c:990:36: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai

ALSA: echoaudio: Drop superfluous macro

2018-05-24T09:23:02Z

Drop pci_device() macro that just leads to chip->pci->dev, and pass it directly to request_firmware(). It was introduced for allowing the external alsa-driver kernel module builds. Since it was discontinued years ago, we should clean it up now. Signed-off-by: Takashi Iwai

ALSA: echoaudio: Use standard C definitions of true and false

2015-08-10T12:27:16Z

The echoaudio locally defines TRUE and FALSE. Not only is this redundant given that C now has a boolean type it results in lots of warnings as other headers also define these macros, causing duplicate definitions. Fix this by removing the local defines and converting all local users to use the standard C true and false instead, simply removing the macros is less safe due to implicit inclusion of the other definitons. [fixed overlooked replacement of FALSE by tiwai] Signed-off-by: Mark Brown Signed-off-by: Takashi Iwai

ALSA: echoaudio: remove all snd_printk

2014-11-03T13:07:25Z

removed all references of snd_printk with the standard dev_* macro. [a few places degraded to dev_dbg(), too -- tiwai] Signed-off-by: Sudip Mukherjee Signed-off-by: Takashi Iwai

ALSA: echoaudio: add reference of struct echoaudio

2014-11-03T13:02:33Z

added reference of struct echoaudio to free_firmware function. this structure will be later used to get a reference of the card when converting snd_printk to dev_* in the next patch of the series. Signed-off-by: Sudip Mukherjee Signed-off-by: Takashi Iwai

ALSA: pci: remove __dev* attributes

2012-12-07T06:20:55Z

CONFIG_HOTPLUG is going away as an option. As result the __dev* markings will be going away. Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit. Signed-off-by: Bill Pemberton Signed-off-by: Takashi Iwai