All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keyon Jie <yang.jie@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	"Rajwa, Marcin" <marcin.rajwa@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue
Date: Fri, 17 Jan 2020 18:13:31 +0800	[thread overview]
Message-ID: <d6cee7a3-bbd4-0706-fcc2-96b403f6c58e@linux.intel.com> (raw)
In-Reply-To: <s5h1rrypla9.wl-tiwai@suse.de>



On 2020/1/17 下午3:57, Takashi Iwai wrote:
> On Fri, 17 Jan 2020 06:30:18 +0100,
> Keyon Jie wrote:
>>
>> On 2020/1/17 上午4:37, Takashi Iwai wrote:
>>
>> Hi Takashi, I get your concern here, but if we switch to use dma_max
>> limit, we won't change the preallocated buffer, it will be still 64KB
>> for each stream, user space can ask for re-allocate buffer for each
>> stream up to 32MB, but those pinned and can't be swapped out ones are
>> the 64KB preallocated ones only, am I wrong?
> 
> No, in general, all sound hardware buffers are pinned.

Sorry, I must have been wrong here, what I was focusing on is those 
allocated SG DMA buffers, I am not sure if they are those you called 
"hardware buffers" here.

My understanding was like this:

1. in pcm_new() stage, the device PCM driver should call 
snd_pcm_lib_preallocate_pages()->
	snd_pcm_lib_preallocate_pages()->
		preallocate_pcm_pages()
and then the substream->dma_buffer is initialized with the preallocated 
buffer.

2. in pcm_open() stage, the device PCM driver should call
snd_pcm_lib_malloc_pages()->
	snd_dma_alloc_pages() //if we need to reallocate bigger buffer. *The 
substream->dma_buffer won't be freed, Takashi, this is what I thought 
you named "pinned" buffer.* And those reallocated bigger buffer via 
snd_dma_alloc_pages() will be freed at pcm_close() per my understanding?

Thanks,
~Keyon

> 
> 
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2020-01-17 10:05 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  4:53 [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue Keyon Jie
2020-01-16  7:15 ` Takashi Iwai
2020-01-16  9:50   ` Keyon Jie
2020-01-16 10:27     ` Takashi Iwai
2020-01-16 11:25       ` Keyon Jie
2020-01-16 11:50         ` Takashi Iwai
2020-01-16 14:14           ` Jie, Yang
2020-01-16 15:31             ` Jie, Yang
2020-01-16 16:07               ` Takashi Iwai
2020-01-16 16:39               ` Pierre-Louis Bossart
2020-01-16 17:25                 ` Rajwa, Marcin
2020-01-16 17:40                   ` Pierre-Louis Bossart
2020-01-16 20:37                     ` Takashi Iwai
2020-01-17  5:30                       ` Keyon Jie
2020-01-17  7:57                         ` Takashi Iwai
2020-01-17 10:13                           ` Keyon Jie [this message]
2020-01-17 10:30                             ` Takashi Iwai
2020-01-17 10:56                               ` Keyon Jie
2020-01-17 11:15                                 ` Takashi Iwai
2020-01-17  5:37                     ` Keyon Jie
2020-01-17  8:00                       ` Takashi Iwai
2020-01-17 10:43                         ` Keyon Jie
2020-01-17 11:12                           ` Takashi Iwai
2020-01-19  3:52                             ` Keyon Jie
2020-01-19  7:09                               ` Takashi Iwai
2020-01-19  8:11                                 ` Keyon Jie
2020-01-19  9:04                                   ` Takashi Iwai
2020-01-19 10:14                                     ` Keyon Jie
2020-01-19 10:43                                       ` Takashi Iwai
2020-01-20  2:23                                         ` Keyon Jie
2020-01-16 15:45             ` Takashi Iwai

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=d6cee7a3-bbd4-0706-fcc2-96b403f6c58e@linux.intel.com \
    --to=yang.jie@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=marcin.rajwa@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.