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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8B17C001DF for ; Wed, 2 Aug 2023 11:23:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234174AbjHBLXK (ORCPT ); Wed, 2 Aug 2023 07:23:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234215AbjHBLW5 (ORCPT ); Wed, 2 Aug 2023 07:22:57 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C288D13D; Wed, 2 Aug 2023 04:22:53 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7B37D21ABA; Wed, 2 Aug 2023 11:22:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1690975372; 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=5r1CpNIAJIEW3BpMhgShJ14F48fAU7qslpZkFUD+rwk=; b=CBvW/AhkgcCD5eWfqToZIUCdl0qQ9bihx77+ptxjqXd3s8JAEJ3P3EuwPcIDBTeV8zaMa8 +8NG+elmSNZo8llvlBvULzXRfhcW6+jBK+7ljSl2IB11xf9OeH4jNleJiRbJwySEA2G1y7 hzMitlzqKdGewuKCHsm3hzmmZsdaKmQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1690975372; 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=5r1CpNIAJIEW3BpMhgShJ14F48fAU7qslpZkFUD+rwk=; b=hpeZK5XRODX9CLvc13p+tye6dirc1m+7cnLpsMl3lmifUvBm1kbRmBamK3d6M0mwM5L5+b 2591pHTdBsSr4NAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4E82013909; Wed, 2 Aug 2023 11:22:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id SCeaEow8ymSAJQAAMHmgww (envelope-from ); Wed, 02 Aug 2023 11:22:52 +0000 Date: Wed, 02 Aug 2023 13:22:51 +0200 Message-ID: <87il9xu1ro.wl-tiwai@suse.de> From: Takashi Iwai To: Hans Verkuil Cc: Shengjiu Wang , sakari.ailus@iki.fi, tfiga@chromium.org, m.szyprowski@samsung.com, mchehab@kernel.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, shengjiu.wang@gmail.com, Xiubo.Lee@gmail.com, festevam@gmail.com, nicoleotsuka@gmail.com, lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz, tiwai@suse.com, alsa-devel@alsa-project.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework In-Reply-To: <47d66c28-1eb2-07f5-d6f9-779d675aefe8@xs4all.nl> References: <1690265540-25999-1-git-send-email-shengjiu.wang@nxp.com> <47d66c28-1eb2-07f5-d6f9-779d675aefe8@xs4all.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 02 Aug 2023 09:32:37 +0200, Hans Verkuil wrote: > > Hi all, > > On 25/07/2023 08:12, Shengjiu Wang wrote: > > Audio signal processing has the requirement for memory to > > memory similar as Video. > > > > This patch is to add this support in v4l2 framework, defined > > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and > > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format > > for audio case usage. > > > > The created audio device is named "/dev/audioX". > > > > And add memory to memory support for two kinds of i.MX ASRC > > module > > Before I spend time on this: are the audio maintainers OK with doing > this in V4L2? > > I do want to have a clear statement on this as it is not something I > can decide. Well, I personally don't mind to have some audio capability in v4l2 layer. But, the only uncertain thing for now is whether this is a must-have or not. IIRC, the implementation in the sound driver side was never done just because there was no similar implementation? If so, and if the extension to the v4l2 core layer is needed, shouldn't it be more considered for the possible other route? thanks, Takashi