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 DBD2CC41535 for ; Tue, 19 Dec 2023 12:28:07 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 88ABCE72; Tue, 19 Dec 2023 13:27:55 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 88ABCE72 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1702988885; bh=AR/FTncpP3HZDm6f9IH+uJbJm+jxlPJQsQuijcUY4ak=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=ll1tuZNtVYiG2tYU0jYcVH9dbM2Kife5m4qV3lSkHL5USj5wH6ln45BIODuW2wA6i qTVEnj5XN7Qh5Hc/TqnftPePSsel0kzlfZ4FhjnxSuL3gxI8H4xCjzV56ybZKRE1mS XSlEK/jQ1xD83jrvSYs3+SXuLhDBFLZMkSzG5dEA= Received: by alsa1.perex.cz (Postfix, from userid 50401) id B6E16F80588; Tue, 19 Dec 2023 13:27:34 +0100 (CET) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 92D98F80589; Tue, 19 Dec 2023 13:27:33 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 223F2F80431; Tue, 19 Dec 2023 13:27:25 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id E8097F80124 for ; Tue, 19 Dec 2023 13:27:17 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz E8097F80124 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=O8beV8by DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1702988839; x=1734524839; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=AR/FTncpP3HZDm6f9IH+uJbJm+jxlPJQsQuijcUY4ak=; b=O8beV8byr5bfJyNqHa41L6wKU3yT3hRypZ6a6+MiSykCA/in1chqXnPi FmYbT45nTACT/bRFOLQtQg/Lga9wH6xsEDRVRHk94+HL0+h1vi8J4KnJp sm5SjZrouxiyP/tUjeOEdSJKm33B6UKLJCZbcq0H/a0lCbKihkpc5Qogn UIrHAIZn1/xUUxE3ulh3T/ZwNxIRpZGTcGwL9vfH3qPw5HmcjFVdiSmUj qtbCE4Hnrfs0C5fyWFuNwq+kRb9SeZPxJM1iO7FHsHuZvql4jBmmZj+bt Sbr2tI1fxuZ4Izn8UwP4yTx4Wlzx78S4dnHjqqpe5FsZw7fzoT7qkkzi6 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10928"; a="14338230" X-IronPort-AV: E=Sophos;i="6.04,288,1695711600"; d="scan'208";a="14338230" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Dec 2023 04:27:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10928"; a="1107335078" X-IronPort-AV: E=Sophos;i="6.04,288,1695711600"; d="scan'208";a="1107335078" Received: from hierlema-mobl.ger.corp.intel.com (HELO [10.252.34.230]) ([10.252.34.230]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Dec 2023 04:27:08 -0800 Message-ID: Date: Mon, 18 Dec 2023 17:33:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 01/16] Documentation: driver: add SoundWire BRA description Content-Language: en-US To: Charles Keepax Cc: Vinod Koul , linux-sound@vger.kernel.org, alsa-devel@alsa-project.org, tiwai@suse.de, broonie@kernel.org, vinod.koul@intel.com, Bard liao , Ranjani Sridharan , Peter Ujfalusi , Kai Vehmanen , srinivas.kandagatla@linaro.org, Krzysztof Kozlowski , vijendar.mukunda@amd.com, Richard Fitzgerald , Shuming Fan , Jack Yu , Oder Chiou References: <20231207222944.663893-1-pierre-louis.bossart@linux.intel.com> <20231207222944.663893-2-pierre-louis.bossart@linux.intel.com> <20231218142946.GZ14858@ediswmail.ad.cirrus.com> From: Pierre-Louis Bossart In-Reply-To: <20231218142946.GZ14858@ediswmail.ad.cirrus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-ID-Hash: WAJ5KUVIZWM4X6MAZ4VMY45RS4QZQ2W2 X-Message-ID-Hash: WAJ5KUVIZWM4X6MAZ4VMY45RS4QZQ2W2 X-MailFrom: pierre-louis.bossart@linux.intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 12/18/23 08:29, Charles Keepax wrote: > On Mon, Dec 18, 2023 at 01:58:47PM +0100, Pierre-Louis Bossart wrote: >>> why not have a single API that does both? First check if it is supported >>> and then allocate buffers and do the transfer.. What are the advantages >>> of using this two step process >> >> Symmetry is the only thing that comes to my mind. Open - close and send >> - wait are natural matches, aren't they? >> >> We do need a wait(), so bundling open() and send() would be odd. >> > > I agree send->wait->close would be odd, But you just bundle close > into wait. So the API becomes just send->wait, which seems pretty > logical. Fair enough, send()/wait() would work indeed. I guess I wanted to keep the callbacks reasonably small (already 200 lines for the open), but we can split the 'send' callback into smaller helpers to keep the code readable. There's no good reason to expose these smaller helpers to codec drivers. >> But you have a point that the open() is not generic in that it also >> prepares the DMA buffers for transmission. Maybe it's more natural to >> follow the traditional open(), hw_params(), hw_free, close() from ALSA. > > I think this just makes it worse, you are now adding even more > calls. The problem I see here is that, open and close (at least to > me) strongly implies that you can do multiple operations between > them and unless I have misunderstood something here you can't. That's right, the open was not compatible with multiple operations. Collapsing open/send and wait/close sounds more logical, thanks for the feedback.