- 23 Apr, 2023 8 commits
-
-
Oswald Buddenhagen authored
- Use correct address limit for Audigy - Use the right constant to actually make a step on Audigy - Don't store *_DBG_STEP and the address in emu->fx8010.dbg, as otherwise unrelated operations would make steps, too This is untested. as10k1 was never ported to Audigy anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1144004-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The rev2 cards use CA0108, but the embedded P17V goes entirely unused. Also, A_IOCTL (which is really the GPIO port) is actually the FPGA control port, so messing with it is no good idea. The hacks are actually mutually exclusive, so make that explicit while we're at it. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143888-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Firstly, fix the distribution between public and private headers. Otherwise, some of the already public macros wouldn't actually work, and the SNDRV_EMU10K1_IOCTL_DBG_READ result for Audigy would be useless. Secondly, add condition code registers for Audigy. These are just aliases for selected constant registers, and thus are generation- specific. At least A_CC_REG_ZERO is actually correct ... Finally, shuffle around some defines to more logical places while at it, and fix up some more comments. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143903-7-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
For documentation purposes and later use. Some pre-existing but (mostly) unused definitions were renamed for consistency. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143903-6-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Firstly, remove the FXWC_* defines - the comment on FXWC implies that the relevant defines are the (A_)EXTOUT_* ones. It's unclear where this came from - it was in the initial ALSA import, but neither the driver from Creative nor kX-project have these defines. Secondly, remove A_HR, which made plain no sense (was unused, and clashed with FXRT). Amends commit cbb7d8f9 ("emu10k1: Update registers defines for the Audigy 2/emu10k2.5"). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143903-5-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
One might be mislead to think that these mean anything. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143903-4-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The bit values are supposed to be internally indented by one step relative to the register addresses. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143903-3-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Move comments to better locations, de-duplicate, fix/remove incorrect/ outdated ones, add new ones, and unify spacing somewhat. While at it, also add testing credits for Jonathan Dowland (SB Live! Platinum) and myself (E-MU 0404b). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143903-2-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 22 Apr, 2023 15 commits
-
-
Oswald Buddenhagen authored
Unlike the Alice2 chips used on 1st generation E-MU cards, the Tina/Tina2 chips used on the 2nd gen cards have only six GPIN pins, which means that we need to use a smaller mask. Failure to do so would falsify the read data if the FPGA tried to raise an IRQ right at that moment. This wasn't a problem so far, as we didn't actually enable FPGA IRQs, but that's going to change soon. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422132430.1057490-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Amends historic commit 27ae958c ("emu10k1 driver - add multichannel device hw:x,3 [2-8/8]"). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422132430.1057468-2-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
This was unnecessarily added in commit 09668b44 ("emu10k1 - Add PM support"). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422132430.1057468-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
- In snd_emu10k1_look_for_ctl(), evaluate the cheap condition first - In _snd_emu10k1_{audigy_,}init_efx(), don't use expensive bit setting loops to fill arrays - In snd_emu_proc_ptr_reg_read(), remove useless condition - iobase can be only 0 or 0x20 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422121519.1052813-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Various redundant FPGA writes which were presumably also cargo-culted from the Windows driver. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005539-7-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
These seem to be another instance of cargo-culting from the Windows driver. It presumably queries the register to decide about the followup actions, but we don't do that. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005539-6-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
These seem to be simply cargo-culted from the Windows driver's behavior. However, the original reason were presumably read-modify-write cycles, which we don't do. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005539-5-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
This doesn't do anything snd_emu10k1_init() wouldn't do later, and none of the things it does seem relevant for the function itself (which is pretty much about setting up the FPGA). It was probably a Windows driver behavior cargo-culting artifact. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005539-4-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
As the register definition clearly states, this is a 16-bit register, yet we did all accesses as 32-bit. The writes in particular would have the potential to clear the TIMER register (depending on how the bus/card actually handles the too long writes). This commit also introduces a separate define A_GPIO which aliases A_IOCFG, which better reflects the distinct usage on E-MU cards. This is done in the same commit to keep the churn down, as we're touching all involved lines anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005539-2-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Assert the validity of the registers and values, as them being out of range would indicate an error in the driver. Consequently, don't bother returning error codes; they were ignored everywhere anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005539-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Detach it better from the main PCM driver, which it really doesn't have much in common with. In particular, this moves the interrupt handler implementation into p16v.c, and makes it access the substream runtime status more directly, so it doesn't need to abuse structs snd_emu10k1_pcm and snd_emu10k1_voice any more. We don't need private pcm runtime data at all, as the only thing it was used for (except the back-link to the substream) was the `running` flag. So store that directly in runtime->private_data. This somewhat radical strip-down shows that this driver contains some complexity that was never actually utilized. I suppose the right way to fully utilize the hardware in a simple way would be introducing more substreams. This wouldn't require any of the removed code. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005452-7-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
It was written, but never read from. Its value is available via the epcm field. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005452-5-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The use of the variable was removed in commit 2b637da5 ("clean up card features"). That commit also broke user space (the ioctl structure), at which point the defines became meaningless, so I don't think purging them is a problem. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005452-3-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
It's just an (outdated) copy of snd_emu10k1_playback_pointer(). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005452-2-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Or actually, replace snd_emu10k1_playback_hw_free() with it, as that is a subset. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005452-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 21 Apr, 2023 4 commits
-
-
Oswald Buddenhagen authored
extin_mask and extout_mask are used only by the SbLive! microcode, so they have no effect on Audigy. Eliminate fxbus_mask entirely, as it wasn't actually used for anything. As a drive-by, remove the pointless pad1 field from struct snd_emu10k1_fx8010 - it is not visible to user space, so it has no binary compatibility constraints. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005509-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Chris Down authored
When an error occurs during USB disconnection sometimes things can go wrong as endpoint_set_interface may end up being called repeatedly. For example: % dmesg --notime | grep 'usb 3-7.1.4' | sort | uniq -c | head -2 3069 usb 3-7.1.4: 1:1: usb_set_interface failed (-19) 908 usb 3-7.1.4: 1:1: usb_set_interface failed (-71) In my case, there sometimes are hundreds of these usb_set_interface failure messages a second when I disconnect the hub that has my USB audio device. These messages can take a huge amount of the kmsg ringbuffer and don't provide any extra information over the previous ones, so ratelimit them. Signed-off-by: Chris Down <chris@chrisdown.name> Link: https://lore.kernel.org/r/ZEKf8UYBYa1h4JWR@chrisdown.nameSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
- Update some outdated info - Language fixes - Whitespace/formatting fixes - Prefer attached over stand-alone '::' [ dropped a trailing white space in the patch -- tiwai ] Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421112751.990244-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The auto-silencer supports two modes: "thresholded" to fill up "just enough", and "top-up" to fill up "as much as possible". The two modes used rather distinct code paths, which this patch unifies. The only remaining distinction is how much we actually want to fill. This fixes a bug in thresholded mode, where we failed to use new_hw_ptr, resulting in under-fill. Top-up mode is now more well-behaved and much easier to understand in corner cases. This also updates comments in the proximity of silencing-related data structures. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230420113324.877164-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 19 Apr, 2023 2 commits
-
-
Rob Herring authored
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144734.1546587-1-robh@kernel.orgSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Rob Herring authored
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144733.1546500-1-robh@kernel.orgSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 18 Apr, 2023 1 commit
-
-
Christophe JAILLET authored
These snd_BUG_ON() can never trigger, so just remove them to save a few LoC. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/91a31341f32d493bcc6c4515178ce0755ac1aa70.1681710069.git.christophe.jaillet@wanadoo.frSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 11 Apr, 2023 1 commit
-
-
Fred Oh authored
Add HD Audio PCI ID for Intel Lunarlake platform. Signed-off-by: Fred Oh <fred.oh@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230406152500.15104-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 08 Apr, 2023 1 commit
-
-
Oswald Buddenhagen authored
... in wait_for_avail() and snd_pcm_drain(). t was calculated in seconds, so it would be pretty much always zero, to be subsequently de-facto ignored due to being max(t, 10)'d. And then it (i.e., 10) would be treated as secs, which doesn't seem right. However, fixing it to properly calculate msecs would potentially cause timeouts when using twice the period size for the default timeout (which seems reasonable to me), so instead use the buffer size plus 10 percent to be on the safe side ... but that still seems insufficient, presumably because the hardware typically needs a moment to fire up. To compensate for this, we up the minimal timeout to 100ms, which is still two orders of magnitude less than the bogus minimum. substream->wait_time was also misinterpreted as jiffies, despite being documented as being in msecs. Only the soc/sof driver sets it - to 500, which looks very much like msecs were intended. Speaking of which, shouldn't snd_pcm_drain() also use substream-> wait_time? As a drive-by, make the debug messages on timeout less confusing. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230405201219.2197774-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 06 Apr, 2023 3 commits
-
-
Oswald Buddenhagen authored
I'm not the first one to run into this, see e.g. https://lore.kernel.org/all/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org/Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230406132521.2252019-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
- Less misinformation - Language and whitespace fixups Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230405201220.2197893-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The newer E-MU cards weren't mentioned at all. The "partially supported" is removed ahead of it becoming mostly untrue. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230405201220.2197908-1-oswald.buddenhagen@gmx.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 30 Mar, 2023 1 commit
-
-
Takashi Iwai authored
For allowing the build without CONFIG_PM, add definitions of dummy functions for snd_ac97_suspend() and snd_ac97_resume() without CONFIG_PM, too. Link: https://lore.kernel.org/r/20230330132847.12882-1-tiwai@suse.deReviewed-by: Jaroslav Kysela <perex@perex.cz> Reviewed-by: Tasos Sahanidis <tasos@tasossah.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 29 Mar, 2023 4 commits
-
-
Tom Rix authored
clang with W=1 reports sound/pci/asihpi/hpi6000.c:1256:6: error: variable 'loop_count' set but not used [-Werror,-Wunused-but-set-variable] u32 loop_count = 0; ^ This variable is not used so remove it. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20230326205712.1358918-1-trix@redhat.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Tasos Sahanidis authored
The macro for said register already exists, so just use it, to make the code more readable. Signed-off-by: Tasos Sahanidis <tasos@tasossah.com> Link: https://lore.kernel.org/r/20230329043918.179352-1-tasos@tasossah.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Tasos Sahanidis authored
There's no need to switch between unsigned short and u16, especially since all the functions that end up using old_legacy_ctrl specify u16 anyway. Signed-off-by: Tasos Sahanidis <tasos@tasossah.com> Link: https://lore.kernel.org/r/20230329043627.178899-1-tasos@tasossah.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Tasos Sahanidis authored
YMF744 and newer store the base IO ports in separate PCI config registers. Since these registers were not restored, when set to a non-default value, features that rely on them (FM, MPU401, gameport) were not functional after restore, as their respective IO ports were reset to their defaults. Signed-off-by: Tasos Sahanidis <tasos@tasossah.com> Link: https://lore.kernel.org/r/20230329041440.177363-5-tasos@tasossah.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-