linux_dsm_epyc7002/include/uapi
Takashi Iwai 42f945970a ALSA: pcm: Add the explicit appl_ptr sync support
Currently x86 platforms use the PCM status/control mmaps for
transferring the PCM status and appl_ptr between kernel and
user-spaces.  The mmap is a most efficient way of communication, but
it has a drawback per its nature, namely, it can't notify the change
explicitly to kernel.

The lack of appl_ptr update notification is a problem on a few
existing drivers, but it's mostly a small issue and negligible.
However, a new type of driver that uses DSP for a deep buffer
management requires the exact position of appl_ptr for calculating the
buffer prefetch size, and the asynchronous appl_ptr update between
kernel and user-spaces becomes a significant problem for it.

How can we enforce user-space to report the appl_ptr update?  The way
is relatively simple.  Just by disabling the PCM control mmap, the
user-space is supposed to fall back to the mode using SYNC_PTR ioctl,
and the kernel gets control over that.  This fallback mode is used in
all non-x86 platforms as default, and also in the 32bit compatible
model on all platforms including x86.  It's been implemented already
over a decade, so we can say it's fairly safe and stably working.

With the help of the knowledge above, this patch introduces a new PCM
info flag SNDRV_PCM_INFO_SYNC_APPLPTR for achieving the appl_ptr sync
from user-space.  When a driver sets this flag at open, the PCM status
/ control mmap is disabled, which effectively switches to SYNC_PTR
mode in user-space side.

In this version, both PCM status and control mmaps are disabled
although only the latter, control mmap, is the target.  It's because
the current alsa-lib implementation supposes that both status and
control mmaps are always coupled, thus it handles a fatal error when
only one of them fails.

Of course, the disablement of the status/control mmaps may bring a
slight performance overhead.  Thus, as of now, this should be used
only for the dedicated devices that deserves.

Note that the disablement of mmap is a sort of workaround.  In the
later patch, we'll introduce the way to identify the protocol version
alsa-lib supports, and keep mmap working while the sync_ptr is
performed together.

Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-23 15:39:47 +02:00
..
asm-generic uapi: export all headers under uapi directories 2017-05-11 00:21:54 +09:00
drm Merge branch 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux into drm-next 2017-05-12 13:58:29 +10:00
linux USB fixes for 4.12-rc2 2017-05-20 08:52:34 -07:00
misc uapi: export all headers under uapi directories 2017-05-11 00:21:54 +09:00
mtd uapi: export all headers under uapi directories 2017-05-11 00:21:54 +09:00
rdma uapi: export all headers under uapi directories 2017-05-11 00:21:54 +09:00
scsi uapi: export all headers under uapi directories 2017-05-11 00:21:54 +09:00
sound ALSA: pcm: Add the explicit appl_ptr sync support 2017-06-23 15:39:47 +02:00
video uapi: export all headers under uapi directories 2017-05-11 00:21:54 +09:00
xen uapi: export all headers under uapi directories 2017-05-11 00:21:54 +09:00