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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D69F3C3402F for ; Mon, 17 Feb 2020 23:23:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B6731207FD for ; Mon, 17 Feb 2020 23:23:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726212AbgBQXXa (ORCPT ); Mon, 17 Feb 2020 18:23:30 -0500 Received: from muru.com ([72.249.23.125]:55768 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726107AbgBQXXa (ORCPT ); Mon, 17 Feb 2020 18:23:30 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 7CBE68087; Mon, 17 Feb 2020 23:24:12 +0000 (UTC) Date: Mon, 17 Feb 2020 15:23:25 -0800 From: Tony Lindgren To: Peter Ujfalusi Cc: Mark Brown , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, "Arthur D ." , Merlijn Wajer , Pavel Machek , Sebastian Reichel , Jarkko Nikula Subject: Re: [PATCH] ASoC: cpcap: Implement set_tdm_slot for voice call support Message-ID: <20200217232325.GD35972@atomide.com> References: <20200211181005.54008-1-tony@atomide.com> <20200212144620.GJ64767@atomide.com> <9a060430-5a3e-61e1-3d2c-f89819d9436f@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9a060430-5a3e-61e1-3d2c-f89819d9436f@ti.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Ujfalusi [200214 13:30]: > Hi Tony, > > On 12/02/2020 16.46, Tony Lindgren wrote: > > * Peter Ujfalusi [200212 09:18]: > >> On 11/02/2020 20.10, Tony Lindgren wrote: > >>> +static int cpcap_voice_set_tdm_slot(struct snd_soc_dai *dai, > >>> + unsigned int tx_mask, unsigned int rx_mask, > >>> + int slots, int slot_width) > >>> +{ > >>> + struct snd_soc_component *component = dai->component; > >>> + struct cpcap_audio *cpcap = snd_soc_component_get_drvdata(component); > >>> + int err, ts_mask, mask; > >>> + bool voice_call; > >>> + > >>> + /* > >>> + * Primitive test for voice call, probably needs more checks > >>> + * later on for 16-bit calls detected, Bluetooth headset etc. > >>> + */ > >>> + if (tx_mask == 0 && rx_mask == 1 && slot_width == 8) > >>> + voice_call = true; > >>> + else > >>> + voice_call = false; > >> > >> You only have voice call if only rx slot0 is in use? > > > > Yeah so it seems. Then there's the modem to wlcore bluetooth path that > > I have not looked at. But presumably that's again just configuring some > > tdm slot on the PMIC. > > > >> If you record mono on the voice DAI, then rx_mask is also 1, no? > > > > It is above :) But maybe I don't follow what you're asking here > > If you arecrod -Dvoice_pcm -c1 -fS8 > /dev/null > then it is reasonable that the machine driver will set rx_mask = 1 > > > and maybe you have some better check in mind. > > Not sure, but relying on set_tdm_slots to decide if we are in a call > case does not sound right. OK yeah seems at least bluetooth would need to be also handled in the set_tdm_slots. > >> You will also set the sampling rate for voice in > >> cpcap_voice_hw_params(), but that is for normal playback/capture, right? > > > > Yeah so normal playback/capture is already working with cpcap codec driver > > with mainline Linux. The voice call needs to set rate to 8000. > > But if you have a voice call initiated should not the rate be set by the > set_sysclk()? Hmm does set_sysclk called from modem codec know that cpcap codec is the clock master based on bitclock-master and set the rate for cpcap codec? > >> It feels like that these should be done via DAPM with codec to codec route? > > > > Sure if you have some better way of doing it :) Do you have an example to > > point me to? > > Something along the lines of: > https://mailman.alsa-project.org/pipermail/alsa-devel/2020-February/162915.html > > The it is a matter of building and connecting the DAPM routes between > the two codec and with a flip of the switch you would have audio flowing > between them. Sounds good to me. Tony