From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B7134C433F5 for ; Thu, 13 Jan 2022 13:46:16 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id CF0DA1F60; Thu, 13 Jan 2022 14:45:24 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz CF0DA1F60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1642081574; bh=8iEUku0WYW9fpW7ruMKGRSin5h1ONqAUo03t32+9YCY=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=UvY7E6qs/tnylhbmnUaob685fRoA9N4daHr/dHoKn702Zc9mtlPeSyDQmg7ai3zjr LPMuY6RnsVuxRE232FkJwTT5mMvwqFefTJYKcDd/D0nqOaIVknRgNAGthFHPp+UFgJ GPNb3+wewUiZClkwPmxIg8/Q8ZFytHE0ookjTN8E= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 6963FF8010B; Thu, 13 Jan 2022 14:45:24 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 4F555F8013F; Thu, 13 Jan 2022 14:45:23 +0100 (CET) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 3A78CF80054 for ; Thu, 13 Jan 2022 14:45:14 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 3A78CF80054 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="xq6y4HWR"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="K0XQDrnS" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id EF9651F3A8; Thu, 13 Jan 2022 13:45:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1642081513; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+FGl7/4XB2Odszl/6hHzcWVompbiJIeoa9i64XwmjkU=; b=xq6y4HWRjlvUNjmsuUPPBCsBuve8wGT1u1wV7A+MPUqrcy6M80MrIxIoC+S0tV8uJl+Ox1 8XQuAMp9YVwWypEmnrO/S2RZHEhFvSn8qzu58qvAFRH0Bqdr9evAvP0GA1uU56gCyVR4+X OYTJXbEYFJTKlNN2bp1DAE68749M9s0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1642081513; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+FGl7/4XB2Odszl/6hHzcWVompbiJIeoa9i64XwmjkU=; b=K0XQDrnSUr4gCjKZVaFytDGQVKMeu3oodYOpzxYV2DmVKb9t17iOYafG1TJHj5QZiMUgeA Uallr0jnFlK2YPDg== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id EA46AA3B81; Thu, 13 Jan 2022 13:45:13 +0000 (UTC) Date: Thu, 13 Jan 2022 14:45:13 +0100 Message-ID: From: Takashi Iwai To: Jaroslav Kysela Subject: Re: [PATCH] ALSA: pcm: accept the OPEN state for snd_pcm_stop() In-Reply-To: <40388d17-0c5e-5d10-2f8a-ba75e2b7b9c7@perex.cz> References: <20220113113130.1961332-1-perex@perex.cz> <40388d17-0c5e-5d10-2f8a-ba75e2b7b9c7@perex.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Pavel Hofman , ALSA development X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Thu, 13 Jan 2022 14:32:21 +0100, Jaroslav Kysela wrote: > > On 13. 01. 22 13:56, Takashi Iwai wrote: > > On Thu, 13 Jan 2022 12:31:30 +0100, > > Jaroslav Kysela wrote: > >> > >> It may be useful to completely invalidate streaming under some > >> circumstances like the USB gadget detach. This case is a bit different > >> than the complete disconnection. The applications should be notified > >> that the PCM streaming is no longer available, but the recovery may be > >> expected. > >> > >> This patch adds support for SNDRV_PCM_STATE_OPEN passed > >> to snd_pcm_stop() function. Only the hw_free ioctl is allowed to free > >> the buffers in this state for a full recovery operation or the PCM file > >> handle must be closed. > >> > >> In the OPEN state, ioctls return EBADFD error (with the added hw_free > >> exception above). The applications which are not aware about this new > >> state transition (and recovery) will fail with an error. This operation > >> is expected. > >> > >> Link: https://lore.kernel.org/alsa-devel/4e17c99b-1d8a-8ebe-972c-9b1299952ff8@ivitera.com/ > >> Cc: Pavel Hofman > >> Signed-off-by: Jaroslav Kysela > > > > I find the idea neat, but I'm afraid that it's a bit confusing from > > the user POV as is. Namely, the state is in OPEN, but you'd have to > > perform hw_free manually at first for moving forward; how can user > > know it? > > Thanks for the feedback. > > The state ioctls are also not blocked, so the PCM state can be checked > when EBADFD is returned for the updated applications. But as noted in > the comment, it's expected that current applications will fail (like > for the disconnect). OK. So this must be for a specific new use case... > The OPEN state can be set only when hw_params fails in the current > code. So the applications can distinguish the hw_params error / > invalidate stream cases. We may also add this info (flag) to the PCM > status structure. > > This extension can be also implemented using a new PCM state, but in > the regard of our discussion a few months ago, it's probably not a > way. Right, that'll become a compatibility headache. > > Maybe PCM core should do hw_free by itself when hw_params is > > called with hw_free_queued. > > Yes, it's a possible optimization, too. I had same idea when I post > the patch. But the mmap is an issue here - applications must do unmap > before hw_params, so I'm not convinced to add this auto-free to > hw_params, because hw_free has the straight semantics (munmap > before). It would be probably clever to keep those steps separated. Hm, right, mmap is messy. > Also ideally, there may be a check in hw_params, if parameters > (buffers) are changed, but the implementation is not so easy. Maybe we > can allow OPEN -> > PREPARE transition for this case, so the applications may just restart > the streaming in the most light way. Hmm. Reading more about those restrictions and requirements, I feel that this might be better implemented in the gadget driver side locally at first. Basically we can handle similarly: add a new local flag, set it at the stream stop, and return an error at prepare until hw_params gets reconfigured. This might be even smaller changes? thanks, Takashi