linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
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,
	s.hauer@pengutronix.de, timur@tabi.org, rob.herring@calxeda.com,
	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: Sat, 17 Aug 2013 14:56:11 +0200	[thread overview]
Message-ID: <2362958.X2QCBUPAyI@flatron> (raw)
In-Reply-To: <20130816044330.GD1846@MrMyself>

Hi Nicolin,

On Friday 16 of August 2013 12:43:31 Nicolin Chen wrote:
> Hi Tomasz,
> 
>    Thank you for the comments.

You're welcome.

>    I'll revise them in v6.
>    And below is my reply for you comments.

Thanks for your reply.

> On Thu, Aug 15, 2013 at 02:18:22PM +0200, Tomasz Figa wrote:
> > > +  - clock-names : Includes the following entries:
> > > +	name		type		comments
> > > +	"core"		Required	The core clock of spdif controller
> > > +
> > > +	"rx"		Optional	Rx clock source for spdif record.
> > > +					If absent, will use core clock.
> > > +
> > > +	"tx"		Optional	Tx clock source for spdif 
playback.
> > > +					If absent, will use core clock.
> > > +
> > > +	"tx-32000"	Optional	Tx clock source for 32000Hz sample 
rate
> > > +					playback. If absent, will use tx 
clock.
> > > +
> > > +	"tx-44100"	Optional	Tx clock source for 44100Hz sample 
rate
> > > +					playback. If absent, will use tx 
clock.
> > > +
> > > +	"tx-48000"	Optional	Tx clock source for 48000Hz sample 
rate
> > > +					playback. If absent, will use tx 
clock.
> > > +
> > > +	"src<0-7>"	Optional	Clock source list for tx and rx 
clock
> > > +					to look up their clock source 
indexes.
> > > +					This clock list should be 
identical to
> > > +					the list of TxClk_Source bit value 
of
> > > +					register SPDIF_STC. If absent or 
failed
> > > +					to look up, tx and rx clock would 
then
> > > +					ignore the "rx", "tx" "tx-32000",
> > > +					"tx-44100", "tx-48000" clock 
phandles
> > > +					and select the core clock as 
default
> > > +					tx and rx clock.
> > 
> > I suspect a little abuse of clocks property here. From the description
> > of "core" and "src<0-7>" clocks I assume that the IP can have up to 9
> > clock inputs - core clock and up to 8 extra source clocks. Is it
> > correct?
> > 
> > If yes, this makes the "tx", "rx" and "tx-*" clocks describe
> > configuration, not hardware. IMHO it should be up to the driver which
> > source clocks to use for tx and rx channels and for each sampling
> > rate.
> 
> First, you are right that all the properties you just commented are
> software configurations. And I got the point that device tree now
> can't allow any software configuration even if the actual hardware
> connection will depend on it.
> 
> If so, I would like to remove those abused clocks and also drop the
> unused clocks in src<0-7>, then just remain those needed clocks src.
> I think that can be plausible because there'll be no more clock abuse
> and the driver will be able to get the source index from the name
> 'src<num>'.

OK.

> And you are right about the 9 clock inputs, just there're not only 9
> inputs but also an extra external clock from S/PDIF transmitter via
> coaxial cable or optical fiber -- RxCLK. Please check the following
> list:
> 
> 0000 if (DPLL Locked) SPDIF_RxClk else extal
> 0001 if (DPLL Locked) SPDIF_RxClk else spdif_clk
> 0010 if (DPLL Locked) SPDIF_RxClk else asrc_clk
> 0011 if (DPLL Locked) SPDIF_RxClk else spdif_extclk
> 0100 if (DPLL Locked) SPDIF_Rxclk else esai_hckt
> 0101 extal_clk
> 0110 spdif_clk
> 0111 asrc_clk
> 1000 spdif_extclk
> 1001 esai_hckt
> 1010 if (DPLL Locked) SPDIF_RxClk else mlb_clk
> 1011 if (DPLL Locked) SPDIF_RxClk else mlb_phy_clk
> 1100 mkb_clk
> 1101 mlb_phy_clk

Could you explain what the above values are? If they are values written to 
a 4-bit mux that selects RX clock source, then all the 16 clocks should be 
specified from device tree, even if they are duplicated.

Are the clock names you used above names of clock inputs of the S/PDIF 
block or names of SoC-wide clocks?

Can the assignment of clock inputs change? For example on one SoC

0000 if (DPLL Locked) SPDIF_RxClk else extal_clk
0001 if (DPLL Locked) SPDIF_RxClk else spdif_clk
...
0101 extal_clk
0110 spdif_clk
...

and on another

0000 if (DPLL Locked) SPDIF_RxClk else spdif_clk
0001 if (DPLL Locked) SPDIF_RxClk else extal_clk
...
0101 extal_clk
0110 spdif_clk
...

(notice the swapped 0000 and 0001 inputs)

Same goes for the TX mux. If it is a 3-bit, 8-input mux, then it should be 
described in device tree separately, as it is different than the 4-bit, 
16-input RX mux.

> When (DPLL Locked) condition matches, the rx clock can ignore the 8
> input clocks from clock mux then use the external one from a S/PDIF
> transmitter.

What happens if the "DPLL locked" condition doesn't match? When this can 
happen?

> So for the below part:
> > > +Optional properties:
> > > +
> > > +  - rx-clksrc-lock: This is a boolean property. If present,
> > > ClkSrc_Sel
> > > bit +  of SPDIF_SRPC would be set a clock source that cares DPLL
> > > locked
> > > condition. +
> > 
> > This again looks like software configuration, not hardware
> > description.
> > Could you elaborate a bit more on meaning of this property?
> 
> I think the rx-clksrc-lock property should be included in DT as well,
> since it's exactly a available clock source for rx. But I guess I just
> need to figure out a better way or a more elaborated description.

I still don't understand the meaning of this property. Could you explain 
it please?

Best regards,
Tomasz

  parent reply	other threads:[~2013-08-17 12: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
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 [this message]
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=2362958.X2QCBUPAyI@flatron \
    --to=tomasz.figa@gmail.com \
    --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=s.hauer@pengutronix.de \
    --cc=shawn.guo@linaro.org \
    --cc=swarren@wwwdotorg.org \
    --cc=timur@tabi.org \
    /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).