linux-kernel - Re: [PATCH v4 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20171201012934.GA32588@Asurada-Nvidia>
Date:   Thu, 30 Nov 2017 17:29:35 -0800
From:   Nicolin Chen <nicoleotsuka@...il.com>
To:     "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Cc:     Timur Tabi <timur@...i.org>, Xiubo Li <Xiubo.Lee@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Fabio Estevam <fabio.estevam@....com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, alsa-devel@...a-project.org,
        linuxppc-dev@...ts.ozlabs.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Takashi Sakamoto <o-takashi@...amocchi.jp>
Subject: Re: [PATCH v4 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97
 and use it for capture

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