sst_cdev_fragment_elapsed() was added in 2014 by
commit 7adab122a5 ("ASoC: Intel: sst - add compressed ops handling")
but has remained unused.
sst_get_stream_allocated() was added in 2014 by
commit cc547054d3 ("ASoC: Intel: sst - add pcm ops handling")
but has remained unused.
sst_wait_interruptible() was added in 2014 by
commit 60dc8dbacb ("ASoC: Intel: sst: Add some helper functions")
but has remained unused.
Remove them.
Signed-off-by: "Dr. David Alan Gilbert" <linux@treblig.org>
Link: https://patch.msgid.link/20250509003716.278416-1-linux@treblig.org
Signed-off-by: Mark Brown <broonie@kernel.org>
pci_request_regions() is a hybrid function which becomes managed if
pcim_enable_device() was called before. This hybrid nature is deprecated
and should not be used anymore.
Replace pci_request_regions() with the always-managed function
pcim_request_all_regions().
Remove the call to pci_release_regions(), since pcim_ functions do
cleanup automatically.
Pass 0 as length parameter to pcim_iomap(), which is the standard way
for ioremapping an entire BAR.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20250425081742.61623-5-phasta@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Some old Bay Trail tablets which shipped with Android as factory OS
have the SST/LPE audio engine described by an ACPI device with a
HID (Hardware-ID) of LPE0F28 instead of 80860F28.
Add support for this. Note this uses a new sst_res_info for just
the LPE0F28 case because it has a different layout for the IO-mem ACPI
resources then the 80860F28.
An example of a tablet which needs this is the Vexia EDU ATLA 10 tablet,
which has been distributed to schools in the Spanish Andalucía region.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patch.msgid.link/20241025090221.52198-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all drivers below sound/soc to use .remove(), with the eventual
goal to drop struct platform_driver::remove_new(). As .remove() and
.remove_new() have the same prototypes, conversion is done by just
changing the structure member name in the driver initializer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20240909151230.909818-2-u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
*-objs suffix is reserved rather for (user-space) host programs while
usually *-y suffix is used for kernel drivers (although *-objs works
for that purpose for now).
Let's correct the old usages of *-objs in Makefiles.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240507155540.24815-13-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
This patchset first fixes a number of errors made in the hda-mlink
support, then adds Lunar Lake definitions. The main contribution is
the hda-dai changes where the HDaudio DMA is now used for SSP, DMIC
and SoundWire. In previous hardware the GPDMA (aka DesignWare) was
used and controlled by the audio firmware. The volume of code is
minimized with the abstraction added in previous kernel cycles.
Due to cross-dependencies between ASoC and SoundWire trees, the full
support for jack detection will be deferred to the next kernel
cycle. There's not much point to ask for a sync of the two trees to
support one patch for each tree - we are at -rc5 already.
make KCFLAGS='-fanalyzer' sound/soc/intel/atom/ reports a possible
NULL pointer dereference.
sound/soc/intel/atom/sst/sst_stream.c:221:40: error: dereference of
NULL ‘block’ [CWE-476] [-Werror=analyzer-null-dereference]
221 | unsigned char *r = block->data;
This is a false-positive, the GCC analyzer generated that report by
considering if (bytes->block) as true in some cases and false in
others.
We can simplify the code and use a local variable so that static
analysis does not try to look for cases where bytes->block can be
modified concurrently.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Yaochun Hung <yc.hung@mediatek.com>
Link: https://lore.kernel.org/r/20230731213748.440285-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20230315150745.67084-94-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20230315150745.67084-93-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: Updates for v6.1
This has been a very quiet release for the core but quite a busy one for
drivers with a big crop of new drivers and lots of feature additions and
fixes to existing ones:
- A new string helper parse_int_array_user().
- Improvements to the SOF IPC4 code, especially around trace.
- Support for AMD Rembrant DSPs, AMD Pink Sardine ACP 6.2, Apple Silcon
systems, Everest ES8326, Intel Sky Lake and Kaby Lake, MediaTek
MT8186 support, NXP i.MX8ULP DSPs, Qualcomm SC8280XP, SM8250 and SM8450
and Texas Instruments SRC4392
There is a conflict with the conversion of I2C remove functions to void
in the cs42l42 driver which is fairly straightforward to resolve but
should be highlighted to Linus.
ASoC Atom SST driver is using the continuous RAM pages with GFP_DMA
flag for its PCM buffer, but this should work fine with the standard
DMA pages. As a part of cleanup work, this patch replaces the buffer
allocation to the standard device pages with SNDRV_DMA_TYPE_DEV.
Link: https://lore.kernel.org/r/20220823115740.14123-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
Currently the set_fmt callback always passes clock provider/consumer
with respect to the CODEC. This made sense when the framework was
directly broken down into platforms and CODECs. However, as things
are now broken down into components which can be connected as either
the CPU or CODEC side of a DAI link it simplifies things if each
side of the link is just told if it is provider or consumer of the
clocks. Making this change allows us to remove one of the last parts
of the ASoC core that needs to know if a driver is a CODEC driver,
where it flips the clock format specifier if a CODEC driver is used on
the CPU side of a DAI link, as well as just being conceptually more
consistent with componentisation.
The basic idea of this patch chain is to change the set_fmt callback
from specifying if the CODEC is provider/consumer into directly
specifying if the component is provider/consumer. To do this we add
some new defines, and then to preserve bisectability, the migration is
done by adding a new callback, converting over all existing CPU side
drivers, converting the core, and then finally reverting back to the
old callback.
Converting the platform drivers makes sense as the existing defines
are from the perspective of the CODEC and there are more CODEC drivers
than platform drivers.
Obviously a fair amount of this patch chain I was only able to build
test, so any testing that can be done would be greatly appreciated.
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
This code was transformed with the help of Coccinelle:
(next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file script.cocci --include-headers --dir . > output.patch)
@@
identifier S, member, array;
type T1, T2;
@@
struct S {
...
T1 member;
T2 array[
- 0
];
};
UAPI and wireless changes were intentionally excluded from this patch
and will be sent out separately.
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays
Link: https://github.com/KSPP/linux/issues/78
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
ASoC: Updates for v5.15
Quite a quiet release this time, mostly a combination of cleanups
and a good set of new drivers.
- Lots of cleanups and improvements to the Intel drivers,
including some new systems support.
- New support for AMD Vangoh, CUI CMM-4030D-261, Mediatek
Mt8195, Renesas RZ/G2L Mediatek Mt8195, RealTek RT101P,
Renesas RZ/G2L,, Rockchip RK3568 S/PDIF.
We worked around the breakage of PCM buffer setup by the commit
65ca89c2b1 ("ASoC: intel: atom: Fix breakage for PCM buffer address
setup"), but this isn't necessary since the CONTINUOUS buffer type
also sets runtime->dma_addr since commit f84ba106a0 ("ALSA:
memalloc: Store snd_dma_buffer.addr for continuous pages, too").
Let's revert the change again.
Link: https://lore.kernel.org/r/20210822072127.9786-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit 2e6b836312 ("ASoC: intel: atom: Fix reference to PCM
buffer address") changed the reference of PCM buffer address to
substream->runtime->dma_addr as the buffer address may change
dynamically. However, I forgot that the dma_addr field is still not
set up for the CONTINUOUS buffer type (that this driver uses) yet in
5.14 and earlier kernels, and it resulted in garbage I/O. The problem
will be fixed in 5.15, but we need to address it quickly for now.
The fix is to deduce the address again from the DMA pointer with
virt_to_phys(), but from the right one, substream->runtime->dma_area.
Fixes: 2e6b836312 ("ASoC: intel: atom: Fix reference to PCM buffer address")
Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com>
Cc: <stable@vger.kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/2048c6aa-2187-46bd-6772-36a4fb3c5aeb@redhat.com
Link: https://lore.kernel.org/r/20210819152945.8510-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
PCM buffers might be allocated dynamically when the buffer
preallocation failed or a larger buffer is requested, and it's not
guaranteed that substream->dma_buffer points to the actually used
buffer. The address should be retrieved from runtime->dma_addr,
instead of substream->dma_buffer (and shouldn't use virt_to_phys).
Also, remove the line overriding runtime->dma_area superfluously,
which was already set up at the PCM buffer allocation.
Cc: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20210728112353.6675-3-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The SST firmware's media and deep-buffer inputs are hardcoded to
S16LE, the corresponding DAIs don't have a hw_params callback and
their prepare callback also does not take the format into account.
So far the advertising of non working S24LE support has not caused
issues because pulseaudio defaults to S16LE, but changing pulse-audio's
config to use S24LE will result in broken sound.
Pipewire is replacing pulse now and pipewire prefers S24LE over S16LE
when available, causing the problem of the broken S24LE support to
come to the surface now.
Cc: stable@vger.kernel.org
BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866
Fixes: 098c2cd281 ("ASoC: Intel: Atom: add 24-bit support for media playback and capture")
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210324132711.216152-2-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
v5.12-rc1 flags new warnings with make W=1, fix missing or broken
function descriptors.
sound/soc/intel/atom/sst/sst_loader.c:85: warning: expecting prototype
for sst_start_merrifield(). Prototype was for sst_start_mrfld()
instead
sound/soc/intel/atom/sst/sst_acpi.c:339: warning: expecting prototype
for intel_sst_remove(). Prototype was for sst_acpi_remove() instead
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210301165349.114952-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SND_SST_IPC and its _PCI and _ACPI variants all target
sound/soc/intel/atom solution alone. SND_SST_IPC is the core component,
required for PCI and ACPI based atom platforms both. _PCI and _ACPI
target Merrifield/Edison and Baytrial/Cherrytrail platforms
respectively.
On top of that, there is an equivalent set of configs targeting the same
solution:
- SND_SST_ATOM_HIFI2_PLATFORM (core)
- SND_SST_ATOM_HIFI2_PLATFORM_PCI
- SND_SST_ATOM_HIFI2_PLATFORM_ACPI
As both sets do the same job - allow for granular platform selection -
remove the duplicate set and rely on SND_SST_ATOM_HIFI2_PLATOFRM_XXX
configs alone.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20201012095005.29859-1-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
