Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp16450pxb; Tue, 2 Mar 2021 17:30:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJw/MGLD3QTTadVy4KJqkkNF5seVo6PSbcA1tR28z0gENMj483jbT7E6nOh2I9nziV1yRFwa X-Received: by 2002:a05:6402:100b:: with SMTP id c11mr22725042edu.193.1614735059684; Tue, 02 Mar 2021 17:30:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614735059; cv=none; d=google.com; s=arc-20160816; b=CfCayjvzI8oj5Ipb1hi5ouQgHCfY4Pr3A7ydwdcioNKMROeRMtvq6alplPo7kz0Fjc HB/Py8k0HmbwUA1BRloeoSSDlKJpINMrrB9CZ7CoGcSnpDXMM0WmuraR7ghRiSlVWno4 de3D8HnPrIat5h3H+d3blJaZrtJXxETXfGTS31//OsoMhIl69qrWcmr+jdPLwWsSoryb RnXV3XEPdebensMp8FIWqXTf+840rIBbY4N0Ee1BipKPFtH2FZ1Ztxrz7/gXeZGjM9nG k+p5fNp21rRNEl3k3+g6FM43E+BN/gSma0nFopzhiq6E1TSHr8qA8loXEgGGTAK9/9d1 nTrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:date:message-id:from:references:cc:to :subject:dkim-signature; bh=uSJJetc2M6a7lgzm6cOltJ6NC/DZ0gqUW8HqU2UcHXk=; b=LCzzupZDG4sMfxKBh95lfphrLaELk9sbVV0xG6AXdfG97Qj20VnvlW7BOXS2UjJhrH 5G89UlzTtJdxQZXycad/9fw6yIN/YXtbQwROiN8fqOvt1fwftS04z5ALmYBowEJYwLJA z17ii1XiTb6ZhcvOVlPvUf1DzIiEQ73EHgXgZ5aprniPsf1YP2sUvyJUYC0Fi3pcUYU1 3r1CMj27kti3AClvVt179kz/qEP+vKT9IpGd6TTkh47Pum/sIzAMM1u1+yJr1I50N/Kd 0KVFQoWBFQbB/GHOH7gQi3JfRJ1HoDUrJODtPItjNp6V8AUhRMECK0IosrpK12SPLeW4 5rPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@opensynergy.com header.s=srmailgate02 header.b=JH4+SP78; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=opensynergy.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id kl13si13893999ejc.507.2021.03.02.17.30.36; Tue, 02 Mar 2021 17:30:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@opensynergy.com header.s=srmailgate02 header.b=JH4+SP78; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=opensynergy.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233865AbhCAJZx (ORCPT + 99 others); Mon, 1 Mar 2021 04:25:53 -0500 Received: from mx1.opensynergy.com ([217.66.60.4]:13985 "EHLO mx1.opensynergy.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233844AbhCAJZw (ORCPT ); Mon, 1 Mar 2021 04:25:52 -0500 Received: from SR-MAILGATE-02.opensynergy.com (localhost.localdomain [127.0.0.1]) by mx1.opensynergy.com (Proxmox) with ESMTP id 850CBA133F; Mon, 1 Mar 2021 10:25:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opensynergy.com; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=srmailgate02; bh=uSJJetc2M6a7 lgzm6cOltJ6NC/DZ0gqUW8HqU2UcHXk=; b=JH4+SP78tCJ3pTYlZ48ml+43Yh5P Rs0dcRFPb0F2BNEVQcAzW3IeyRInsp5PuWcHCvQH1/O2NZYGUgUhEUI6WTPSch/m b96yDk1+SB7TRKMU1qteXiL2IPCNfBitX5qqcoI5gxNRC4lpYr+g3Y7Dj96XF0uL VCUILdn51VOVbEsKtwTMzuRyotgnol/QzLT/mCqdizO0UftD+kvin7MVPaH2EvPt oc0m4XMstF6S/NRCzfj3WTI8gWojjdWxIa3Q9P/lS6I9QqzXSbPmNVS32qrrSiad yvCT0miMljfuHH6ImaNxkqSncbKedSWYWZr0zhNuBJ72Pa/un5Nxs4O7Cw== Subject: Re: [PATCH v6 5/9] ALSA: virtio: handling control and I/O messages for the PCM device To: Takashi Iwai CC: , , , "Michael S. Tsirkin" , Jaroslav Kysela , Takashi Iwai , References: <20210227085956.1700687-1-anton.yakovlev@opensynergy.com> <20210227085956.1700687-6-anton.yakovlev@opensynergy.com> From: Anton Yakovlev Message-ID: Date: Mon, 1 Mar 2021 10:25:05 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SR-MAIL-01.open-synergy.com (10.26.10.21) To SR-MAIL-01.open-synergy.com (10.26.10.21) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28.02.2021 12:27, Takashi Iwai wrote: > 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... Well, no. Here, events are kind of independent entities. PCM-related events are just a special case of more generic events, which can carry any kind of notification/payload. (And at the moment, only XRUN notification is supported for PCM substreams.) So it has nothing to do with the atomicity of the PCM device itself. >> +/** >> + * 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. Yeah, we can take a look into some kind of optimizations here. But I suspect, the overall code will look similar. It is not enough just to get a list of pages, you also need to build a list of physically contiguous regions from it. Because the sg-elements are put into a virtqueue that has a limited size. And each sg-element consumes one item in the virtqueue. And since the virtqueue itself is shared between all substreams, the items of the virtqueue become a scarce resource. > (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? That's one of options. Since the same info can be derived from sg-list, I thought it might be not necessary to keep it in some additional field. But probably it makes sense to keep total length in the message structure itself. Then it will be more flexible (if we will need to create non-period sized messages in the future). > > thanks, > > Takashi > -- Anton Yakovlev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin