From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>,
Cezary Rojewski <cezary.rojewski@intel.com>
Cc: alsa-devel@alsa-project.org,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Bard Liao <yung-chuan.liao@linux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>,
Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Subject: Re: Buffers used in ASoC Intel Atom SST driver
Date: Thu, 18 Aug 2022 18:11:31 +0200 [thread overview]
Message-ID: <13ee0a40-2353-ef64-9bea-544a5dedac34@linux.intel.com> (raw)
In-Reply-To: <87zgg17d4s.wl-tiwai@suse.de>
On 8/18/22 18:03, Takashi Iwai wrote:
> On Thu, 18 Aug 2022 17:59:36 +0200,
> Cezary Rojewski wrote:
>>
>> On 2022-08-18 5:42 PM, Takashi Iwai wrote:
>>> Hi,
>>>
>>> while cleaning up / fixing the memory allocation code, I noticed that
>>> Intel SST driver is the only driver that currently uses the
>>> SNDRV_DMA_TYPE_CONTINUOUS pages for its PCM buffer.
>>>
>>> Is there any reason not to use the standard device buffer
>>> (SNDRV_DMA_TYPE_DEV)? i.e. the change like below.
>>
>>
>> Hello,
>>
>> Does not hurt to check the change out. I'm not aware of such
>> limitation for any of Intel's AudioDSP solutions. I cannot test this
>> change though as ATOM devices are not part of my CI. Pierre, do you
>> have any devices where this change could be tested?
>>
>> Adding Hans as he is the key intel/atom maintainer too and I'm pretty
>> sure he has few devices on his own.
>
> Oh yeah, thanks, Hans might be able to check.
> FWIW, the patch I asked is like below.
It's a 2011 contribution, commit d927fdae5cb2ca, probably from the
Medfield days. I doubt anyone in the Intel CC: list has context on this,
I was the only one on the Intel payroll at the time.
I vaguely remember than in early versions the PCM data was copied over
to the DSP SRAM with the .ack callback, it wasn't a straightforward DMA
transfer, and that created all kinds of issues for PulseAudio integration.
This was changed at some point IIRC, I don't see any reason why a
bog-standard DMA buffer wouldn't work with the released firmware for
Baytrail which is two generations newer and does use the DesignWare DMA.
The best would be to try, I can't volunteer since I don't have any
hardware available at the moment.
>
>
> Takashi
>
> -- 8< --
>
> From: Takashi Iwai <tiwai@suse.de>
> Subject: [PATCH] ASoC: Intel: sst: Switch to standard device pages
>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> sound/soc/intel/atom/sst-mfld-platform-pcm.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> index a56dd48c045f..c75616a5fd0a 100644
> --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> @@ -676,10 +676,9 @@ static int sst_soc_pcm_new(struct snd_soc_component *component,
>
> if (dai->driver->playback.channels_min ||
> dai->driver->capture.channels_min) {
> - snd_pcm_set_managed_buffer_all(pcm,
> - SNDRV_DMA_TYPE_CONTINUOUS,
> - snd_dma_continuous_data(GFP_DMA),
> - SST_MIN_BUFFER, SST_MAX_BUFFER);
> + snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV,
> + pcm->card->dev,
> + SST_MIN_BUFFER, SST_MAX_BUFFER);
> }
> return 0;
> }
next prev parent reply other threads:[~2022-08-18 16:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 15:42 Buffers used in ASoC Intel Atom SST driver Takashi Iwai
2022-08-18 15:59 ` Cezary Rojewski
2022-08-18 16:03 ` Takashi Iwai
2022-08-18 16:11 ` Pierre-Louis Bossart [this message]
2022-08-23 11:56 ` Takashi Iwai
2022-09-11 18:08 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13ee0a40-2353-ef64-9bea-544a5dedac34@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=cezary.rojewski@intel.com \
--cc=hdegoede@redhat.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=peter.ujfalusi@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=tiwai@suse.de \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox