Hi, This patchset is a revised version for a part of my previous RFC: [alsa-lib][RFC][PATCH 0/9] pcm: handle status/control mapping independently http://mailman.alsa-project.org/pipermail/alsa-devel/2017-June/122130.html As I described, we found an advantage to handle results of page mapping for status/control data separately in a discussion about ALSA PCM protocol v2.0.14. In this version, when kernel-land drivers support SNDRV_PCM_INFO_SYNC_APPLPTR for a certain design of hardware, userspace applications are expected to issue current position of applptr for several merits. This should be performed even if applications are programmed to run with mmap operation for PCM buffer. In the above discussion, the way to take applications to perform it is one of important issues. On platforms without enough cache coherency support such as ARM, this doesn't matter. On the platforms, ALSA PCM core already disallows any of mappings for the status/control data of runtime of PCM substream. For this case, userland stuffs were already programmed to go to fallback mode, in which ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR is used to issue/query the status/control data. Even if handling PCM frames on PCM buffer by mmap operation, the position of applptr is issues into ALSA PCM core by a call of ioctl(2) with the command. As a solution for old stuffs in userland, the above mechanism is used for cache coherent architecture such as x86. A patch was already merged into kernel land[1]. This patch changes behaviours of ALSA PCM core to disallow userland to map the status/control data according to drivers' support for SNDRV_PCM_INFO_SYNC_APPLPTR. However, disallowing mappings for both of status/control data has a slight overhead to increase calls of ioctl(2), than usual operation on x86. As I reported[2]. Furthermore, it's clear that current proposals make no sense for drivers because 'struct snd_pcm_ops.ack' in driver implementation is not called expectedly due to a commit[4]. Even if the applptr is issued by ioctl(2), the callback is skipped as long as mapped status includes the updated value for the applptr. In the above discussion, some solutions were suggested[5]. One of them is to enable map of the status data and disable map of the control data. This idea can archive both of the aim of v2.0.14 protocol and reduction of calls for status data, for newer userland stuffs. This patchset for alsa-lib is a preparation for the idea. In current implementation of this library, results of mapping operation for status/control data are not handled separately. This patchset is a similar to code refactoring, thus this includes no essential behaviour changes against released kernel lands. [1] ALSA: pcm: Add the explicit appl_ptr sync support https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=42f945970af9df6216e3d771b4df371d02d8742c [2] ALSA: pcm: add 'applptr' event of tracepoint https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=for-next&id=fccf53881e9b564321326f62ed5f85130fa6e569 [3] [PATCH 0/3] ALSA: Add the explicit appl_ptr sync support http://mailman.alsa-project.org/pipermail/alsa-devel/2017-June/122092.html [4] ALSA: pcm: Skip ack callback without actual appl_ptr update https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=for-next&id=f8ff2f28ba49fa41a06215ac3187dede347bc9a7 [5] [PATCH 0/3] ALSA: Add the explicit appl_ptr sync support http://mailman.alsa-project.org/pipermail/alsa-devel/2017-June/122093.html Takashi Sakamoto (6): pcm: hw: add helper functions to map/unmap status/control data for runtime of PCM substream pcm: hw: add an arrangement for initialization of appl_ptr/avail_min pcm: hw: deallocate fallback buffer when trials of unmapping finished pcm: hw: allocate fallback buffer in advance of trials of mapping pcm: hw: maintain fallback mode for status data mapping pcm: hw: maintain fallback mode for control data mapping independently src/pcm/pcm_hw.c | 192 +++++++++++++++++++++++++++++++++---------------------- 1 file changed, 115 insertions(+), 77 deletions(-) -- 2.11.0 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
