Re: [PATCHv4 7/9] ASoC: fsl-asoc-card: add DT clock "cpu_sysclk" with generic codec
On Fri, May 17, 2024 at 05:05:35AM -0400, Elinor Montmasson wrote:
> From: "Mark Brown"
> > On Wed, May 15, 2024 at 03:54:09PM +0200, Elinor Montmasson wrote:
> >> + struct clk *cpu_sysclk = clk_get(>dev, "cpu_sysclk");
> >> + if (!IS_ERR(cpu_sysclk)) {
> >> + priv->cpu_priv.sysclk_freq[TX] =
> >> clk_get_rate(cpu_sysclk);
> >> + priv->cpu_priv.sysclk_freq[RX] =
> >> priv->cpu_priv.sysclk_freq[TX];
> >> + clk_put(cpu_sysclk);
> >> + }
> > I don't really understand the goal here - this is just reading whatever
> > frequency happens to be set in the hardware when the driver starts up
> > which if nothing else seems rather fragile?
> The driver allow to set the sysclk frequency
> of the CPU DAI through `priv->cpu_priv.sysclk_freq` when calling
> `fsl_asoc_card_hw_params()`.
> Currently it is hard-coded per use-case in the driver.
> My reasoning was that with a generic codec/compatible, there might
> be use-cases needing to use this parameter, so I exposed it here via DT.
> Is it a bad idea to expose this parameter ? This is not a requirement for the
> driver to work, most of the current compatibles do not use this parameter.
> It is currently used only for `fsl,imx-audio-cs42888`.
> In that case I can remove this commit.
I'm having a hard time connecting your reply here with my comment. This
isn't as far as I can see allowing the frequency to be explicitly
configured, it's just using whatever value happens to be programmed in
the clock when the driver starts.
signature.asc
Description: PGP signature
Re: [PATCHv4 9/9] ASoC: dt-bindings: fsl-asoc-card: add compatible for generic codec
On Fri, May 17, 2024 at 05:05:41AM -0400, Elinor Montmasson wrote: > From: "Mark Brown" > > This description (and the code) don't feel like they're actually generic > > - they're clearly specific to the bidrectional S/PDIF case. I'd expect > > something called -generic to cope with single CODECs as well as double, > > and not to have any constraints on what those are. > I proposed, in an reply of the v3 patch series to Krzysztof Kozlowski, > the compatible "fsl,imx-audio-no-codec" instead of "generic". > Krzysztof thought it was too generic, but it would convey more clearly > that it is for cases without codec driver. > Would this other compatible string be more appropriate ? No. There is very clearly a CODEC here, it physically exists, we can point at it on the board and it has a software representation. Your code is also very specific to the two CODEC case. signature.asc Description: PGP signature
Re: [PATCHv4 8/9] ASoC: fsl-asoc-card: add DT property "cpu-system-clock-direction-out"
On Fri, May 17, 2024 at 05:05:38AM -0400, Elinor Montmasson wrote: > This new compatible is intended to be used when there is no codec > device/driver. There is technically no codec device/driver for which > the clock input can be set. This is obviously not true, there clearly is a driver. > Is it a bad idea to allow setting the cpu sysclk direction only ? > Should the compatible be limited to use-cases where the cpu sysclk > direction cannot be set by the machine driver ? When I said "this should use the clock bindings" I meant that we should use the clock bindings for configuration here. signature.asc Description: PGP signature
Re: [PATCHv4 8/9] ASoC: fsl-asoc-card: add DT property "cpu-system-clock-direction-out"
On Wed, May 15, 2024 at 03:54:10PM +0200, Elinor Montmasson wrote: > Add new optional DT property "cpu-system-clock-direction-out" to set > sysclk direction as "out" for the CPU DAI when using the generic codec. > It is set for both Tx and Rx. > If not set, the direction is "in". > The way the direction value is used is up to the CPU DAI driver > implementation. This feels like we should be using the clock bindings to specify the clock input of whatever is using the output from the SoC, though that's a lot more work. signature.asc Description: PGP signature
Re: [PATCHv4 7/9] ASoC: fsl-asoc-card: add DT clock "cpu_sysclk" with generic codec
On Wed, May 15, 2024 at 03:54:09PM +0200, Elinor Montmasson wrote:
> Add an optional DT clock "cpu_sysclk" to get the CPU DAI system-clock
> frequency when using the generic codec.
> It is set for both Tx and Rx.
> The way the frequency value is used is up to the CPU DAI driver
> implementation.
> + struct clk *cpu_sysclk = clk_get(>dev, "cpu_sysclk");
> + if (!IS_ERR(cpu_sysclk)) {
> + priv->cpu_priv.sysclk_freq[TX] =
> clk_get_rate(cpu_sysclk);
> + priv->cpu_priv.sysclk_freq[RX] =
> priv->cpu_priv.sysclk_freq[TX];
> + clk_put(cpu_sysclk);
> + }
I don't really understand the goal here - this is just reading whatever
frequency happens to be set in the hardware when the driver starts up
which if nothing else seems rather fragile?
signature.asc
Description: PGP signature
Re: [PATCHv4 9/9] ASoC: dt-bindings: fsl-asoc-card: add compatible for generic codec
On Wed, May 15, 2024 at 03:54:11PM +0200, Elinor Montmasson wrote: > Add documentation about new dts bindings following new support > for compatible "fsl,imx-audio-generic". >audio-codec: > -$ref: /schemas/types.yaml#/definitions/phandle > -description: The phandle of an audio codec > +$ref: /schemas/types.yaml#/definitions/phandle-array > +description: | > + The phandle of an audio codec. > + If using the "fsl,imx-audio-generic" compatible, give instead a pair of > + phandles with the spdif_transmitter first (driver SPDIF DIT) and the > + spdif_receiver second (driver SPDIF DIR). > +items: > + maxItems: 1 This description (and the code) don't feel like they're actually generic - they're clearly specific to the bidrectional S/PDIF case. I'd expect something called -generic to cope with single CODECs as well as double, and not to have any constraints on what those are. signature.asc Description: PGP signature
Re: [PATCH 0/4] ASoC: Constify static snd_pcm_hardware
On Mon, 29 Apr 2024 13:48:45 +0200, Krzysztof Kozlowski wrote: > No dependencies. > > Static 'struct snd_pcm_hardware' is not modified by few drivers and its > copy is passed to the core, so it can be made const for increased code > safety. > > Best regards, > Krzysztof > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/4] ASoC: qcom: Constify static snd_pcm_hardware commit: e6fa3509cb32df373b15212a99f69a6595efd1c3 [2/4] ASoC: fsl: Constify static snd_pcm_hardware commit: ed90156037659473ee95eafe3f72d8498e5384ff [3/4] ASoC: meson: Constify static snd_pcm_hardware commit: 7b5ce9f0c52a5885d34d46bba62e9eaedc3dd459 [4/4] ASoC: uniphier: Constify static snd_pcm_hardware commit: 74a15fabd271d0fd82ceecbbfa1b98ea0a4709dd All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 00/13] ASoC: Use snd_soc_substream_to_rtd() for accessing private_data
On Tue, 30 Apr 2024 16:02:09 +0200, Krzysztof Kozlowski wrote: > Do not open-code snd_soc_substream_to_rtd() when accessing > snd_pcm_substream->private_data. This makes code more consistent with > rest of ASoC and allows in the future to move the field to any other > place or add additional checks in snd_soc_substream_to_rtd(). > > Best regards, > Krzysztof > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [01/13] ASoC: qcom: Use snd_soc_substream_to_rtd() for accessing private_data commit: 77678a25d1ecf70dc1d7ea2c0ab7609af15b83d3 [02/13] ASoC: tegra: Use snd_soc_substream_to_rtd() for accessing private_data commit: 3beb985abbf29e660edd1708f8a120ae9bbbddc3 [03/13] ASoC: ti: Use snd_soc_substream_to_rtd() for accessing private_data commit: 72a666f47f958a57db16b6bdd9ed385674069693 [04/13] ASoC: arm: Use snd_soc_substream_to_rtd() for accessing private_data commit: a80f2f8443a4ae10c568566f57fe704ea52c5bdb [05/13] ASoC: amd: Use snd_soc_substream_to_rtd() for accessing private_data commit: a84d84077512fc64cf1fc2292a3638690a026737 [06/13] ASoC: fsl: Use snd_soc_substream_to_rtd() for accessing private_data commit: b695d8be5bba9897ee670ec102ca608ecaf625c4 [07/13] ASoC: img: Use snd_soc_substream_to_rtd() for accessing private_data commit: 3b62178720594e08bdf8a87515ccca0328fe41fe [08/13] ASoC: kirkwood: Use snd_soc_substream_to_rtd() for accessing private_data commit: fe42c3b75b93dee9a4010e2297f1783e48684af7 [09/13] ASoC: loongson: Use snd_soc_substream_to_rtd() for accessing private_data commit: ffad75cebb865fef6f8e40f921c08c79a8faf7e3 [10/13] ASoC: mediatek: Use snd_soc_substream_to_rtd() for accessing private_data commit: 410a45140fb76709cf2bbad84bc8a731acf632c8 [11/13] ASoC: meson: Use snd_soc_substream_to_rtd() for accessing private_data commit: 22f5680a9cbc7388f97e5386c15c325d6961b958 [12/13] ASoC: samsung: Use snd_soc_substream_to_rtd() for accessing private_data commit: 3e726593107d134221f666b4f2be612b278c3ddb [13/13] ASoC: sunxi: Use snd_soc_substream_to_rtd() for accessing private_data commit: 47aa51677c975a5f66bc93d1c527e8878cf34d6c All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v4 00/29] arm64: Permission Overlay Extension
On Fri, May 03, 2024 at 02:01:18PM +0100, Joey Gouly wrote: > One possible issue with this version, I took the last bit of HWCAP2. Fortunately we already have AT_HWCAP[34] defined thanks to PowerPC. signature.asc Description: PGP signature
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On Thu, May 02, 2024 at 10:26:43AM +0100, Mauro Carvalho Chehab wrote: > Mauro Carvalho Chehab escreveu: > > There are still time control associated with it, as audio and video > > needs to be in sync. This is done by controlling the buffers size > > and could be fine-tuned by checking when the buffer transfer is done. ... > Just complementing: on media, we do this per video buffer (or > per half video buffer). A typical use case on cameras is to have > buffers transferred 30 times per second, if the video was streamed > at 30 frames per second. IIRC some big use case for this hardware was transcoding so there was a desire to just go at whatever rate the hardware could support as there is no interactive user consuming the output as it is generated. > I would assume that, on an audio/video stream, the audio data > transfer will be programmed to also happen on a regular interval. With audio the API is very much "wake userspace every Xms". signature.asc Description: PGP signature
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On Tue, Apr 30, 2024 at 05:27:52PM +0100, Mauro Carvalho Chehab wrote: > Mark Brown escreveu: > > On Tue, Apr 30, 2024 at 10:21:12AM +0200, Sebastian Fricke wrote: > > The discussion around this originally was that all the audio APIs are > > very much centered around real time operations rather than completely > The media subsystem is also centered around real time. Without real > time, you can't have a decent video conference system. Having > mem2mem transfers actually help reducing real time delays, as it > avoids extra latency due to CPU congestion and/or data transfers > from/to userspace. Real time means strongly tied to wall clock times rather than fast - the issue was that all the ALSA APIs are based around pushing data through the system based on a clock. > > That doesn't sound like an immediate solution to maintainer overload > > issues... if something like this is going to happen the DRM solution > > does seem more general but I'm not sure the amount of stop energy is > > proportionate. > I don't think maintainer overload is the issue here. The main > point is to avoid a fork at the audio uAPI, plus the burden > of re-inventing the wheel with new codes for audio formats, > new documentation for them, etc. I thought that discussion had been had already at one of the earlier versions? TBH I've not really been paying attention to this since the very early versions where I raised some similar "why is this in media" points and I thought everyone had decided that this did actually make sense. signature.asc Description: PGP signature
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On Tue, Apr 30, 2024 at 10:21:12AM +0200, Sebastian Fricke wrote: > first of all thanks for all of this work and I am very sorry for only > emerging this late into the series, I sadly didn't notice it earlier. It might be worth checking out the discussion on earlier versions... > 1. The biggest objection is, that the Linux Kernel has a subsystem > specifically targeted for audio devices, adding support for these > devices in another subsystem are counterproductive as they work around > the shortcomings of the audio subsystem while forcing support for a > device into a subsystem that was never designed for such devices. > Instead, the audio subsystem has to be adjusted to be able to support > all of the required workflows, otherwise, the next audio driver with > similar requirements will have to move to the media subsystem as well, > the audio subsystem would then never experience the required change and > soon we would have two audio subsystems. The discussion around this originally was that all the audio APIs are very much centered around real time operations rather than completely async memory to memory operations and that it's not clear that it's worth reinventing the wheel simply for the sake of having things in ALSA when that's already pretty idiomatic for the media subsystem. It wasn't the memory to memory bit per se, it was the disconnection from any timing. > So instead of hammering a driver into the wrong destination, I would > suggest bundling our forces and implementing a general memory-to-memory > framework that both the media and the audio subsystem can use, that > addresses the current shortcomings of the implementation and allows you > to upload the driver where it is supposed to be. That doesn't sound like an immediate solution to maintainer overload issues... if something like this is going to happen the DRM solution does seem more general but I'm not sure the amount of stop energy is proportionate. signature.asc Description: PGP signature
Re: [PATCH 0/2] ASoC: fsl-asoc-card: add wm8904 codec support
On Mon, 15 Apr 2024 15:17:34 +0800, Shengjiu Wang wrote: > add wm8904 codec support in fsl-asoc-card. > > Shengjiu Wang (2): > ASoC: fsl-asoc-card: add wm8904 codec support > ASoC: dt-bindings: fsl-asoc-card: Add compatbile string for wm8904 > codec > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: fsl-asoc-card: add wm8904 codec support commit: 51f67862ea6ea83f9fa4cda2e59d7bfd4387f63b [2/2] ASoC: dt-bindings: fsl-asoc-card: Add compatbile string for wm8904 codec commit: 62c48dd33b4f2e037554d1322ae4f9f60e9461ef All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v3 0/5] ASoC: fsl: Support register and unregister rpmsg sound card through remoteproc
On Mon, 11 Mar 2024 20:13:44 +0900, Chancel Liu wrote: > echo /lib/firmware/fw.elf > /sys/class/remoteproc/remoteproc0/firmware > (A) echo start > /sys/class/remoteproc/remoteproc0/state > (B) echo stop > /sys/class/remoteproc/remoteproc0/state > > The rpmsg sound card is registered in (A) and unregistered in (B). > After "start", imx-audio-rpmsg registers devices for ASoC platform driver > and machine driver. Then sound card is registered. After "stop", > imx-audio-rpmsg unregisters devices for ASoC platform driver and machine > driver. Then sound card is unregistered. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/5] ASoC: fsl: imx-pcm-rpmsg: Register component with rpmsg channel name commit: 41f96cd53f2838ac4894491ac5eadb06f1e5b858 [2/5] ASoC: fsl: imx-audio-rpmsg: Register device with rpmsg channel name commit: dacc7459745df168152b5cceba34efade9b5e063 [3/5] ASoC: fsl: Let imx-audio-rpmsg register platform device for card commit: c73524768e9e1a7ac9eb3a4d36a1ac0d34f22644 [4/5] ASoC: fsl: fsl_rpmsg: Register CPU DAI with name of rpmsg channel commit: 0aa7f5406afa828a93d84d75c9b9ac991cd75367 [5/5] ASoC: fsl: imx-rpmsg: Update to correct DT node commit: c14445bdcb98feddf9afaeb05e6193cc1f8eec1a All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v1 1/1] ASoC: fsl: imx-es8328: Remove leftover gpio initialisation
On Mon, 25 Mar 2024 21:13:41 +0200, Andy Shevchenko wrote: > The gpio field is not used anymore, remove the leftover. > This also fixes the compilation error after the ... > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl: imx-es8328: Remove leftover gpio initialisation commit: 6a92834166b16babd70e99c3e0ce9262893ad6ae All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2 1/1] ASoC: fsl: imx-es8328: Switch to using gpiod API
On Mon, 18 Mar 2024 22:07:56 +0200, Andy Shevchenko wrote: > This updates the driver to gpiod API, and removes yet another use of > of_get_named_gpio(). > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl: imx-es8328: Switch to using gpiod API commit: 9855f05e553637f05494cf47a3154cbf9a5cfc67 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 1/1] ASoC: fsl: fsl_ssi: Add dev_err_probe if PCM DMA init fails
On Thu, 14 Mar 2024 15:16:42 +0100, Alexander Stein wrote: > This happens especially if this driver is built-in, but SDMA driver > is configured as module. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl: fsl_ssi: Add dev_err_probe if PCM DMA init fails commit: 3ca49e7f9475ac06614edf1bfece123eafbdf8f3 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: soc-card: Fix missing locking in snd_soc_card_get_kcontrol()
On Wed, 21 Feb 2024 12:37:10 +, Richard Fitzgerald wrote: > snd_soc_card_get_kcontrol() must be holding a read lock on > card->controls_rwsem while walking the controls list. > > Compare with snd_ctl_find_numid(). > > The existing function is renamed snd_soc_card_get_kcontrol_locked() > so that it can be called from contexts that are already holding > card->controls_rwsem (for example, control get/put functions). > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: soc-card: Fix missing locking in snd_soc_card_get_kcontrol() commit: eba2eb2495f47690400331c722868902784e59de All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v1] spi: spi-ppc4xx: include missing platform_device.h
On Fri, 09 Feb 2024 15:59:07 +0100, Christian Lamparter wrote: > the driver currently fails to compile on 6.8-rc3 due to: > | spi-ppc4xx.c: In function ‘spi_ppc4xx_of_probe’: > | @346:36: error: invalid use of undefined type ‘struct platform_device’ > | 346 | struct device_node *np = op->dev.of_node; > | |^~ > | ... (more similar errors) > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/1] spi: spi-ppc4xx: include missing platform_device.h commit: 9f208e097801f9c2088eb339a1162fff81c08b4e All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2 0/3] ASoC: Support SAI and MICFIL on i.MX95 platform
On Fri, 12 Jan 2024 14:43:28 +0900, Chancel Liu wrote: > Support SAI and MICFIL on i.MX95 platform > > changes in v2 > - Remove unnecessary "item" in fsl,micfil.yaml > - Don't change alphabetical order in fsl,sai.yaml > > Chancel Liu (3): > ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform > ASoC: fsl_sai: Add support for i.MX95 platform > ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX95 > platform > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/3] ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform commit: 52523f70fdf9b2cb0bfd1999eba4aa3a30b04fa6 [2/3] ASoC: fsl_sai: Add support for i.MX95 platform commit: 2f2d78e2c29347a96268f6f34092538b307ed056 [3/3] ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX95 platform commit: 20d2719937cf439602566a8f041d3208274abc01 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_rpmsg: Fix error handler with pm_runtime_enable
On Mon, 25 Dec 2023 17:06:08 +0900, Chancel Liu wrote: > There is error message when defer probe happens: > > fsl_rpmsg rpmsg_audio: Unbalanced pm_runtime_enable! > > Fix the error handler with pm_runtime_enable. > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_rpmsg: Fix error handler with pm_runtime_enable commit: f9d378fc68c43fd41b35133edec9cd902ec334ec All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2] ASoC: fsl_sai: Fix channel swap issue on i.MX8MP
On Tue, 19 Dec 2023 10:30:57 +0800, Shengjiu Wang wrote: > When flag mclk_with_tere and mclk_direction_output enabled, > The SAI transmitter or receiver will be enabled in very early > stage, that if FSL_SAI_xMR is set by previous case, > for example previous case is one channel, current case is > two channels, then current case started with wrong xMR in > the beginning, then channel swap happen. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_sai: Fix channel swap issue on i.MX8MP commit: 8f0f01647550daf9cd8752c1656dcb0136d79ce1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_mqs: remove duplicated including
On Fri, 15 Dec 2023 17:13:51 +0800, Wang Jinchao wrote: > rm the second \#include > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_mqs: remove duplicated including commit: e7a4a2fd9a4116286a1523ea1a5cbabd2c36f5b9 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes
On Wed, Nov 08, 2023 at 01:58:36PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The VDSO functions are defined as globals in the kernel sources but intended
> to be called from userspace, so there is no need to declare them in a kernel
> side header.
This is in -next as commit 42874e4eb35bdfc54f8514685e50434098ba4f6c and
breaks an arm64 defconfig build, the 32 bit vDSO build is broken:
/build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.c:10:5: error: conflic
ting types for ‘__vdso_clock_gettime’; have ‘int(clockid_t, struct old_timespec
32 *)’ {aka ‘int(int, struct old_timespec32 *)’}
10 | int __vdso_clock_gettime(clockid_t clock,
| ^~~~
In file included from /build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.
c:8:
/build/stage/linux/include/vdso/gettime.h:16:5: note: previous declaration of
‘__vdso_clock_gettime’ with type ‘int(clockid_t, struct __kernel_timespec *)’
{aka ‘int(int, struct __kernel_timespec *)’}
16 | int __vdso_clock_gettime(clockid_t clock, struct __kernel_timespec *ts);
| ^~~~
/build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.c:28:5: error:
conflicting types for ‘__vdso_clock_getres’; have ‘int(clockid_t, struct
old_timespec32 *)’ {aka ‘int(int, struct old_timespec32 *)’}
28 | int __vdso_clock_getres(clockid_t clock_id,
| ^~~
/build/stage/linux/include/vdso/gettime.h:15:5: note: previous declaration of
‘__vdso_clock_getres’ with type ‘int(clockid_t, struct __kernel_timespec *)’
{aka ‘int(int, struct __kernel_timespec *)’}
15 | int __vdso_clock_getres(clockid_t clock, struct __kernel_timespec *res);
| ^~~
signature.asc
Description: PGP signature
Re: [PATCH] ASoC: fsl_xcvr: refine the requested phy clock frequency
On Thu, 23 Nov 2023 09:14:53 +0800, Shengjiu Wang wrote: > As the input phy clock frequency will divided by 2 by default > on i.MX8MP with the implementation of clk-imx8mp-audiomix driver, > So the requested frequency need to be updated. > > The relation of phy clock is: > sai_pll_ref_sel >sai_pll > sai_pll_bypass > sai_pll_out > sai_pll_out_div2 >earc_phy_cg > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_xcvr: refine the requested phy clock frequency commit: 347ecf29a68cc8958fbcbd26ef410d07fe9d82f4 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: (subset) [PATCH 1/2] ASoC: fsl: mpc8610_hpcd: Remove unused driver
On Wed, 22 Nov 2023 17:27:11 +1100, Michael Ellerman wrote:
> The mpc8610_hpcd.c driver depends on CONFIG_MPC8610_HPCD which was
> removed in commit 248667f8bbde ("powerpc: drop HPCD/MPC8610 evaluation
> platform support"). That makes the driver unbuildable and unusable, so
> remove it.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: fsl: mpc8610_hpcd: Remove unused driver
commit: b1cea462a79316bd619173f1ded8b28202b5ce3a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
Re: [PATCH] ASoC: fsl_xcvr: Enable 2 * TX bit clock for spdif only case
On Wed, 22 Nov 2023 09:42:53 +0800, Shengjiu Wang wrote: > The bit 10 in TX_DPTH_CTRL register controls the TX clock rate. > If this bit is set, TX datapath clock should be = 2* TX bit rate. > If this bit is not set, TX datapath clock should be 10* TX bit rate. > > As the spdif only case, we always use 2 * TX bit clock, so > this bit need to be set. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_xcvr: Enable 2 * TX bit clock for spdif only case commit: c33fd110424dfcb544cf55a1b312f43fe1918235 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 2/2] ASoC: cs4270: Remove unused codec
On Wed, Nov 22, 2023 at 05:27:12PM +1100, Michael Ellerman wrote: > The only driver to enable SND_SOC_CS4270 was SND_SOC_MPC8610_HPCD, which > was dropped in the preceding commit. Remove the codec as unused. There's no real overhead from having extra drivers and we do have generic drivers that people can attach CODECs to. signature.asc Description: PGP signature
Re: [PATCH v5 1/2] ASoC: dt-bindings: sound-card-common: List sound widgets ignoring system suspend
On Tue, 21 Nov 2023 13:25:11 +0800, Chancel Liu wrote: > Add a property to list audio sound widgets which are marked ignoring > system suspend. Paths between these endpoints are still active over > suspend of the main application processor that the current operating > system is running. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: dt-bindings: sound-card-common: List sound widgets ignoring system suspend commit: 27c69d7da1084af0b8b3a20ef9ff01e9eda5270c [2/2] ASoC: imx-rpmsg: Force codec power on in low power audio mode commit: 5d9f746ca64c3ebfba3b650dbc4b0de705c83f3b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v4 2/2] ASoC: imx-rpmsg: Force codec power on in low power audio mode
On Mon, Oct 23, 2023 at 10:07:18AM +0800, Chancel Liu wrote: > Low power audio mode requires binding codec still power on while Acore > enters into suspend so Mcore can continue playback music. > > ASoC machine driver acquires DAPM endpoints through reading > "ignore-suspend-widgets" property from DT and then forces the path > between these endpoints ignoring suspend. This breaks an x86 allmodconfig build: /build/stage/linux/sound/soc/fsl/imx-rpmsg.c: In function ‘imx_rpmsg_late_probe’ : /build/stage/linux/sound/soc/fsl/imx-rpmsg.c:60:46: error: implicit declaration of function ‘of_find_device_by_node’; did you mean ‘of_find_i2c_device_by_node’? [-Werror=implicit-function-declaration] 60 | codec_pdev = of_find_device_by_node(code c_np); | ^~ | of_find_i2c_device_by_node /build/stage/linux/sound/soc/fsl/imx-rpmsg.c:60:44: error: assignment to ‘struct platform_device *’ from ‘int’ makes pointer from integer without a cast [-Werro r=int-conversion] 60 | codec_pdev = of_find_device_by_node(codec_np); |^ cc1: all warnings being treated as errors signature.asc Description: PGP signature
Re: [PATCH] ASoC: fsl_mqs: Remove duplicate linux/of.h header
On Sun, 19 Nov 2023 10:45:14 +, Lucas Tanure wrote: > Remove linux/of.h as is included more than once. > Reported by make includecheck. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_mqs: Remove duplicate linux/of.h header commit: cac15dc25f416972f8dd0b6a8d74daa79dc3a998 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_sai: Fix no frame sync clock issue on i.MX8MP
On Mon, 20 Nov 2023 18:05:35 +0800, Shengjiu Wang wrote: > On i.MX8MP, when the TERE and FSD_MSTR enabled before configuring > the word width, there will be no frame sync clock issue, because > old word width impact the generation of frame sync. > > TERE enabled earlier only for i.MX8MP case for the hardware limitation, > So need to disable FSD_MSTR before configuring word width, then enable > FSD_MSTR bit for this specific case. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_sai: Fix no frame sync clock issue on i.MX8MP commit: 14e8442e0789598514f3c9de014950de9feda7a4 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 34/34] KVM: selftests: Add a memory region subtest to validate invalid flags
On Wed, Nov 08, 2023 at 05:08:01PM -0800, Anish Moorthy wrote: > Applying [1] and [2] reveals that this also breaks non-x86 builds- the > MEM_REGION_GPA/SLOT definitions are guarded behind an #ifdef > __x86_64__, while the usages introduced here aren't. > > Should > > On Sun, Nov 5, 2023 at 8:35 AM Paolo Bonzini wrote: > > > > + test_invalid_memory_region_flags(); > > be #ifdef'd, perhaps? I'm not quite sure what the intent is. This has been broken in -next for a week now, do we have any progress on a fix or should we just revert the patch? signature.asc Description: PGP signature
Re: [PATCH v9 00/27] Add support for QMC HDLC, framer infrastructure and PEF2256 framer
On Fri, Nov 17, 2023 at 04:47:46PM -0800, Jakub Kicinski wrote: > On Wed, 15 Nov 2023 15:39:36 +0100 Herve Codina wrote: > >- Removed Patches 6, 7 and 8 (patches applied) > > > >- Patches 7, 20, 21, 23 (patches 10, 23, 24, 26 in v8) > > Add 'Acked-by: Jakub Kicinski ' > I thought someone (Mark?) asked for the networking stuff to be put > on a branch. If that's still the preference - is it possible to factor > these out as a standalone series, too? Will they build on their own? Yes, can we *please* at least get the generic non-driver bits of this series moving - they seem uncontroversial as far as I can see and are a tiny portion of the overall 20 patches. Patches 21-23 look like they can go on a branch in the net tree? signature.asc Description: PGP signature
Re: [PATCH v4 1/2] ASoC: dt-bindings: sound-card-common: List sound widgets ignoring system suspend
On Thu, Oct 26, 2023 at 12:58:42PM -0500, Rob Herring wrote: > On Mon, Oct 23, 2023 at 10:07:17AM +0800, Chancel Liu wrote: > > Add a property to list audio sound widgets which are marked ignoring > > system suspend. Paths between these endpoints are still active over > > suspend of the main application processor that the current operating > > system is running. > Perhaps it would be better to define components used for low power > audio rather than the OS mode that gets used. Isn't LPA just audio > handling that doesn't require the OS CPU to be involved? So the state of > the CPU is kind of orthogonal. Not really - you can have bypass paths that don't touch the AP but which will have the power cut if the AP goes into suspend and it can be a system integration decision which components that will be true for. Often it's an inflexible PMIC/MCU setup managing the lowest system power states. The pure low power audio bit we should already be able to figure out. signature.asc Description: PGP signature
Re: [PATCH v8 00/30] Add support for QMC HDLC, framer infrastructure and PEF2256 framer
On Wed, Oct 25, 2023 at 12:32:15PM -0700, Jakub Kicinski wrote: > On Wed, 25 Oct 2023 17:00:51 +0200 Herve Codina wrote: > > > Which way will those patches go? Via some FSL SoC tree? > > This series seems mature now. > > What is the plan next in order to have it applied ? > > Don't hesitate to tell me if you prefer split series. > FWIW we are happy to take the drivers/net/ parts if there is no hard > dependency. But there's no point taking that unless the SoC bits > also go in for 6.7. > Li Yang, what are your expectations WRT merging this series? I did previously ask for the generic framer bit as a tag so I could apply the ASoC part but nobody responded and I've been getting repeated resends of the series :( signature.asc Description: PGP signature
Re: [PATCH v2] ASoC: fsl: Fix PM disable depth imbalance in fsl_easrc_probe
On Thu, 12 Oct 2023 21:03:15 +0800, Zhang Shurong wrote: > The pm_runtime_enable will increase power disable depth. Thus > a pairing decrement is needed on the error handling path to > keep it balanced according to context. We fix it by calling > pm_runtime_disable when error returns. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl: Fix PM disable depth imbalance in fsl_easrc_probe commit: 9e630efb5a4af56fdb15aa10405f5cfd3f5f5b83 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: Re: [PATCH v3 1/2] ASoC: dt-bindings: sound-card-common: List DAPM endpoints ignoring system suspend
On Mon, Oct 16, 2023 at 12:08:56PM +, Chancel Liu wrote: > Thanks Mark and Rob for your advice. In fact, it's common use case. We can see > many drivers set widgets ignoring suspend. I will remove the linux specifics > and focus on the key concept. How about the modification on the property name > and description as following: > ignore-suspend-widgets: > description: | > A list of audio sound widgets which are marked ignoring system suspend. > Paths between these endpoints are still active over suspend of the > main > application processor that the current operating system is running. That's probably fine from my point of view. There's likely a better way of saying system suspend but I'm not immediately seeing it and it could always be improved later. signature.asc Description: PGP signature
Re: [RFC PATCH v6 05/11] ASoC: fsl_easrc: register m2m platform device
On Fri, Oct 13, 2023 at 04:30:59PM +0800, Shengjiu Wang wrote: > Register m2m platform device,that user can > use M2M feature. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [RFC PATCH v6 04/11] ASoC: fsl_asrc: register m2m platform device
On Fri, Oct 13, 2023 at 04:30:58PM +0800, Shengjiu Wang wrote: > Register m2m platform device, that user can > use M2M feature. > > Defined platform data structure and platform > driver name. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [RFC PATCH v6 03/11] ASoC: fsl_asrc: move fsl_asrc_common.h to include/sound
On Fri, Oct 13, 2023 at 04:30:57PM +0800, Shengjiu Wang wrote: > Move fsl_asrc_common.h to include/sound that it can be > included from other drivers. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [RFC PATCH v6 02/11] ASoC: fsl_easrc: define functions for memory to memory usage
On Fri, Oct 13, 2023 at 04:30:56PM +0800, Shengjiu Wang wrote: > ASRC can be used on memory to memory case, define several > functions for m2m usage and export them as function pointer. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [RFC PATCH v6 01/11] ASoC: fsl_asrc: define functions for memory to memory usage
On Fri, Oct 13, 2023 at 04:30:55PM +0800, Shengjiu Wang wrote: > ASRC can be used on memory to memory case, define several > functions for m2m usage. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH v3 1/2] ASoC: dt-bindings: sound-card-common: List DAPM endpoints ignoring system suspend
On Wed, Oct 11, 2023 at 07:47:58PM +0800, Chancel Liu wrote: > + lpa-widgets: > +$ref: /schemas/types.yaml#/definitions/non-unique-string-array > +description: | > + A list of DAPM endpoints which mark paths between these endpoints > should > + not be disabled when system enters in suspend state. LPA means low > power > + audio case. For example on asymmetric multiprocessor, there are > Cortex-A I suspect that the DT maintainers would prefer that this description be workshopped a bit to remove the Linux specifics. I think the key thing here is that these are endpoints that can be active over suspend of the main application processor that the current operating system is running (system DT stuff is an interesting corner case here...), and the example is probably a bit specific. Other bindings use "audio sound widgets" rather than "DAPM widgets". We also shouldn't see that these endpoints "should not be disabled" since that implies that they should be left on even if they aren't active which isn't quite the case, instead it's that we can continue playing an audio stream through them in suspend. signature.asc Description: PGP signature
Re: [PATCH v3 0/5] ASoC: DT matching and header cleanups
On Fri, 06 Oct 2023 15:09:09 -0500, Rob Herring wrote: > (trimmed the recipient list due to bounces on v1) > > This is a series is part of ongoing clean-ups related to device > matching and DT related implicit includes. Essentially of_device.h has > a bunch of implicit includes and generally isn't needed any nore except > for of_match_device(). As we also generally want to get rid of > of_match_device() as well, I've done that so we're not updating the > includes twice. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/5] ASoC: Explicitly include correct DT includes commit: 340d79a14d6ab5066ba40651764db20bd151aea7 [2/5] ASoC: Drop unnecessary of_match_device() calls commit: 56c075b2d31c626370481a62d334a0575f751522 [3/5] ASoC: da7218: Use i2c_get_match_data() commit: fe26425518862020449cb2c9709e62cc76a56de2 [4/5] ASoC: qcom/lpass: Constify struct lpass_variant commit: ec5236c2e6ec1ce62237a2e9345dd2ffc4fc6d56 [5/5] ASoC: Use device_get_match_data() commit: 9958d85968ed2df4b704105fd2a9c3669eb9cd97 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2 0/5] ASoC: DT matching and header cleanups
On Wed, 04 Oct 2023 10:58:04 -0500, Rob Herring wrote: > (trimmed the recipient list due to bounces on v1) > > This is a series is part of ongoing clean-ups related to device > matching and DT related implicit includes. Essentially of_device.h has > a bunch of implicit includes and generally isn't needed any nore except > for of_match_device(). As we also generally want to get rid of > of_match_device() as well, I've done that so we're not updating the > includes twice. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/5] ASoC: Explicitly include correct DT includes commit: 340d79a14d6ab5066ba40651764db20bd151aea7 [2/5] ASoC: Drop unnecessary of_match_device() calls commit: 56c075b2d31c626370481a62d334a0575f751522 [3/5] ASoC: da7218: Use i2c_get_match_data() commit: fe26425518862020449cb2c9709e62cc76a56de2 [4/5] ASoC: qcom/lpass: Constify struct lpass_variant commit: ec5236c2e6ec1ce62237a2e9345dd2ffc4fc6d56 [5/5] ASoC: Use device_get_match_data() commit: 9958d85968ed2df4b704105fd2a9c3669eb9cd97 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH RESEND 0/5] ASoC: DT matching and header cleanups
On Tue, 03 Oct 2023 13:13:09 -0500, Rob Herring wrote: > (Got a bunch of bounces on the first try. Something weird going on with > the To header best I can tell. Retrying with git-send-email instead of > b4.) > > This is a series is part of ongoing clean-ups related to device > matching and DT related implicit includes. Essentially of_device.h has > a bunch of implicit includes and generally isn't needed any nore except > for of_match_device(). As we also generally want to get rid of > of_match_device() as well, I've done that so we're not updating the > includes twice. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/5] ASoC: Explicitly include correct DT includes commit: 340d79a14d6ab5066ba40651764db20bd151aea7 [2/5] ASoC: Drop unnecessary of_match_device() calls commit: 56c075b2d31c626370481a62d334a0575f751522 [3/5] ASoC: da7218: Use i2c_get_match_data() commit: fe26425518862020449cb2c9709e62cc76a56de2 [4/5] ASoC: qcom/lpass: Constify struct lpass_variant commit: ec5236c2e6ec1ce62237a2e9345dd2ffc4fc6d56 [5/5] ASoC: Use device_get_match_data() commit: 9958d85968ed2df4b704105fd2a9c3669eb9cd97 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [EXT] Re: Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend
On Sat, Oct 07, 2023 at 11:13:49AM +, Chancel Liu wrote: > Instead of "fsl,lpa-widgets", I would like to add a common property > "ignore-suspend-widgets" in sound-card-common.yaml file. So not only rpmsg > sound cards but also other sound cards which have such feature can use this > property to define wanted widgets ignoring suspend. > What do you think about that? We can perhaps bikeshed the name a bit to be more focused on the use case but yes, that sounds reasonable. signature.asc Description: PGP signature
Re: [PATCH v2 1/5] ASoC: Explicitly include correct DT includes
On Wed, Oct 04, 2023 at 10:58:05AM -0500, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it was merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. This is breaking various builds for me, for example arm64 defconfig: /build/stage/linux/sound/soc/rockchip/rockchip_i2s_tdm.c: In function ‘rockchip_i2s_tdm_probe’: /build/stage/linux/sound/soc/rockchip/rockchip_i2s_tdm.c:1557:17: error: implicit declaration of function ‘of_match_device’; did you mean ‘of_match_node’? [-Werror=implicit-function-declaration] 1557 | of_id = of_match_device(rockchip_i2s_tdm_match, >dev); | ^~~ | of_match_node /build/stage/linux/sound/soc/rockchip/rockchip_i2s_tdm.c:1557:15: warning: assignment to ‘const struct of_device_id *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 1557 | of_id = of_match_device(rockchip_i2s_tdm_match, >dev); | ^ /build/stage/linux/sound/soc/tegra/tegra210_amx.c: In function ‘tegra210_amx_platform_probe’: /build/stage/linux/sound/soc/tegra/tegra210_amx.c:541:17: error: implicit declaration of function ‘of_match_device’; did you mean ‘of_match_node’? [-Werror=implicit-function-declaration] 541 | match = of_match_device(tegra210_amx_of_match, dev); | ^~~ | of_match_node /build/stage/linux/sound/soc/tegra/tegra210_amx.c:541:15: warning: assignment to ‘const struct of_device_id *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 541 | match = of_match_device(tegra210_amx_of_match, dev); | ^ cc1: some warnings being treated as errors multi_v7_defconfig is also broken. signature.asc Description: PGP signature
Re: [RFC PATCH v5 00/11] Add audio support in v4l2 framework
On Thu, Sep 28, 2023 at 05:00:08PM +0800, Shengjiu Wang wrote: > Audio signal processing also has the requirement for memory to > memory similar as Video. > This asrc memory to memory (memory ->asrc->memory) case is a non > real time use case. Other than the naming thing I sent in reply to one of the patches the ASoC bits look fine. signature.asc Description: PGP signature
Re: [RFC PATCH v5 01/11] ASoC: fsl_asrc: define functions for memory to memory usage
On Thu, Sep 28, 2023 at 05:00:09PM +0800, Shengjiu Wang wrote: > m2m_start_part_one: first part of the start steps > m2m_start_part_two: second part of the start steps > m2m_stop_part_one: first part of stop steps > m2m_stop_part_two: second part of stop steps, optional The part_one/two naming isn't amazing here. Looking at the rest of the code it looks like this is a prepare/trigger type distinction where the first part is configuring things prior to DMA setup and the second part is actually starting the transfer. Perhaps _config()/_start() instead? signature.asc Description: PGP signature
Re: Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend
On Wed, Sep 27, 2023 at 03:07:49AM +, Chancel Liu wrote: > > This is a fairly standard DSP playback case as far as I can see so it > > should work with DAPM without needing this obviously use case specific > > stuff peering into the Linux implementation. Generally this is done by > > tagging endpoint widgets and DAIs as ignore_suspend, DAPM will then > > figure out the rest of the widgets in the path. > Yes, indeed I meant to let driver get DAPM endpoints from the > "fsl,lpa-widgets" > property and then set these endpoints as ignore_suspend if the sound card is > running in this use case. Do you think the description for the use case can be > simplified since it's a common use case? This is a card problem - the driver for rpmsg shouldn't need to worry about it. Any bindings extensions should be at the card level rather than in a specific driver, we could probably use something in the generic properties that they're all using. signature.asc Description: PGP signature
Re: [PATCH] ASoC: dt-bindings: Add missing (unevaluated|additional)Properties on child node schemas
On Mon, 25 Sep 2023 17:09:28 -0500, Rob Herring wrote: > Just as unevaluatedProperties or additionalProperties are required at > the top level of schemas, they should (and will) also be required for > child node schemas. That ensures only documented properties are > present for any node. > > Add unevaluatedProperties or additionalProperties as appropriate. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: dt-bindings: Add missing (unevaluated|additional)Properties on child node schemas commit: 7b71da59122c3ab82908910abf78db1fd6340cac All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl-asoc-card: use integer type for fll_id and pll_id
On Wed, 20 Sep 2023 17:43:12 +0800, Shengjiu Wang wrote:
> As the pll_id and pll_id can be zero (WM8960_SYSCLK_AUTO)
> with the commit 2bbc2df46e67 ("ASoC: wm8960: Make automatic the
> default clocking mode")
>
> Then the machine driver will skip to call set_sysclk() and set_pll()
> for codec, when the sysclk rate is different with what wm8960 read
> at probe, the output sound frequency is wrong.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl-asoc-card: use integer type for fll_id and pll_id
commit: 2b21207afd06714986a3d22442ed4860ba4f9ced
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
Re: [PATCH] ASoC: fsl_sai: Don't disable bitclock for i.MX8MP
On Tue, 19 Sep 2023 17:42:13 +0800, Shengjiu Wang wrote: > On i.MX8MP, the BCE and TERE bit are binding with mclk > enablement, if BCE and TERE are cleared the MCLK also be > disabled on output pin, that cause the external codec (wm8960) > in wrong state. > > Codec (wm8960) is using the mclk to generate PLL clock, > if mclk is disabled before disabling PLL, the codec (wm8960) > won't generate bclk and frameclk when sysclk switch to > MCLK source in next test case. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_sai: Don't disable bitclock for i.MX8MP commit: 197c53c8ecb34f2cd5922f4bdcffa8f701a134eb All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend
On Mon, Sep 25, 2023 at 07:09:45PM +0800, Chancel Liu wrote: > + fsl,lpa-widgets: > +$ref: /schemas/types.yaml#/definitions/non-unique-string-array > +description: | > + A list of DAPM endpoints which mark paths between these endpoints > should > + not be disabled when system enters in suspend state. LPA means low > power > + audio case. On asymmetric multiprocessor, there are Cortex-A core and > + Cortex-M core, Linux is running on Cortex-A core, RTOS or other OS is > + running on Cortex-M core. The audio hardware devices can be controlled > by > + Cortex-M. LPA can be explained as a mechanism that Cortex-A allocates a > + large buffer and fill audio data, then Cortex-A can enter into suspend > + for the purpose of power saving. Cortex-M continues to play the sound > + during suspend phase of Cortex-A. When the data in buffer is consumed, > + Cortex-M will trigger the Cortex-A to wakeup to fill data. LPA requires > + some audio paths still enabled when Cortex-A enters into suspend. This is a fairly standard DSP playback case as far as I can see so it should work with DAPM without needing this obviously use case specific stuff peering into the Linux implementation. Generally this is done by tagging endpoint widgets and DAIs as ignore_suspend, DAPM will then figure out the rest of the widgets in the path. signature.asc Description: PGP signature
Re: [RFC PATCH v4 09/11] media: uapi: Add V4L2_CID_USER_IMX_ASRC_RATIO_MOD control
On Thu, Sep 21, 2023 at 07:13:14PM +0800, Shengjiu Wang wrote: > Ratio modification on i.MX is to modify the configured ratio. > For example, the input rate is 44.1kHz, output rate is 48kHz, > configured ratio = 441/480, the ratio modification is to modify > the fractional part of (441/480) with small steps. because the > input clock or output clock has drift in the real hardware. > The ratio modification is signed value, it is added to configured > ratio. It does sound like something other vendors are likely to have to provide a mechanism to compensate for clock inaccuracies. signature.asc Description: PGP signature
Re: [PATCH] ASoC: imx-audmix: Fix return error with devm_clk_get()
On Fri, 15 Sep 2023 14:02:11 +0800, Shengjiu Wang wrote: > The devm_clk_get() can return -EPROBE_DEFER error, > modify the error code to be -EINVAL is not correct, which > cause the -EPROBE_DEFER error is not correctly handled. > > This patch is to fix the return error code. > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: imx-audmix: Fix return error with devm_clk_get() commit: b19a5733de255cabba5feecabf6e900638b582d1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2] ASoC: imx-rpmsg: Set ignore_pmdown_time for dai_link
On Wed, 13 Sep 2023 18:26:56 +0800, Chancel Liu wrote: > i.MX rpmsg sound cards work on codec slave mode. MCLK will be disabled > by CPU DAI driver in hw_free(). Some codec requires MCLK present at > power up/down sequence. So need to set ignore_pmdown_time to power down > codec immediately before MCLK is turned off. > > Take WM8962 as an example, if MCLK is disabled before DAPM power down > playback stream, FIFO error will arise in WM8962 which will have bad > impact on playback next. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: imx-rpmsg: Set ignore_pmdown_time for dai_link commit: fac58baf8fcfcd7481e8f6d60206ce2a47c1476c All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v5 24/31] net: wan: Add framer framework support
On Tue, Sep 12, 2023 at 12:14:36PM +0200, Herve Codina wrote: > A framer is a component in charge of an E1/T1 line interface. > Connected usually to a TDM bus, it converts TDM frames to/from E1/T1 > frames. It also provides information related to the E1/T1 line. > > The framer framework provides a set of APIs for the framer drivers > (framer provider) to create/destroy a framer and APIs for the framer > users (framer consumer) to obtain a reference to the framer, and > use the framer. If people are fine with this could we perhaps get it applied on a branch with a tag? That way we could cut down the size of the series a little and I could apply the generic ASoC bit too, neither of the two patches have any dependency on the actual hardware. signature.asc Description: PGP signature
Re: [PATCH v5 28/31] pinctrl: Add support for the Lantic PEF2256 pinmux
On Tue, Sep 12, 2023 at 01:04:56PM +0200, Linus Walleij wrote: > On Tue, Sep 12, 2023 at 12:15 PM Herve Codina > wrote: > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > I think SPDX mandates that you start the tag with C99 comments > // SPDX-License-Identifier: GPL-2.0-only Not for headers, they should use C style since they might be included in contexts where C++ isn't supported. signature.asc Description: PGP signature
Re: [PATCH] ASoC: fsl: imx-pcm-rpmsg: Add SNDRV_PCM_INFO_BATCH flag
On Mon, 11 Sep 2023 14:38:07 +0800, Shengjiu Wang wrote: > The rpmsg pcm device is a device which should support > double buffering. > > Found this issue with pipewire. When there is no > SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will > set headroom to be zero, and because rpmsg pcm device > don't support residue report, when the latency setting > is small, the "delay" always larger than "target" in > alsa-pcm.c, that reading next period data is not > scheduled on time. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl: imx-pcm-rpmsg: Add SNDRV_PCM_INFO_BATCH flag commit: 2f9426905a63be7ccf8cd10109caf1848aa0993a All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: (subset) [PATCH 00/11] add missing of_node_put
On Thu, 07 Sep 2023 11:55:10 +0200, Julia Lawall wrote: > Add of_node_put on a break out of an of_node loop. > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [10/11] ASoC: rsnd: add missing of_node_put commit: 28115b1c4f2bb76e786436bf6597c5eb27638a5c All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Thu, Aug 24, 2023 at 07:03:09PM +0200, Takashi Iwai wrote: > Shengjiu Wang wrote: > > But there are several issues: > > 1. Need to create sound cards. ASRC module support multi instances, then > > need to create multi sound cards for each instance. > Hm, why can't it be multiple PCM instances instead? I'm having a hard time following this one too. > > 2. The ASRC is an entirety but with DPCM we need to separate input port and > > output port to playback substream and capture stream. Synchronous between > > playback substream and capture substream is a problem. > > How to start them and stop them at the same time. > This could be done by enforcing the full duplex and linking the both > PCM streams, I suppose. > > So shall we make the decision that we can go to the V4L2 solution? > Honestly speaking, I don't mind much whether it's implemented in V2L4 > or not -- at least for the kernel part, we can reorganize / refactor > things internally. But, the biggest remaining question to me is > whether this user-space interface is the most suitable one. Is it > well defined, usable and maintained for the audio applications? Or > is it meant to be a stop-gap for a specific use case? I'm having a really hard time summoning much enthusiasm for using v4l here, it feels like this is heading down the same bodge route as DPCM but directly as ABI so even harder to fix properly. That said all the ALSA APIs are really intended to be used in real time and this sounds like a non real time application? I don't fully understand what the actual use case is here. signature.asc Description: PGP signature
Re: [PATCH] spi: fsl-cpm: Properly define and use IO pointers
On Wed, 09 Aug 2023 10:54:27 +0200, Christophe Leroy wrote: > Sparse reports several issues with IO pointers. > > Fix it by adding missing __iomem flags and using iowriteXXbe() > generic helpers instead of the powerpc specific out_beXX() ones. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/1] spi: fsl-cpm: Properly define and use IO pointers commit: ddaec4e44d4e2a556b51159d48788a85ff67179d All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH -next] ASoC: imx-audio-rpmsg: Remove redundant initialization owner in imx_audio_rpmsg_driver
On Tue, 08 Aug 2023 10:17:28 +0800, Li Zetao wrote: > The module_rpmsg_driver() will set "THIS_MODULE" to driver.owner when > register a rpmsg_driver driver, so it is redundant initialization to set > driver.owner in the statement. Remove it for clean code. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: imx-audio-rpmsg: Remove redundant initialization owner in imx_audio_rpmsg_driver commit: 8e5c4a9fc47ab6d8e1d9cf6c1f11c90675c1d968 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2 24/28] pinctrl: Add support for the Lantic PEF2256 pinmux
On Mon, Aug 07, 2023 at 03:05:15PM +0200, Linus Walleij wrote: > On Wed, Jul 26, 2023 at 5:04 PM Herve Codina wrote: > > +#include "linux/bitfield.h" > Really? I don't think there is such a file there. > Do you mean and does this even compile? #include "" means "try the local directory first then fall back to system includes" so it'll work, it picks up extra stuff on top of what <> does. There's a stylistic issue though. signature.asc Description: PGP signature
Re: [PATCH v2 RESEND*3] ASoC: fsl MPC52xx drivers require PPC_BESTCOMM
On Thu, Aug 03, 2023 at 11:09:43AM -0700, Randy Dunlap wrote: > On 8/3/23 04:27, Mark Brown wrote: > > On Wed, Aug 02, 2023 at 07:59:41PM -0700, Randy Dunlap wrote: > >> Both SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA select > >> SND_SOC_MPC5200_AC97. The latter symbol depends on PPC_BESTCOMM, > >> so the 2 former symbols should also depend on PPC_BESTCOMM since > >> "select" does not follow any dependency chains. > > Take a hint, it's not clear that the patch is tasteful. > Thank you for replying. I'll drop it and just report the build errors. To be clear I generally don't give you review comments because in the past I grew so frustrated with having them and their escalations ignored that it seemed better to just not start. If the patch seems fine I generally apply it, usually you just don't resend patches so that works. signature.asc Description: PGP signature
Re: [PATCH v2 RESEND*3] ASoC: fsl MPC52xx drivers require PPC_BESTCOMM
On Wed, Aug 02, 2023 at 07:59:41PM -0700, Randy Dunlap wrote: > Both SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA select > SND_SOC_MPC5200_AC97. The latter symbol depends on PPC_BESTCOMM, > so the 2 former symbols should also depend on PPC_BESTCOMM since > "select" does not follow any dependency chains. Take a hint, it's not clear that the patch is tasteful. signature.asc Description: PGP signature
Re: [PATCH v2 0/3] Update the register list of MICFIL
On Wed, 02 Aug 2023 13:21:14 +0800, Chancel Liu wrote: > MICFIL IP is upgraded on i.MX93 platform. Add new registers and new bit > definition. > > changes in v2: > - rename check_version to use_verid to make it more explicit > - rename fsl_micfil_check_version to fsl_micfil_use_verid > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/3] ASoC: fsl_micfil: Add new registers and new bit definition commit: 51d765f79c8d8016df906afd05410f8bc14167ac [2/3] ASoC: fsl_micfil: Add fsl_micfil_use_verid function commit: 367365051b06e172c91172e3273eea72988ce8f6 [3/3] ASoC: fsl_micfil: Use SET_SYSTEM_SLEEP_PM_OPS to simplify PM commit: a38a4090e2c400c6c49c584cda6f28c73c08f5f1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Wed, Aug 02, 2023 at 10:41:43PM +0800, Shengjiu Wang wrote: > Currently the ASRC in ALSA is to connect to another I2S device as > a sound card. But we'd like to the ASRC can be used by user space directly > that user space application can get the output after conversion from ASRC. That sort of use case would be handled via DPCM at the minute, though persuading it to connect two front ends together might be fun (which is the sort of reason why we want to push digital information down into DAPM and make everything a component). signature.asc Description: PGP signature
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Wed, Aug 02, 2023 at 08:02:29PM +0800, Shengjiu Wang wrote: > On Wed, Aug 2, 2023 at 7:22 PM Takashi Iwai wrote: > > Well, I personally don't mind to have some audio capability in v4l2 > > layer. But, the only uncertain thing for now is whether this is a > > must-have or not. > Thanks, I am also not sure about this. I am also confused that why > there is no m2m implementation for audio in the kernel. Audio also > has similar decoder encoder post-processing as video. This is the thing where we've been trying to persuade people to work on replacing DPCM with full componentisation for about a decade now but nobody's had time other than Morimoto-san who's been chipping away at making everything component based for a good chunk of that time. One trick is that we don't just want this to work for things that are memory to memory, we also want things where there's a direct interconnect that bypasses memory for off-SoC case. > The reason why I select to extend v4l2 for such audio usage is that v4l2 > looks best for this audio m2m implementation. v4l2 is designed for m2m > usage. if we need implement another 'route', I don't think it can do better > that v4l2. > I appreciate that someone can share his ideas or doable solutions. > And please don't ignore my request, ignore my patch. There's a bunch of presentations Lars-Peter did at ELC some considerable time ago about this. signature.asc Description: PGP signature
Re: [PATCH] ASoC: fsl_micfil: refactor deprecated strncpy
On Thu, 27 Jul 2023 22:26:41 +, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > A suitable replacement is `strscpy` [2] due to the fact that it > guarantees NUL-termination on its destination buffer argument which is > _not_ always the case for `strncpy`! > > In this case, though, there was great care taken to ensure that the > destination buffer would be NUL-terminated through the use of `len - 1` > ensuring that the previously zero-initialized buffer would not overwrite > the last NUL byte. This means that there's no bug here. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_micfil: refactor deprecated strncpy commit: 7eb10bfbbae6025cb7b4bba3db0c1281eac05862 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [RFC PATCH v2 4/7] media: v4l2: Add audio capture and output support
On Fri, Jul 28, 2023 at 07:59:33AM +, Tomasz Figa wrote: > On Tue, Jul 25, 2023 at 02:12:17PM +0800, Shengjiu Wang wrote: > > + case VFL_TYPE_AUDIO: > > + name_base = "audio"; > I think it was mentioned before that "audio" could be confusing. Wasn't > there actually some other kind of /dev/audio device long ago? OSS used /dev/audio. signature.asc Description: PGP signature
Re: [PATCH 1/1] ASoC: fsl: fsl_qmc_audio: Fix snd_pcm_format_t values handling
On Wed, 26 Jul 2023 18:16:20 +0200, Herve Codina wrote: > Running sparse on fsl_qmc_audio (make C=1) raises the following warnings: > fsl_qmc_audio.c:387:26: warning: restricted snd_pcm_format_t degrades to > integer > fsl_qmc_audio.c:389:59: warning: incorrect type in argument 1 (different > base types) > fsl_qmc_audio.c:389:59:expected restricted snd_pcm_format_t [usertype] > format > fsl_qmc_audio.c:389:59:got unsigned int [assigned] i > fsl_qmc_audio.c:564:26: warning: restricted snd_pcm_format_t degrades to > integer > fsl_qmc_audio.c:569:50: warning: incorrect type in argument 1 (different > base types) > fsl_qmc_audio.c:569:50:expected restricted snd_pcm_format_t [usertype] > format > fsl_qmc_audio.c:569:50:got int [assigned] i > fsl_qmc_audio.c:573:62: warning: incorrect type in argument 1 (different > base types) > fsl_qmc_audio.c:573:62:expected restricted snd_pcm_format_t [usertype] > format > fsl_qmc_audio.c:573:62:got int [assigned] i > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl: fsl_qmc_audio: Fix snd_pcm_format_t values handling commit: 5befe22b3eebd07b334b2917f6d14ce7ee4c8404 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_spdif: Silence output on stop
On Wed, 19 Jul 2023 18:47:29 +0200, Matus Gajdos wrote: > Clear TX registers on stop to prevent the SPDIF interface from sending > last written word over and over again. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_spdif: Silence output on stop commit: 0e4c2b6b0c4a4b4014d9424c27e5e79d185229c5 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_spdif: Add support for 22.05 kHz sample rate
On Wed, 19 Jul 2023 18:31:53 +0200, Matus Gajdos wrote: > Add support for 22.05 kHz sample rate for TX. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_spdif: Add support for 22.05 kHz sample rate commit: 65bc25b8d0904e0aff66b1c3a9dd4c0dcb8efbf1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_sai: Disable bit clock with transmitter
On Wed, 12 Jul 2023 14:49:33 +0200, Matus Gajdos wrote: > Otherwise bit clock remains running writing invalid data to the DAC. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_sai: Disable bit clock with transmitter commit: 269f399dc19f0e5c51711c3ba3bd06e0ef6ef403 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 0/2] Add support for rpmsg sound card on i.MX93 platform
On Fri, 14 Jul 2023 17:29:11 +0800, Chancel Liu wrote: > Support rpmsg sound card on i.MX93 platform. > > Chancel Liu (2): > ASoC: dt-bindings: fsl_rpmsg: Add compatible string for i.MX93 > ASoC: fsl_rpmsg: Add support for i.MX93 platform > > Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml | 1 + > sound/soc/fsl/fsl_rpmsg.c | 8 > 2 files changed, 9 insertions(+) > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: dt-bindings: fsl_rpmsg: Add compatible string for i.MX93 commit: 143f8c69a27f3fa8ed30c7f6790ea039fff57cfe [2/2] ASoC: fsl_rpmsg: Add support for i.MX93 platform commit: 60f38a592efe08e5ced454e8a05f6814e6e221ec All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Mon, Jul 17, 2023 at 03:55:50PM +, Edgecombe, Rick P wrote: > On Fri, 2023-07-14 at 23:57 +0100, Mark Brown wrote: > > The same issue seems to apply with the version that was in -next > > based > > on v6.4-rc4 too. > The version in your branch is not the same as the version in tip (which > had a squashed build fix). I was able to reproduce the build error with > your branch. But not with the one in tip rebased on v6.5-rc1. So can > you try this version: > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/shstk=899223d69ce9f338056f4c41ef870d70040fc860 Ah, I'd not seen that patch or that tip had been rebased - I'd actually been using literally the branch from tip as my base at whatever point I last noticed it changing up until I rebased onto -rc1. signature.asc Description: PGP signature
Re: [PATCH] ASoC: fsl_sai: Disable bit clock with transmitter
On Mon, Jul 17, 2023 at 09:31:38AM -0300, Fabio Estevam wrote: > On Wed, Jul 12, 2023 at 9:53 AM Matus Gajdos wrote: > > > > Otherwise bit clock remains running writing invalid data to the DAC. > > > > Signed-off-by: Matus Gajdos > > Should this contain a Fixes tag so that it could be backported to > stable kernels? I'll just put a non-specific Cc stable tag on it, that should be enough to get it backported. signature.asc Description: PGP signature
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote:
> The x86 Shadow stack feature includes a new type of memory called shadow
> stack. This shadow stack memory has some unusual properties, which requires
> some core mm changes to function properly.
This seems to break sparc64_defconfig when applied on top of v6.5-rc1:
In file included from /home/broonie/git/bisect/include/linux/mm.h:29,
from /home/broonie/git/bisect/net/core/skbuff.c:40:
/home/broonie/git/bisect/include/linux/pgtable.h: In function 'pmd_mkwrite':
/home/broonie/git/bisect/include/linux/pgtable.h:528:9: error: implicit
declaration of function 'pmd_mkwrite_novma'; did you mean 'pte_mkwrite_novma'?
[-Werror=implicit-function-declaration]
return pmd_mkwrite_novma(pmd);
^
pte_mkwrite_novma
/home/broonie/git/bisect/include/linux/pgtable.h:528:9: error: incompatible
types when returning type 'int' but 'pmd_t' {aka 'struct '} was
expected
return pmd_mkwrite_novma(pmd);
^~
The same issue seems to apply with the version that was in -next based
on v6.4-rc4 too.
signature.asc
Description: PGP signature
Re: [PATCH] ASoC: imx-pcm-rpmsg: Set PCM hardware parameters separately
On Sun, 25 Jun 2023 14:54:12 +0800, Chancel Liu wrote: > Different PCM devices may have different PCM hardware parameters. It > requires PCM hardware parameters set separately if there is more than > one rpmsg sound card. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: imx-pcm-rpmsg: Set PCM hardware parameters separately commit: 82770b76abae2ff9d70f354a61983b921e63bae1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 1/6] media: v4l2: Add audio capture and output support
On Mon, Jul 03, 2023 at 03:12:55PM +0200, Hans Verkuil wrote: > My main concern is that these cross-subsystem drivers are a pain to > maintain. So there have to be good reasons to do this. > Also it is kind of weird to have to use the V4L2 API in userspace to > deal with a specific audio conversion. Quite unexpected. > But in the end, that's a decision I can't make. > So I wait for that feedback. Note that if the decision is made that this > can use V4L2, then there is quite a lot more that needs to be done: > documentation, new compliance tests, etc. It's adding a new API, and that > comes with additional work... Absolutely, I agree with all of this - my impression was that the target here would be bypass of audio streams to/from a v4l2 device, without bouncing through an application layer. If it's purely for audio usage with no other tie to v4l2 then involving v4l2 does just seem like complication. signature.asc Description: PGP signature
Re: [PATCH 1/6] media: v4l2: Add audio capture and output support
On Mon, Jul 03, 2023 at 02:07:10PM +0200, Takashi Iwai wrote: > Shengjiu Wang wrote: > > There is no such memory to memory interface defined in ALSA. Seems > > ALSA is not designed for M2M cases. > There is no restriction to implement memory-to-memory capture in ALSA > framework. It'd be a matter of the setup of PCM capture source, and > you can create a corresponding kcontrol element to switch the mode or > assign a dedicated PCM substream, for example. It's just that there > was little demand for that. Yeah, it's not a terrible idea. We might use it more if we ever get better support for DSP audio, routing between the DSP and external devices if driven from the CPU would be a memory to memory thing. > I'm not much against adding the audio capture feature to V4L2, > though, if it really makes sense. But creating a crafted /dev/audio* > doesn't look like a great idea to me, at least. I've still not looked at the code at all. signature.asc Description: PGP signature
Re: [PATCH 4/6] ASoC: fsl_asrc: Add memory to memory driver
On Fri, Jun 30, 2023 at 11:37:29AM +0800, Shengjiu Wang wrote: > On Thu, Jun 29, 2023 at 7:39 PM Mark Brown wrote: > > On Thu, Jun 29, 2023 at 09:37:51AM +0800, Shengjiu Wang wrote: > > > Implement the ASRC memory to memory function using > > > the v4l2 framework, user can use this function with > > > v4l2 ioctl interface. > > This feels like the bit where we interface v4l to ASoC should be a > > separate library, there shouldn't be anything device specific about > > getting an audio stream into a block of memory. I'm thinking something > > like the way we handle dmaengine here. > > I've not dug into the code yet though. > Users may want to get the ASRC output in the user space, then > do mixing with other streams before sending to ALSA. > As there is no such API in ASoC, the best interface I found is > the V4L2, but I need to do a little modification of the V4L2 API, > extend it for audio usage. > Could you please suggest more about the "separate library"? > Should I place this "sound/soc/fsl/fsl_asrc_m2m.c" in another folder? The concept of connecting an audio stream from v4l directly to something in ASoC isn't specific to this driver or even to the i.MX platform, the code that deals with that part of things should be split out so that it works the same for any other drivers that do this. signature.asc Description: PGP signature
Re: [PATCH 4/6] ASoC: fsl_asrc: Add memory to memory driver
On Thu, Jun 29, 2023 at 09:37:51AM +0800, Shengjiu Wang wrote: > Implement the ASRC memory to memory function using > the v4l2 framework, user can use this function with > v4l2 ioctl interface. > > User send the output and capture buffer to driver and > driver store the converted data to the capture buffer. > > This feature can be shared by ASRC and EASRC drivers > > Signed-off-by: Shengjiu Wang > --- > sound/soc/fsl/Kconfig| 13 + > sound/soc/fsl/Makefile | 2 + > sound/soc/fsl/fsl_asrc_m2m.c | 878 +++ > sound/soc/fsl/fsl_asrc_m2m.h | 48 ++ This feels like the bit where we interface v4l to ASoC should be a separate library, there shouldn't be anything device specific about getting an audio stream into a block of memory. I'm thinking something like the way we handle dmaengine here. I've not dug into the code yet though. signature.asc Description: PGP signature
Re: [PATCH] ASoC: imx-audmix: check return value of devm_kasprintf()
On Wed, 14 Jun 2023 15:15:09 +0300, Claudiu Beznea wrote: > devm_kasprintf() returns a pointer to dynamically allocated memory. > Pointer could be NULL in case allocation fails. Check pointer validity. > Identified with coccinelle (kmerr.cocci script). > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: imx-audmix: check return value of devm_kasprintf() commit: 2f76e1d6ca524a888d29aafe29f2ad2003857971 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_sai: Enable BCI bit if SAI works on synchronous mode with BYP asserted
On Tue, 30 May 2023 18:30:12 +0800, Chancel Liu wrote: > There's an issue on SAI synchronous mode that TX/RX side can't get BCLK > from RX/TX it sync with if BYP bit is asserted. It's a workaround to > fix it that enable SION of IOMUX pad control and assert BCI. > > For example if TX sync with RX which means both TX and RX are using clk > form RX and BYP=1. TX can get BCLK only if the following two conditions > are valid: > 1. SION of RX BCLK IOMUX pad is set to 1 > 2. BCI of TX is set to 1 > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_sai: Enable BCI bit if SAI works on synchronous mode with BYP asserted commit: 32cf0046a652116d6a216d575f3049a9ff9dd80d All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2 0/2] ASoC: do not include runtime_pm.h if not needed
On Wed, 17 May 2023 12:49:01 +0300, Claudiu Beznea wrote: > Series removes the pm_runtime.h inclusion in files where > APIs exported though pm_runtime.h are not used. In case > of files that make use of pm.h which comes form pm_runtime.h > added patch 2/2. > > Changes were built with allmodconfig on ARM and x86_64 and checked > all the changed files were built at least once. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: do not include pm_runtime.h if not used commit: 2f3092e77f98fcfc0d653846591401bfe2a5232e [2/2] ASoC: use pm.h instead of runtime_pm.h commit: a9392efae9f5de42673cfc1b81ac6fb88bdb26b2 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_sai: MCLK bind with TX/RX enable bit
On Fri, 05 May 2023 15:55:22 +0800, Shengjiu Wang wrote: > On i.MX8MP, the sai MCLK is bound with TX/RX enable bit, > which means the TX/RE enable bit need to be enabled then > MCLK can be output on PAD. > > Some codec (for example: WM8962) needs the MCLK output > earlier, otherwise there will be issue for codec > configuration. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_sai: MCLK bind with TX/RX enable bit commit: 3e4a826129980fed0e3e746a7822f2f204dfc24a All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_micfil: Fix error handler with pm_runtime_enable
On Mon, 08 May 2023 18:16:36 +0800, Shengjiu Wang wrote: > There is error message when defer probe happens: > > fsl-micfil-dai 30ca.micfil: Unbalanced pm_runtime_enable! > > Fix the error handler with pm_runtime_enable and add > fsl_micfil_remove() for pm_runtime_disable. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_micfil: Fix error handler with pm_runtime_enable commit: 17955aba7877a4494d8093ae5498e19469b01d57 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] Revert "ASoC: fsl: remove unnecessary dai_link->platform"
On Wed, 19 Apr 2023 18:29:18 +0800, Shengjiu Wang wrote: > This reverts commit 33683cbf49b5412061cb1e4c876063fdef86def4. > > dai_link->platform is needed. The platform component is > "snd_dmaengine_pcm", which is registered from cpu driver, > > If dai_link->platform is not assigned, then platform > component will not be probed, then there will be issue: > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] Revert "ASoC: fsl: remove unnecessary dai_link->platform" commit: 09cda705860125ffee1b1359b1da79f8e0c77a40 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl: Simplify an error message
On Sun, 16 Apr 2023 08:29:34 +0200, Christophe JAILLET wrote: > dev_err_probe() already display the error code. There is no need to > duplicate it explicitly in the error message. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl: Simplify an error message commit: 574399f4c997ad71fab95dd875a9ff55424f9a3d All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_asrc_dma: fix potential null-ptr-deref
On Mon, 17 Apr 2023 06:32:42 -0700, Nikita Zhandarovich wrote: > dma_request_slave_channel() may return NULL which will lead to > NULL pointer dereference error in 'tmp_chan->private'. > > Correct this behaviour by, first, switching from deprecated function > dma_request_slave_channel() to dma_request_chan(). Secondly, enable > sanity check for the resuling value of dma_request_chan(). > Also, fix description that follows the enacted changes and that > concerns the use of dma_request_slave_channel(). > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_asrc_dma: fix potential null-ptr-deref commit: 86a24e99c97234f87d9f70b528a691150e145197 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_sai: Fix pins setting for i.MX8QM platform
On Tue, 18 Apr 2023 17:42:59 +0800, Chancel Liu wrote: > SAI on i.MX8QM platform supports the data lines up to 4. So the pins > setting should be corrected to 4. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_sai: Fix pins setting for i.MX8QM platform commit: 238787157d83969e5149c8e99787d5d90e85fbe5 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] Revert "ASoC: fsl: remove unnecessary dai_link->platform"
On Wed, Apr 19, 2023 at 06:29:18PM +0800, Shengjiu Wang wrote: > This reverts commit 33683cbf49b5412061cb1e4c876063fdef86def4. Please include human readable descriptions of things like commits and issues being discussed in e-mail in your mails, this makes them much easier for humans to read especially when they have no internet access. I do frequently catch up on my mail on flights or while otherwise travelling so this is even more pressing for me than just being about making things a bit easier to read. Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone. signature.asc Description: PGP signature
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Tue, Apr 18, 2023 at 11:21:45AM -0700, Nathan Chancellor wrote: > On Fri, Apr 14, 2023 at 05:55:10PM +0100, Mark Brown wrote: > > Done. > Thanks a lot, sorry for not saying it sooner! It looks like this > regressed in next-20230417 and next-20230418 though. Someone sent a mail saying they thought they'd fixed the DRM tree - is that not the case? signature.asc Description: PGP signature
Re: [PATCH 1/2] ASoC: fsl_mqs: move of_node_put() to the correct location
On Mon, 03 Apr 2023 23:26:47 +0800, Liliang Ye wrote: > of_node_put() should have been done directly after > mqs_priv->regmap = syscon_node_to_regmap(gpr_np); > otherwise it creates a reference leak on the success path. > > To fix this, of_node_put() is moved to the correct location, and change > all the gotos to direct returns. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: fsl_mqs: move of_node_put() to the correct location commit: 1c34890273a020d61d6127ade3f68ed1cb21c16a All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 2/2] ASoC: fsl_mqs: call pm_runtime_disable() on error path
On Mon, Apr 03, 2023 at 11:27:37PM +0800, Liliang Ye wrote: > pm_runtime_disable was missed in cleanup operation, which corresponds to > the earlier call to pm_runtime_enable. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature
