From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751885AbdLAB3k (ORCPT ); Thu, 30 Nov 2017 20:29:40 -0500 Received: from mail-pf0-f176.google.com ([209.85.192.176]:46823 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750735AbdLAB3j (ORCPT ); Thu, 30 Nov 2017 20:29:39 -0500 X-Google-Smtp-Source: AGs4zMaT9Mo2SuoL8y5pQnH8azPrRUaYbvKLQgWJ4Rcpyi/quQTcxcctm5B/jj+DTAUpD/5Ydyfjvg== Date: Thu, 30 Nov 2017 17:29:35 -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: <20171201012934.GA32588@Asurada-Nvidia> References: <5dfa7813-385e-d9c7-84e0-12cf1f7d3a5f@maciej.szmigiero.name> <20171130072357.GA992@Asurada> <20171130235335.GA26530@Asurada-Nvidia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 01, 2017 at 02:02:29AM +0100, Maciej S. Szmigiero wrote: > > I will clean up the driver a bit and I think the change would be > > highly related to AC97 code. So I'll later need you review/test. > From my perspective it would be great if the whole cleanup was in one > series, so the whole testing doesn't need to be repeated per patch > (it involves a lot of manual work). Understood. > >> Regarding a sample rate in AC'97 mode its effective value isn't really > >> controlled by the CPU (that is, SSI), but by a CODEC since it is > >> the CODEC which tells the CPU when it should send a next sample for > >> playback and when a next capture sample is ready. > >> There are no problems if they are different (as long as the CODEC > >> supports this, naturally, but it's up to its driver to restrict the > >> sample rate space accordingly). > > > > It's because CODEC drives the bit clock and framesync clock, isn't > > it? > > Strictly speaking, the frame sync is driven by the controller (SSI), > but it is simply the CODEC-provided bit clock divided by 256. > And the CODEC-provided bit clock is fixed at 12.288MHz by the AC'97 > specs. > > But every frame from CODEC also has 'TAG' bits which tell the > controller whether this frame contains valid capture samples or not. > If the capture sample rate currently programmed in CODEC is less > than 48kHz (the frame rate) it simply means that some of incoming > frames will contain 'TAG' bits indicating that these frames do not > contain valid capture samples (for example, if the capture rate is > 24kHz then only half of the frames, on average, will be marked by CODEC > as containing valid capture samples). > > The situation with playback is similar: the frame from CODEC also has > 'SLOTREQ' bits which tell the controller if it should send playback > samples (and which) in the next frame - for example, if the playback > rate is 24kHz then in half of the frames, on average, the CODEC will > request playback samples. > > Hope it is clear now. Thanks for the explain. It's clear now. Nicolin