- 08 May, 2022 1 commit
-
-
bo liu authored
The current kernel does not support the SN6140 codec chip. Add the SN6140 codec configuration item to kernel. Signed-off-by:
bo liu <bo.liu@senarytech.com> Link: https://lore.kernel.org/r/20220506025735.17731-1-bo.liu@senarytech.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 25 Apr, 2022 2 commits
-
-
Colin Ian King authored
Pointer substream is being dereferenced on the assignment of pointer card before substream is being null checked with the macro PCM_RUNTIME_CHECK. Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the the pointer check before card is assigned. Fixes: d4cfb30f ("ALSA: pcm: Set per-card upper limit of PCM buffer allocations") Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220424205945.1372247-1-colin.i.king@gmail.comSigned-off-by:
-
Mark Brown authored
Not much of a test but we keep on getting problems with boolean controls not being called Switches so let's add a few basic checks to help people spot problems. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220421115020.14118-1-broonie@kernel.orgSigned-off-by:
-
- 21 Apr, 2022 2 commits
-
-
Takashi Iwai authored
Use the new quirk bits to manage the generic implicit fb quirk entries. This makes easier to compare with other devices. Link: https://lore.kernel.org/r/20220421064101.12456-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
For making easier to test, add the new quirk_flags bits 17 and 18 to enable and disable the generic implicit feedback mode. The bit 17 is equivalent with implicit_fb=1 option, applying the generic implicit feedback sync mode. OTOH, the bit 18 disables the implicit fb mode forcibly. Link: https://lore.kernel.org/r/20220421064101.12456-1-tiwai@suse.deSigned-off-by:
-
- 13 Apr, 2022 20 commits
-
-
Takashi Iwai authored
Back-merge the 5.18-rc3 devel branch, as it influences on the further development. Signed-off-by: -
Takashi Iwai authored
Pull CS35L41 codec updates Signed-off-by: -
Lucas Tanure authored
Add support for external boost voltage, where GPIO1 must control a switch to isolate CS35L41 from the external Boost Voltage Signed-off-by:
Lucas Tanure <tanureal@opensource.cirrus.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by:
-
David Rhodes authored
Document internal and external boost feature for ASoC CS35L41. For internal boost the following properties are required: - cirrus,boost-peak-milliamp - cirrus,boost-ind-nanohenry - cirrus,boost-cap-microfarad For external boost, the GPIO1 must be configured as output, so the following properties are required: - cirrus,gpio1-src-select = <1> - cirrus,gpio1-output-enable Signed-off-by:
David Rhodes <drhodes@opensource.cirrus.com> Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Lucas Tanure authored
To add support for external boost for ASoC move the HDA external boost implementation to the shared lib. Signed-off-by:
-
Lucas Tanure authored
External boost enables sequences for devices with or without GPIO1 as VSPK switch are the same if devices are put in safe mode from reset. As a previous patch put all external boost devices into safe mode from reset, all external boost devices can be handled in the same way for stream open and close. The only difference is that devices without an VSPK switch can not be put in reset and devices with it can be put into reset if a configuration is applied. The function cs35l41_hda_safe_reset is created to handle the safe reset of the chip, and as systems without VSPK switch are not supported anymore, only the CS35L41 HDA driver should check its return. Signed-off-by:
-
Lucas Tanure authored
For each case, only log the last regmap access, so it doesn't get overwritten, and as all regmap access should show the same issues logging the last one should be enough. Change to dev_err to log this error. Also, differentiate between a regmap access failure and invalid playback action. Signed-off-by:
-
Lucas Tanure authored
Remove cs35l41_hd_reg_sequence as it adds a layer of flexibility not needed. As cs35l41_hda_(start/stop)_bst is a single register, it can be replaced by regmap_update_bits with usleep_range to wait for the same 3000us that reg_sequence had. Signed-off-by:
-
Lucas Tanure authored
Having CS35L41_PWR_CTRL2 on cs35l41_hda_config overwrites the boost configuration for internal boost. So move it to the initialization part and use regmap_update_bits to only change the correct bits. Signed-off-by:
-
Lucas Tanure authored
Internal Boost enable is the default option from reset, but with external boost support, internal boost must be disabled. Add the enable of internal boost in cs35l41_boost_config to centralize the internal boost configuration. Signed-off-by:
-
Lucas Tanure authored
Mute the device before shutdown to avoid pops and clicks for all types of boost. Signed-off-by:
-
Lucas Tanure authored
To facilitate the configuration of external boost devices, put all devices, with or without VSPK switch, into safe mode from the start. That allows the following parts of the driver to handle all external boost devices in the same way. Signed-off-by:
-
Lucas Tanure authored
Replace vspk_always_on by a enum that better characterizes the boost type, as there is 3 types of boost hardware. And with the new boost type other parts of the driver can better handle the configuration of the chip. Signed-off-by:
-
Lucas Tanure authored
The dai configuration is always the same and should always configured during the opening the stream. Signed-off-by:
-
Lucas Tanure authored
Fix clock and slot size comments Signed-off-by:
-
Lucas Tanure authored
ASoC and HDA can use a single function to configure the chip gpios. Signed-off-by:
-
Lucas Tanure authored
The driver can receive an empty hw_config, so mark as valid if successfully read from device tree/ACPI or set by the driver itself. Platforms not marked with a valid hw config will not be supported. Signed-off-by:
-
Lucas Tanure authored
Both ASoC and HDA require to configure the GPIOs and Boost, so create a single shared struct for hardware configuration. Signed-off-by:
-
Takashi Iwai authored
In the previous fix, we increased the max buffer bytes from 1MB to 4MB so that we can use bigger buffers for the modern HiFi devices with higher rates, more channels and wider formats. OTOH, extending this has a concern that too big buffer is allowed for the lower rates, less channels and narrower formats; when an application tries to allocate as big buffer as possible, it'll lead to unexpectedly too huge size. Also, we had a problem about the inconsistent max buffer and period bytes for the implicit feedback mode when both streams have different channels. This was fixed by the (relatively complex) patch to reduce the max buffer and period bytes accordingly. This is an alternative fix for those, a patch to kill two birds with one stone (*): instead of increasing the max buffer bytes blindly and applying the reduction per channels, we simply use the hw constraints for the buffer and period "time". Meanwhile the max buffer and period bytes are set unlimited instead. Since the inconsistency of buffer (and period) bytes comes from the difference of the channels in the tied streams, as long as we care only about the buffer (and period) time, it doesn't matter; the buffer time is same for different channels, although we still allow higher buffer size. Similarly, this will allow more buffer bytes for HiFi devices while it also keeps the reasonable size for the legacy devices, too. As of this patch, the max period and buffer time are set to 1 and 2 seconds, which should be large enough for all possible use cases. (*) No animals were harmed in the making of this patch. Fixes: 98c27add ("ALSA: usb-audio: Cap upper limits of buffer/period bytes for implicit fb") Fixes: fee2ec8c ("ALSA: usb-audio: Increase max buffer size") Link: https://lore.kernel.org/r/20220412130740.18933-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The recent change for memory allocator replaced the SG-buffer handling helper for x86 with the standard non-contiguous page handler. This works for most cases, but there is a corner case I obviously overlooked, namely, the fallback of non-contiguous handler without IOMMU. When the system runs without IOMMU, the core handler tries to use the continuous pages with a single SGL entry. It works nicely for most cases, but when the system memory gets fragmented, the large allocation may fail frequently. Ideally the non-contig handler could deal with the proper SG pages, it's cumbersome to extend for now. As a workaround, here we add new types for (minimalistic) SG allocations, instead, so that the allocator falls back to those types automatically when the allocation with the standard API failed. BTW, one better (but pretty minor) improvement from the previous SG-buffer code is that this provides the proper mmap support without the PCM's page fault handling. Fixes: 2c95b92e ("ALSA: memalloc: Unify x86 SG-buffer handling (take#3)") BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2272 BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1198248 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220413054808.7547-1-tiwai@suse.deSigned-off-by:
-
- 12 Apr, 2022 15 commits
-
-
Takashi Iwai authored
The card destructor of nm256 driver does merely stopping the running streams, and it's superfluous for the probe error handling. Moreover, calling this via the previous devres change would lead to another problem due to the reverse call order. This patch moves the setup of the private_free callback after the card registration, so that it can be used only after fully set up. Fixes: c19935f0 ("ALSA: nm256: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-40-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The card destructor of nm256 driver does merely stopping the running timer, and it's superfluous for the probe error handling. Moreover, calling this via the previous devres change would lead to another problem due to the reverse call order. This patch moves the setup of the private_free callback after the card registration, so that it can be used only after fully set up. Fixes: aa92050f ("ALSA: mtpav: Allocate resources with device-managed APIs") Link: https://lore.kernel.org/r/20220412102636.16000-39-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: b1002b2d ("ALSA: rme9652: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-38-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 0195ca5f ("ALSA: hdspm: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-37-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: d136b8e5 ("ALSA: hdsp: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-36-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 596ae97a ("ALSA: oxygen: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-35-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 6f16c19b ("ALSA: lx6464es: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-34-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 87e082ad ("ALSA: cmipci: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-33-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 33631012 ("ALSA: aw2: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-32-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 21a9314c ("ALSA: als300: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-31-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 098fe3d6 ("ALSA: lola: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-30-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 9e80ed64 ("ALSA: bt87x: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-29-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres forgot to replace the snd_card_free() call with the devm version. Moreover, it still needs the manual call of snd_card_free() at the probe error path, otherwise the reverse order of the releases may happen. This patch addresses those issues. Fixes: 499ddc16 ("ALSA: sis7019: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-28-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 854577ac ("ALSA: x86: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-27-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: afaf9975 ("ALSA: via82xx: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-26-tiwai@suse.deSigned-off-by:
-
