linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Anton Yakovlev <anton.yakovlev@opensynergy.com>
Cc: <virtualization@lists.linux-foundation.org>,
	<alsa-devel@alsa-project.org>, <virtio-dev@lists.oasis-open.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 5/9] ALSA: virtio: handling control and I/O messages for the PCM device
Date: Sun, 28 Feb 2021 12:27:55 +0100	[thread overview]
Message-ID: <s5hsg5gjutg.wl-tiwai@suse.de> (raw)
In-Reply-To: <20210227085956.1700687-6-anton.yakovlev@opensynergy.com>

On Sat, 27 Feb 2021 09:59:52 +0100,
Anton Yakovlev wrote:
> +/**
> + * virtsnd_pcm_event() - Handle the PCM device event notification.
> + * @snd: VirtIO sound device.
> + * @event: VirtIO sound event.
> + *
> + * Context: Interrupt context.

OK, then nonatomic PCM flag is invalid...

> +/**
> + * virtsnd_pcm_sg_num() - Count the number of sg-elements required to represent
> + *                        vmalloc'ed buffer.
> + * @data: Pointer to vmalloc'ed buffer.
> + * @length: Buffer size.
> + *
> + * Context: Any context.
> + * Return: Number of physically contiguous parts in the @data.
> + */
> +static int virtsnd_pcm_sg_num(u8 *data, unsigned int length)
> +{
> +	phys_addr_t sg_address;
> +	unsigned int sg_length;
> +	int num = 0;
> +
> +	while (length) {
> +		struct page *pg = vmalloc_to_page(data);
> +		phys_addr_t pg_address = page_to_phys(pg);
> +		size_t pg_length;
> +
> +		pg_length = PAGE_SIZE - offset_in_page(data);
> +		if (pg_length > length)
> +			pg_length = length;
> +
> +		if (!num || sg_address + sg_length != pg_address) {
> +			sg_address = pg_address;
> +			sg_length = pg_length;
> +			num++;
> +		} else {
> +			sg_length += pg_length;
> +		}
> +
> +		data += pg_length;
> +		length -= pg_length;
> +	}
> +
> +	return num;
> +}
> +
> +/**
> + * virtsnd_pcm_sg_from() - Build sg-list from vmalloc'ed buffer.
> + * @sgs: Preallocated sg-list to populate.
> + * @nsgs: The maximum number of elements in the @sgs.
> + * @data: Pointer to vmalloc'ed buffer.
> + * @length: Buffer size.
> + *
> + * Splits the buffer into physically contiguous parts and makes an sg-list of
> + * such parts.
> + *
> + * Context: Any context.
> + */
> +static void virtsnd_pcm_sg_from(struct scatterlist *sgs, int nsgs, u8 *data,
> +				unsigned int length)
> +{
> +	int idx = -1;
> +
> +	while (length) {
> +		struct page *pg = vmalloc_to_page(data);
> +		size_t pg_length;
> +
> +		pg_length = PAGE_SIZE - offset_in_page(data);
> +		if (pg_length > length)
> +			pg_length = length;
> +
> +		if (idx == -1 ||
> +		    sg_phys(&sgs[idx]) + sgs[idx].length != page_to_phys(pg)) {
> +			if (idx + 1 == nsgs)
> +				break;
> +			sg_set_page(&sgs[++idx], pg, pg_length,
> +				    offset_in_page(data));
> +		} else {
> +			sgs[idx].length += pg_length;
> +		}
> +
> +		data += pg_length;
> +		length -= pg_length;
> +	}
> +
> +	sg_mark_end(&sgs[idx]);
> +}

Hmm, I thought there can be already a handy helper to convert vmalloc
to sglist, but apparently not.  It should have been trivial to get the
page list from vmalloc, e.g.

int vmalloc_to_page_list(void *p, struct page **page_ret)
{
	struct vmap_area *va;

	va = find_vmap_area((unsigned long)p);
	if (!va)
		return 0;
	*page_ret = va->vm->pages;
	return va->vm->nr_pages;
}

Then you can set up the sg list in a single call from the given page
list.

But it's just a cleanup, and let's mark it as a room for
improvements.

(snip)
> +/**
> + * virtsnd_pcm_msg_complete() - Complete an I/O message.
> + * @msg: I/O message.
> + * @written_bytes: Number of bytes written to the message.
> + *
> + * Completion of the message means the elapsed period. If transmission is
> + * allowed, then each completed message is immediately placed back at the end
> + * of the queue.
> + *
> + * For the playback substream, @written_bytes is equal to sizeof(msg->status).
> + *
> + * For the capture substream, @written_bytes is equal to sizeof(msg->status)
> + * plus the number of captured bytes.
> + *
> + * Context: Interrupt context. Takes and releases the VirtIO substream spinlock.
> + */
> +static void virtsnd_pcm_msg_complete(struct virtio_pcm_msg *msg,
> +				     size_t written_bytes)
> +{
> +	struct virtio_pcm_substream *vss = msg->substream;
> +
> +	/*
> +	 * hw_ptr always indicates the buffer position of the first I/O message
> +	 * in the virtqueue. Therefore, on each completion of an I/O message,
> +	 * the hw_ptr value is unconditionally advanced.
> +	 */
> +	spin_lock(&vss->lock);
> +	/*
> +	 * If the capture substream returned an incorrect status, then just
> +	 * increase the hw_ptr by the message size.
> +	 */
> +	if (vss->direction == SNDRV_PCM_STREAM_PLAYBACK ||
> +	    written_bytes <= sizeof(msg->status)) {
> +		struct scatterlist *sg;
> +
> +		for (sg = &msg->sgs[PCM_MSG_SG_DATA]; sg; sg = sg_next(sg))
> +			vss->hw_ptr += sg->length;

So the sg list entries are supposed to be updated?  Or if the length
there are constant, we don't need to iterate the sg entries but keep
the total length beforehand?


thanks,

Takashi

  reply	other threads:[~2021-02-28 11:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210227085956.1700687-1-anton.yakovlev@opensynergy.com>
2021-02-27  8:59 ` [PATCH v6 1/9] uapi: virtio_ids: add a sound device type ID from OASIS spec Anton Yakovlev
2021-02-27  8:59 ` [PATCH v6 2/9] ALSA: virtio: add virtio sound driver Anton Yakovlev
2021-02-27  8:59 ` [PATCH v6 3/9] ALSA: virtio: handling control messages Anton Yakovlev
2021-02-28 11:04   ` Takashi Iwai
2021-02-28 18:39     ` Anton Yakovlev
2021-02-27  8:59 ` [PATCH v6 4/9] ALSA: virtio: build PCM devices and substream hardware descriptors Anton Yakovlev
2021-02-28 11:15   ` Takashi Iwai
2021-02-27  8:59 ` [PATCH v6 5/9] ALSA: virtio: handling control and I/O messages for the PCM device Anton Yakovlev
2021-02-28 11:27   ` Takashi Iwai [this message]
2021-03-01  9:25     ` Anton Yakovlev
2021-03-01 13:32       ` Takashi Iwai
2021-03-01 14:47         ` Anton Yakovlev
2021-03-01 14:56           ` Takashi Iwai
2021-03-01 15:24             ` Anton Yakovlev
2021-03-01 15:30               ` Takashi Iwai
2021-02-27  8:59 ` [PATCH v6 6/9] ALSA: virtio: PCM substream operators Anton Yakovlev
2021-02-28 11:32   ` Takashi Iwai
2021-03-01  9:29     ` Anton Yakovlev
2021-03-01 13:33       ` Takashi Iwai
2021-02-27  8:59 ` [PATCH v6 7/9] ALSA: virtio: introduce jack support Anton Yakovlev
2021-02-27  8:59 ` [PATCH v6 8/9] ALSA: virtio: introduce PCM channel map support Anton Yakovlev
2021-02-27  8:59 ` [PATCH v6 9/9] ALSA: virtio: introduce device suspend/resume support Anton Yakovlev
2021-02-28 12:05   ` Takashi Iwai
2021-03-01 10:03     ` Anton Yakovlev
2021-03-01 13:38       ` Takashi Iwai
2021-03-01 15:30         ` Anton Yakovlev
2021-03-02  6:29     ` Anton Yakovlev
2021-03-02  6:48       ` Takashi Iwai
2021-03-02  8:09         ` Anton Yakovlev
2021-03-02  9:11           ` Takashi Iwai
2021-03-02 15:35             ` Anton Yakovlev

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=s5hsg5gjutg.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=anton.yakovlev@opensynergy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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;
as well as URLs for NNTP newsgroup(s).