From: Nicolin Chen <nicoleotsuka@gmail.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: alsa-devel@alsa-project.org,
Takashi Sakamoto <o-takashi@sakamocchi.jp>,
Timur Tabi <timur@tabi.org>, Xiubo Li <Xiubo.Lee@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Takashi Iwai <tiwai@suse.com>, Mark Brown <broonie@kernel.org>,
Fabio Estevam <fabio.estevam@nxp.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v4 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture
Date: Thu, 30 Nov 2017 17:29:35 -0800 [thread overview]
Message-ID: <20171201012934.GA32588@Asurada-Nvidia> (raw)
In-Reply-To: <aaedc37a-1536-462f-515e-19c6cb711e4f@maciej.szmigiero.name>
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
WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicoleotsuka@gmail.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: Timur Tabi <timur@tabi.org>, Xiubo Li <Xiubo.Lee@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Fabio Estevam <fabio.estevam@nxp.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
alsa-devel@alsa-project.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel <linux-kernel@vger.kernel.org>,
Takashi Sakamoto <o-takashi@sakamocchi.jp>
Subject: Re: [PATCH v4 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture
Date: Thu, 30 Nov 2017 17:29:35 -0800 [thread overview]
Message-ID: <20171201012934.GA32588@Asurada-Nvidia> (raw)
In-Reply-To: <aaedc37a-1536-462f-515e-19c6cb711e4f@maciej.szmigiero.name>
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
next prev parent reply other threads:[~2017-12-01 1:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-27 22:34 [PATCH v4 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture Maciej S. Szmigiero
2017-11-30 7:23 ` Nicolin Chen
2017-11-30 7:23 ` Nicolin Chen
2017-11-30 19:20 ` Maciej S. Szmigiero
2017-11-30 19:20 ` Maciej S. Szmigiero
2017-11-30 23:53 ` Nicolin Chen
2017-12-01 1:02 ` Maciej S. Szmigiero
2017-12-01 1:02 ` Maciej S. Szmigiero
2017-12-01 1:29 ` Nicolin Chen [this message]
2017-12-01 1:29 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171201012934.GA32588@Asurada-Nvidia \
--to=nicoleotsuka@gmail.com \
--cc=Xiubo.Lee@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mail@maciej.szmigiero.name \
--cc=o-takashi@sakamocchi.jp \
--cc=timur@tabi.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.