- 09 Feb, 2022 1 commit
-
-
Pierre-Louis Bossart authored
The existing code maximizes confusion by using 'stream' and 'hstream' variables of different types, e.g: struct hdac_stream *stream; struct hdac_ext_stream *stream; struct hdac_stream *hstream; struct hdac_ext_stream *hstream; This confusion is partly inherited from legacy code but SOF contributors added their own creative spin, e.g. struct hdac_ext_stream *link_dev; struct hdac_ext_stream *dsp_stream; struct hdac_ext_stream hda_stream; and my personal favorite: stream = &hda_stream->hda_stream; This patch suggests a consistent naming across all Intel code related to HDAudio stream management. The convention is - by hierarchical order: struct sof_intel_hda_stream *hda_stream; struct hdac_ext_stream *hext_stream; struct hdac_stream *hstream; No functionality change - just renaming of variables/members. Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Rander Wang <rander.wang@intel.com> Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220209063104.9971-1-peter.ujfalusi@linux.intel.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 08 Feb, 2022 12 commits
-
-
Mark Brown authored
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: Hi, the DMA trace implementation on AMD platform assumes that the stream_tag pointer is pointing the stream_tag member of struct sof_ipc_dma_trace_params_ext, which is true at the moment, but it can not be guarantied and a change in the dtrace core can cause out of bound accesses for AMD. For this reason, change the API to pass the struct itself which will remove the assumption and makes it clear from both sides what is expected to be sent via the parameter list. This opens up a window to clean up the intel and AMD implementation at the same time. Regards, Peter --- Peter Ujfalusi (2): ASoC: SOF: intel: hda-trace: Pass the dma buffer pointer to hda_dsp_trace_prepare ASoC: SOF: dma-trace: Pass pointer to params_ext struct in trace_init() sound/soc/sof/amd/acp-trace.c | 38 ++++++++------------------------- sound/soc/sof/amd/acp.h | 3 ++- sound/soc/sof/intel/hda-trace.c | 17 ++++++++------- sound/soc/sof/intel/hda.h | 3 ++- sound/soc/sof/ops.h | 4 ++-- sound/soc/sof/sof-priv.h | 2 +- sound/soc/sof/trace.c | 2 +- 7 files changed, 26 insertions(+), 43 deletions(-) -- 2.35.0 -
Mark Brown authored
Merge series from Mark Brown <broonie@kernel.org>: This series removes a bunch of spurious selects of gpiolib that were causing noise in randconfig build tests. Mark Brown (6): ASoC: dmic: Remove spurious gpiolib select ASoC: rt9120: Remove spurious gpiolib select ASoC: simple-amplifier: Remove spurious gpiolib select ASoC: max9759: Remove spurious gpiolib select ASoC: zl38060: Remove spurious gpiolib select ASoC: simple-mux: Depend on gpiolib rather than selecting it sound/soc/codecs/Kconfig | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) base-commit: e783362e -- 2.30.2
-
Sascha Hauer authored
The fsl_sai driver calculates the number of pins used and enables multiple channels if necessary. This means the SAI expects data in one FIFO per pin. The SDMA engine only services a single FIFO, so multi pin support doesn't work at all. This patch enables the software combine mode in chips that support it. With this the SAI presents only a single FIFO to the outside and distributes the data into the different FIFOs internally. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20220111081518.982437-1-s.hauer@pengutronix.deSigned-off-by:
-
Daniel Baluta authored
Implement snd_compress_ops. There are a lot of similarities with PCM implementation. For now we use sof_ipc_pcm_params to transfer compress parameters to SOF firmware. This will be changed in the future once we either add new compress parameters to SOF or enhance existing sof_ipc_pcm_params structure to support all native compress params. Note that get_caps and get_codec_caps are missing and will be added later. This is because we need to find a way to advertise DSP capabilities depending on supported platforms. Signed-off-by:
Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220120143741.492634-1-daniel.baluta@oss.nxp.comSigned-off-by:
-
Peter Ujfalusi authored
Instead of passing a pointer to the stream_tag within the struct sof_ipc_dma_trace_params_ext, pass the pointer to the containing struct. AMD needs to update buffer.phy_addr (and don't really use the stream_tag) for the trace implementation. Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220128123623.23569-3-peter.ujfalusi@linux.intel.comSigned-off-by:
-
Peter Ujfalusi authored
Pass the snd_dma_buffer pointer as parameter to hda_dsp_trace_prepare() function. Signed-off-by:
-
Mark Brown authored
The simple-mux driver requires gpiolib. Currently it selects GPIOLIB but since the use of select can lead to issues with randconfig let's instead depend on GPIOLIB, select is more idiomatically used for Kconfig symbols that are not user selectable but GPIOLIB is user selectable. Signed-off-by:
-
Mark Brown authored
The usage of GPIOs is optional in the code so don't force on gpiolib when building it, avoiding warnings in randconfigs. Signed-off-by:
-
Mark Brown authored
The usage of GPIOs is optional in the code so don't force on gpiolib when building it, avoiding warnings in randconfigs. Signed-off-by:
-
Mark Brown authored
The usage of GPIOs is optional in the code so don't force on gpiolib when building it, avoiding warnings in randconfigs. Signed-off-by:
-
Mark Brown authored
The usage of GPIOs is optional in the code so don't force on gpiolib when building it, avoiding warnings in randconfigs. Signed-off-by:
-
Mark Brown authored
The usage of GPIOs is optional in the code so don't force on gpiolib when building it, avoiding warnings in randconfigs. Signed-off-by:
-
- 03 Feb, 2022 7 commits
-
-
Mark Brown authored
Merge series from Samuel Holland <samuel@sholland.org>: This series extends the sun4i-i2s binding and driver to support some newer versions of the hardware. Each instance of the hardwar now has multiple input/output pins, and channels can be muxed between them. Since so far the driver only supports a "default" linear channel map, the driver changes are minimal. Samuel Holland (3): ASoC: dt-bindings: sun4i-i2s: Add compatibles for R329 and D1 ASoC: sun4i-i2s: Update registers for more channels ASoC: sun4i-i2s: Add support for the R329/D1 variant .../sound/allwinner,sun4i-a10-i2s.yaml | 5 ++ sound/soc/sunxi/sun4i-i2s.c | 68 +++++++++++++++---- 2 files changed, 59 insertions(+), 14 deletions(-) -- 2.33.1
-
Charles Keepax authored
The Madera CODECs use regmap_irq functions but nothing ensures that regmap_irq is built into the kernel. Add dependencies on the ASoC symbols for the relevant MFD component. There is no point in building the ASoC driver if the MFD doesn't support it and the MFD part contains the necessary dependencies to ensure everything is built into the kernel. Reported-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220203115025.16464-1-ckeepax@opensource.cirrus.comSigned-off-by:
-
Mark Brown authored
midas_wm811 uses gpiolib but relies on the header being implicitly included which can lead to build failures in some configurations, explicitly pull the header in to avoid problems. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20220202191322.3650708-1-broonie@kernel.orgSigned-off-by:
-
Charles Keepax authored
When the DMIC_ENA bit is set the analogue inputs are disconnected from the digital core of the chip, in favour of the digital microphones. Currently the driver will always enable DMIC_ENA whilst the GPIOs are configured for the DMIC function, this means the user can't currently use both the analog inputs and the digital inputs in one system. Add an additional DAPM mutex that allows switching between analog and digital inputs into the digital core. Reported-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by:
-
Samuel Holland authored
This adds a new set of quirks to set the right RX channel map. Since that is the only change to the register layout, reuse the H6 regmap config by extending its last register. R329 support is added by its compatible string. D1 uses R329 as its fallback compatible, so no additional code change is needed for it. Signed-off-by:
Samuel Holland <samuel@sholland.org> Acked-by:
Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220203020116.12279-4-samuel@sholland.orgSigned-off-by:
-
Samuel Holland authored
H6 expands the number of channels in each direction to 16, so the slot number fields need to be expanded from 3 to 4 bits each. R329/D1 expand that further by allowing each of the 16 slots to map to any of 4 data pins. For TX, the configuration of each pin is independent, so there is a copy of the mapping registers for each pin. For RX, each of the 16 slots can map to only one pin, so the registers were changed to add the pin selection inline with the channel mapping. Signed-off-by:
-
Samuel Holland authored
R329 contains I2S controllers which are similar to, but are incompatible with, the H6 variant, because they change the layout of the RX channel mapping registers. The D1 contains I2S controllers which appear to be identical to those in the R329. Signed-off-by:
-
- 31 Jan, 2022 1 commit
-
-
Randy Dunlap authored
Add a header file that provides the missing function prototypes and macro to fix these build errors (seen on arch/alpha/): ../sound/soc/codecs/max98927.c: In function 'max98927_i2c_probe': ../sound/soc/codecs/max98927.c:902:19: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? [-Werror=implicit-function-declaration] 902 | = devm_gpiod_get_optional(&i2c->dev, "reset", GPIOD_OUT_HIGH); | ^~~~~~~~~~~~~~~~~~~~~~~ ../sound/soc/codecs/max98927.c:902:63: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function); did you mean 'GPIOF_INIT_HIGH'? 902 | = devm_gpiod_get_optional(&i2c->dev, "reset", GPIOD_OUT_HIGH); | ^~~~~~~~~~~~~~ ../sound/soc/codecs/max98927.c:909:17: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] 909 | gpiod_set_value_cansleep(max98927->reset_gpio, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 4d67dc19 ("ASoC: max98927: Handle reset gpio when probing i2c") Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Cc: Alejandro Tafalla <atafalla@dnyon.com> Cc: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Link: https://lore.kernel.org/r/20220129080259.19964-1-rdunlap@infradead.orgSigned-off-by:
-
- 28 Jan, 2022 19 commits
-
-
Mark Brown authored
Merge series from Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>: These changes add PDM and PCI drivers for AMD ACP hardware.
-
Mark Brown authored
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: The series will drop the internal use of 'header' parameter which is always set to hdr->cmd. The other simplification is to use the provided message directly as it is guarantied to be valid throughout the message sending and we can save memory by not allocating a temporary buffer, also saving on needles memcpy() operations.
-
Mark Brown authored
Merge series from Brian Norris <briannorris@chromium.org>: This series fixes DP/HDMI audio for RK3399 Gru systems. First, there was a regression with the switch to SPDIF. Patch 1 can be taken separately as a regression fix if desired. But it's not quite so useful (at least on Chrome OS systems) without the second part. Second, jack detection was never upstreamed, because the hdmi-codec dependencies were still being worked out when this platform was first supported. base-commit: e783362e
-
Uwe Kleine-König authored
When disabling a regulator fails while the device goes away, there is little we can do and the machine is probably in enough trouble that any action we'd want to take fails anyhow. The return value used to be passed on in cs42l51_i2c_remove() (i.e. the i2c device remove callback). But the i2c core ignores the error code (apart from emitting a generic warning) and removes the device anyhow. So return 0 unconditionally in cs42l51_i2c_remove(), and instead of returning the error code to the upper layer emit a more helpful warning message. After that nobody is interested any more in the actual error code, so let cs42l51_remove() return void. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220110071832.306185-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Peter Ujfalusi authored
The sof_ipc_tx_message does not have support for async operations. There is no need to allocate a buffer and copy each message to it to be sent to the DSP, we can use the passed message data pointer directly. Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
-
Peter Ujfalusi authored
The snd_sof_ipc_msg.header is not used by platform code, there is no need to update it and the 'header' parameter for sof_ipc_tx_message_unlocked() can be dropped at the same time. Instead of using the header parameter passed by the caller (which does by setting it to the hdr->cmd) use the hdr->cmd directly when logging. At the same time make sure that there is a message passed to the tx_message function. All instances of the tx_message passes an IPC message, this check is placed to make sure the future users can not introduce bugs. Signed-off-by:
-
Peter Ujfalusi authored
Instead of first checking the msg->header (which is the hdr.cmd), use directly the cmd from the message itself. Signed-off-by:
-
Ajit Kumar Pandey authored
We have SOF and generic ACP support enabled for Renoir platforms on some machines. Since we have same PCI id used for probing, add check for machine configuration flag to avoid conflict with newer pci drivers. Such machine flag has been initialized via dmi match on few Chrome machines. If no flag is specified probe and register older platform device. Signed-off-by:
Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Link: https://lore.kernel.org/r/20220117115854.455995-7-AjitKumar.Pandey@amd.comSigned-off-by:
-
Ajit Kumar Pandey authored
Add DMIC related dai link for pdm-dmic dai on Renoir platform with generic dmic codec dai. Signed-off-by:
-
Ajit Kumar Pandey authored
ACP hardware has PGFSM control registers that can be configured to power On/Off the ACP IP block. Add acp init()/de_init() callbacks in renoir platform driver probe()/remove() respectively to power on and off ACP IP block on ACP3X device. Signed-off-by:
-
Ajit Kumar Pandey authored
Audio Co-processor or ACP IP block on AMD's SOC is connected via PCI bus interface, hence needs to be register as a PCI device. We have same PCI device ID across multiple SOC's but with different revision id for PCI hw. Add a generic PCI driver module for ACP that registers ACP as a PCI device and also register a platform device based on pci revision id. Any SOC's specific configuration for ACP block will be done in platform driver probe. We have added an initial support for ACP revision id 3 or ACP3X device. Signed-off-by:
-
Ajit Kumar Pandey authored
Renoir ACP IP has a PDM controller block. Add DMIC dai instance in dai_driver struct to enable dmic capture support on Renoir platform. Signed-off-by:
-
Ajit Kumar Pandey authored
Add driver module for PDM controller on ACP IP block. Expose dai ops to configure ACP_WOV_PDM_BLOCK registers on ACP. Such dai ops will be used by platform specific driver module to register dmic related dai with ASoC. Signed-off-by:
-
Brian Norris authored
Now that the cdn-dp driver supports plug-change callbacks, let's wire it up. Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20220114150129.v2.3.I3c79b1466c14b02980071221e5b99283cd26ec77@changeidSigned-off-by:
-
Brian Norris authored
Some audio servers like to monitor a jack device (perhaps combined with EDID, for audio-presence info) to determine DP/HDMI audio presence. Signed-off-by:
-
Mark Brown authored
Merge series from Sameer Pujar <spujar@nvidia.com>: This adds APE support on Tegra234 and enables sound card on Jetson AGX Orin platform.
-
Peter Ujfalusi authored
The first count check and fixup against "buffer - lpos" can be removed as we will do the adjustment later against the "avail" in sof_dfsentry_trace_read() Signed-off-by:
-
Rob Herring authored
There's no need to complicate examples with a platform specific macro. It also complicates example parsing to figure out the number of interrupt cells in examples (based on bracketing). Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220126231358.1637174-1-robh@kernel.orgSigned-off-by:
-
Ranjani Sridharan authored
The limitation to assign a link DMA channel for a BE iff the corresponding host DMA channel is assigned to a connected FE is only applicable if the PROCEN_FMT_QUIRK is set. So, remove it for platforms that do not enable the quirk. Complements: a792bfc1 ("ASoC: SOF: Intel: hda-stream: limit PROCEN workaround") Signed-off-by:
-
