From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolin Chen Subject: Re: [PATCH v4 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture Date: Wed, 29 Nov 2017 23:23:58 -0800 Message-ID: <20171130072357.GA992@Asurada> References: <5dfa7813-385e-d9c7-84e0-12cf1f7d3a5f@maciej.szmigiero.name> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com [209.85.192.179]) by alsa0.perex.cz (Postfix) with ESMTP id 597EB266A74 for ; Thu, 30 Nov 2017 08:24:09 +0100 (CET) Received: by mail-pf0-f179.google.com with SMTP id m26so2747620pfj.11 for ; Wed, 29 Nov 2017 23:24:09 -0800 (PST) Content-Disposition: inline In-Reply-To: <5dfa7813-385e-d9c7-84e0-12cf1f7d3a5f@maciej.szmigiero.name> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: "Maciej S. Szmigiero" Cc: alsa-devel@alsa-project.org, Takashi Sakamoto , Timur Tabi , Xiubo Li , linux-kernel , Liam Girdwood , Takashi Iwai , Mark Brown , Fabio Estevam , linuxppc-dev@lists.ozlabs.org List-Id: alsa-devel@alsa-project.org Hi Maciej, On Mon, Nov 27, 2017 at 11:34:44PM +0100, Maciej S. Szmigiero wrote: > There is no problem in using different bit widths in playback and capture > in AC'97 mode so allow this, too. > @@ -1557,11 +1558,12 @@ static int fsl_ssi_probe(struct platform_device *pdev) > > /* Are the RX and the TX clocks locked? */ > if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) { > - if (!fsl_ssi_is_ac97(ssi_private)) > + if (!fsl_ssi_is_ac97(ssi_private)) { > ssi_private->cpu_dai_drv.symmetric_rates = 1; > + ssi_private->cpu_dai_drv.symmetric_samplebits = 1; > + } > > ssi_private->cpu_dai_drv.symmetric_channels = 1; > - ssi_private->cpu_dai_drv.symmetric_samplebits = 1; > } I was actually wondering how the AC97 works in the synchronous mode while being able to handle different bit widths. Then I found that the drivers does corresponding configurations for synchronous mode only if symmetric_rates is set -- which is unset for AC97 cases. So in fact AC97 case (symmetric_rates unset) is probably being treated as asynchronous mode by the driver -- it'd be better if you confirm this for me. And I am not so sure about the physical pin connections in an AC97 situation, but I started to think that, instead of having a change above, AC97 cases might be supposed to have "fsl,ssi-asynchronous" property in DT since it's working when the driver sets both TX and RX control registers (i.e. asynchronous mode), not like synchronous mode that only sets TX's registers. Thanks Nicolin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3ynTRb2CPmzDrq6 for ; Thu, 30 Nov 2017 18:24:10 +1100 (AEDT) Received: by mail-pf0-x236.google.com with SMTP id u25so2753136pfg.5 for ; Wed, 29 Nov 2017 23:24:10 -0800 (PST) Date: Wed, 29 Nov 2017 23:23:58 -0800 From: Nicolin Chen To: "Maciej S. Szmigiero" Cc: Timur Tabi , Xiubo Li , Jaroslav Kysela , Takashi Iwai , Fabio Estevam , Liam Girdwood , Mark Brown , alsa-devel@alsa-project.org, linuxppc-dev@lists.ozlabs.org, linux-kernel , Takashi Sakamoto Subject: Re: [PATCH v4 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture Message-ID: <20171130072357.GA992@Asurada> References: <5dfa7813-385e-d9c7-84e0-12cf1f7d3a5f@maciej.szmigiero.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <5dfa7813-385e-d9c7-84e0-12cf1f7d3a5f@maciej.szmigiero.name> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Maciej, On Mon, Nov 27, 2017 at 11:34:44PM +0100, Maciej S. Szmigiero wrote: > There is no problem in using different bit widths in playback and capture > in AC'97 mode so allow this, too. > @@ -1557,11 +1558,12 @@ static int fsl_ssi_probe(struct platform_device *pdev) > > /* Are the RX and the TX clocks locked? */ > if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) { > - if (!fsl_ssi_is_ac97(ssi_private)) > + if (!fsl_ssi_is_ac97(ssi_private)) { > ssi_private->cpu_dai_drv.symmetric_rates = 1; > + ssi_private->cpu_dai_drv.symmetric_samplebits = 1; > + } > > ssi_private->cpu_dai_drv.symmetric_channels = 1; > - ssi_private->cpu_dai_drv.symmetric_samplebits = 1; > } I was actually wondering how the AC97 works in the synchronous mode while being able to handle different bit widths. Then I found that the drivers does corresponding configurations for synchronous mode only if symmetric_rates is set -- which is unset for AC97 cases. So in fact AC97 case (symmetric_rates unset) is probably being treated as asynchronous mode by the driver -- it'd be better if you confirm this for me. And I am not so sure about the physical pin connections in an AC97 situation, but I started to think that, instead of having a change above, AC97 cases might be supposed to have "fsl,ssi-asynchronous" property in DT since it's working when the driver sets both TX and RX control registers (i.e. asynchronous mode), not like synchronous mode that only sets TX's registers. Thanks Nicolin