This series fixes two patches:
1. Fix the dmaengine API usage by calling dmaengine_synchronize() after
dmaengine_terminate_async() when xrun events occur in application
2. Use the McASP AFIFO property from DT to refine the period size,
instead of hardcoding minimum to 64 samples
Signed-off-by: Jai Luthra <[email protected]>
---
Changes in v3:
- Use sync_stop() hook instead of a prepare() hook for the DMA channel
synchronization
- Link to v2: https://lore.kernel.org/r/[email protected]
Changes in v2:
- Fix compiler warning for prepare callback by marking it static
- Pass numevt directly to hw_rule_min_periodsize()
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Jai Luthra (2):
ALSA: dmaengine: Synchronize dma channel after drop()
ASoC: ti: davinci-mcasp: Set min period size using FIFO config
include/sound/dmaengine_pcm.h | 1 +
sound/core/pcm_dmaengine.c | 10 ++++++++++
sound/soc/soc-generic-dmaengine-pcm.c | 8 ++++++++
sound/soc/ti/davinci-mcasp.c | 9 +++++++--
4 files changed, 26 insertions(+), 2 deletions(-)
---
base-commit: a957267fa7e9159d3d2ee1421359ebf228570c68
change-id: 20240604-asoc_next-c063fcc190c6
Best regards,
--
Jai Luthra <[email protected]>
The minimum period size was enforced to 64 as older devices integrating
McASP with EDMA used an internal FIFO of 64 samples.
With UDMA based platforms this internal McASP FIFO is optional, as the
DMA engine internally does some buffering which is already accounted for
when registering the platform. So we should read the actual FIFO
configuration (txnumevt/rxnumevt) instead of hardcoding frames.min to
64.
Acked-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Jai Luthra <[email protected]>
---
sound/soc/ti/davinci-mcasp.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c
index 1e760c315521..2b1ed91a736c 100644
--- a/sound/soc/ti/davinci-mcasp.c
+++ b/sound/soc/ti/davinci-mcasp.c
@@ -1472,10 +1472,11 @@ static int davinci_mcasp_hw_rule_min_periodsize(
{
struct snd_interval *period_size = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_PERIOD_SIZE);
+ u8 numevt = *((u8 *)rule->private);
struct snd_interval frames;
snd_interval_any(&frames);
- frames.min = 64;
+ frames.min = numevt;
frames.integer = 1;
return snd_interval_refine(period_size, &frames);
@@ -1490,6 +1491,7 @@ static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
u32 max_channels = 0;
int i, dir, ret;
int tdm_slots = mcasp->tdm_slots;
+ u8 *numevt;
/* Do not allow more then one stream per direction */
if (mcasp->substreams[substream->stream])
@@ -1589,9 +1591,12 @@ static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
return ret;
}
+ numevt = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) ?
+ &mcasp->txnumevt :
+ &mcasp->rxnumevt;
snd_pcm_hw_rule_add(substream->runtime, 0,
SNDRV_PCM_HW_PARAM_PERIOD_SIZE,
- davinci_mcasp_hw_rule_min_periodsize, NULL,
+ davinci_mcasp_hw_rule_min_periodsize, numevt,
SNDRV_PCM_HW_PARAM_PERIOD_SIZE, -1);
return 0;
--
2.43.0
On Tue, 11 Jun 2024 18:02:54 +0530, Jai Luthra wrote:
> This series fixes two patches:
>
> 1. Fix the dmaengine API usage by calling dmaengine_synchronize() after
> dmaengine_terminate_async() when xrun events occur in application
> 2. Use the McASP AFIFO property from DT to refine the period size,
> instead of hardcoding minimum to 64 samples
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ALSA: dmaengine: Synchronize dma channel after drop()
commit: e8343410ddf08fc36a9b9cc7c51a4e53a262d4c6
[2/2] ASoC: ti: davinci-mcasp: Set min period size using FIFO config
commit: c5dcf8ab10606e76c1d8a0ec77f27d84a392e874
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