linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Nicolin Chen <b42378@freescale.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	alsa-devel@alsa-project.org, lars@metafoo.de,
	ian.campbell@citrix.com, pawel.moll@arm.com,
	swarren@wwwdotorg.org, festevam@gmail.com,
	Tomasz Figa <tomasz.figa@gmail.com>,
	rob.herring@calxeda.com, timur@tabi.org, broonie@kernel.org,
	p.zabel@pengutronix.de, galak@codeaurora.org,
	shawn.guo@linaro.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Date: Fri, 16 Aug 2013 10:56:32 +0200	[thread overview]
Message-ID: <20130816085632.GO26614@pengutronix.de> (raw)
In-Reply-To: <20130816080124.GE1846@MrMyself>

On Fri, Aug 16, 2013 at 04:01:25PM +0800, Nicolin Chen wrote:
> Hi Sascha,
> 
>    Thank you for the detailed comments.
> 
> On Fri, Aug 16, 2013 at 09:08:18AM +0200, Sascha Hauer wrote:
> > Which of them the driver should use is configuration and thus normally
> > should *not* be described in the devicetree. However, there may be no
> > good way for the driver to know which clock to use in which case. There
> > may be additional board requirements which are unknown to the driver. So
> > in this case it might be valid to put the information which clock to use
> > into the devicetree. But be aware that from the moment you put this
> > information into the devicetree the driver is no longer free to chose
> > the best clock, even if in future we find a good way to automatically
> > guess the best clock. Do you have some insights in which case I would
> > use which input clock? Is this only about which clock has the best
> > suitable input frequency or is this also about synchronization of the
> > audio signal with some other unit?
> 
> I understand. What I'm thinking now is to let the driver find the best
> clock source for tx clock and a correspond divisor like this:
> 
> "tx<0-8>"	Optional	Tx clock source for spdif playback.
> 				If absent, will use core clock.
> 				The index from 0 to 8 is identical
> 				to the clock source list described
> 				in TxClk_Source bit of register STC.
> 				Multiple clock source are allowed
> 				for this tx clock source. The driver
> 				will select one source from them for
> 				each supported sample rate according
> 				to the clock rates of these provided
> 				clock sources.

You mean tx<0-7>.

Also I would make this option required. Use a dummy clock for mux inputs
that are grounded for a specific SoC.

> 
> Please review this idea.
> 
> 
> And likewise for rx:
> 
> "rx<0-16>"	Optional	Rx clock source for spdif record.
> 				If absent, will use core clock.
> 				The index from 0 to 16 is identical
> 				to the clock source list described
> 				in ClkSrc_Sel bit of register SRPC.
> 				If the index provided contains an
> 				"if (DPLL Locked)" condition in its
> 				source, the correspond clock phandle
> 				should be the one in "else" path.
> 				Only one rx clock source should be
> 				defined here.

Again, describe the input clocks *to* *the* *S/PDIF* *core* in the
devicetree. Nothing more, nothing less. We've already been at the point
where we realized that half of the above clocks only describe the
'PDLL locked' condition. Also the tx clocks are from what I see identical
to the rx clocks. The following are the clocks:

clock-names: "core", "rxtx<0-7>" Required. The S/PDIF core has a core
clock and 8 clocks which are muxed internally to provide input/output
sample clocks.

This is all binding that is needed for now.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2013-08-16  8:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-15 11:26 [PATCH v5 0/2] Add freescale S/PDIF CPU DAI and machine drivers Nicolin Chen
2013-08-15 11:26 ` [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver Nicolin Chen
2013-08-15 12:18   ` Tomasz Figa
2013-08-16  4:43     ` Nicolin Chen
2013-08-16  7:08       ` Sascha Hauer
2013-08-16  8:01         ` Nicolin Chen
2013-08-16  8:56           ` Sascha Hauer [this message]
2013-08-16  9:53             ` Nicolin Chen
2013-08-16 10:11               ` Sascha Hauer
2013-08-16 10:16                 ` Nicolin Chen
2013-08-17 12:28                 ` Tomasz Figa
2013-08-17 14:53                   ` Sascha Hauer
2013-08-17 15:17                     ` Tomasz Figa
2013-08-19  9:35                       ` Mark Rutland
2013-08-20  0:06                         ` Mike Turquette
2013-08-21  8:50                           ` Mark Rutland
2013-08-21 21:34                             ` Tomasz Figa
2013-08-22  7:19                               ` Mike Turquette
2013-08-22 12:09                                 ` Mark Rutland
2013-08-22 21:00                                   ` Sascha Hauer
2013-08-22 22:43                                     ` Mike Turquette
2013-08-22 22:49                                       ` Tomasz Figa
2013-08-23  6:34                                         ` Sascha Hauer
2013-08-23 12:58                                           ` Mark Rutland
2013-08-23 14:01                                             ` [alsa-devel] " Sascha Hauer
2013-08-23 14:57                                               ` Mark Rutland
2013-08-23 21:41                                               ` Mike Turquette
2013-08-24  0:20                                                 ` Mark Brown
2013-08-23 12:44                                     ` Mark Rutland
2013-08-17 12:26             ` Tomasz Figa
2013-08-17 15:00               ` Sascha Hauer
2013-08-17 15:13                 ` Tomasz Figa
2013-08-17 15:14                   ` Sascha Hauer
2013-08-17 12:56       ` Tomasz Figa
2013-08-17 15:14         ` Sascha Hauer
2013-08-17 15:38           ` Tomasz Figa
2013-08-15 11:26 ` [PATCH v5 2/2] ASoC: fsl: Add S/PDIF machine driver 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=20130816085632.GO26614@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=b42378@freescale.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=ian.campbell@citrix.com \
    --cc=lars@metafoo.de \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mark.rutland@arm.com \
    --cc=p.zabel@pengutronix.de \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=shawn.guo@linaro.org \
    --cc=swarren@wwwdotorg.org \
    --cc=timur@tabi.org \
    --cc=tomasz.figa@gmail.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).