linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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 15:53:36 -0800	[thread overview]
Message-ID: <20171130235335.GA26530@Asurada-Nvidia> (raw)
In-Reply-To: <ba46e597-6ae7-5fb4-40b3-bb2a5e08066a@maciej.szmigiero.name>

On Thu, Nov 30, 2017 at 08:20:08PM +0100, Maciej S. Szmigiero wrote:

> In the AC'97 mode we have to differentiate two things:
> 1) Bit width of the physical AC'97 interface ("AC-link"),
> 2) Bit width of samples that are accepted during a playback and output
> during a recording by the SSI (and, so by the sound card that it driven
> by this CPU).
> 
> Bit width of the physical AC'97 interface is fixed at 20 bits per sample
> (both in playback and capture direction).
> 
> Bit width of samples that are accepted (or produced) by the SSI could
> be set in its STCCR and SRCCR registers (although in the AC'97 mode
> only settings of either 16 or 20 bits are possible).
> Each direction could be set independently from the other one.

I checked the reference manual regarding the AC97 configurations.
It seems that AC97 sets SYNC bit in SCR register. However, unlike
I2S which only uses STCCR for both TX and RX, AC97 does use STCCR
and SRCCR separately. So bypassing SRCCR if SYNC bit is set isn't
correct for AC97 cases.

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.

> 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? Could SSI act as the clock master side? It doesn't seem to be
configurable to do so according to the reference manual though.

> A comment above "fsl,ssi-asynchronous" property says that it is about
> whether "the RX and the TX clocks [are] locked".
> They are on the physical AC'97 interface, but they aren't on the logical
> playback / capture interface.
> IMHO, this configurable property simply makes no sense in the AC'97
> mode.

The property is more on the hardware level. And we should refer to
the DT binding doc:
    fsl,ssi-asynchronous:
         If specified, the SSI is to be programmed in asynchronous
         mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
         all be connected to valid signals.  In synchronous mode,
         SRCK and SRFS are ignored.  Asynchronous mode allows
         playback and capture to use different sample sizes and
         sample rates.  Some drivers may require that SRCK and STCK
         be connected together, and SRFS and STFS be connected
         together.  This would still allow different sample sizes,
         but not different sample rates.

If AC97 doesn't need SRFS and SRCK at all, it's fine to ignore it.

Thanks
Nic

  reply	other threads:[~2017-11-30 23:53 UTC|newest]

Thread overview: 6+ 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 19:20   ` Maciej S. Szmigiero
2017-11-30 23:53     ` Nicolin Chen [this message]
2017-12-01  1:02       ` Maciej S. Szmigiero
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=20171130235335.GA26530@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=perex@perex.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).