All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <b42378@freescale.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: broonie@kernel.org, lars@metafoo.de, p.zabel@pengutronix.de,
	linuxppc-dev@lists.ozlabs.org, alsa-devel@alsa-project.org,
	devicetree@vger.kernel.org, timur@tabi.org,
	rob.herring@calxeda.com
Subject: Re: [PATCH v4 resent 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Date: Wed, 14 Aug 2013 16:48:02 +0800	[thread overview]
Message-ID: <20130814084801.GH31651@MrMyself> (raw)
In-Reply-To: <20130814075017.GE2324@pengutronix.de>

Hi Sascha,

On Wed, Aug 14, 2013 at 09:50:17AM +0200, Sascha Hauer wrote:
> > +  - tx-clksrc-names : The names for all available clock sources for tx, which
> > +  is also being listed in SoC reference manual, ClkSrc_Sel bit of SPDIF_SRPC.
> > +  And the name list would be different between different SoC. Use 'null' for
> > +  those unlisted names, and the max number of tx-clksrc-names should be 8.
> > +
> > +  - rx-clksrc-names : The names for all available clock sources for rx, which
> > +  is also being listed in SoC reference manual, TxClk_Source bit of SPDIF_STC.
> > +  And the name list would be different between different SoC. Use 'null' for
> > +  those unlisted names, and the max number of rx-clksrc-names should be 16.
> > +
> > +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.
> > +
> > +Example1:
> > +
> > +spdif: spdif@02004000 {
> > +	clocks = <&clks 197>;
> > +	clock-names = "core";
> > +	rx-clksrc-lock;
> > +	rx-clksrc-names =
> > +		"lock.ext", "lock.spdif", "lock.asrc",
> > +		"lock.spdif_ext", "lock.esai", "ext",
> > +		"spdif", "asrc", "spdif_ext", "esai",
> > +		"lock.mlb", "lock.mlb_phy", "mlb",
> > +		"mlb_phy";
> > +	tx-clksrc-names =
> > +		"xtal", "spdif", "asrc", "spdif_ext",
> > +		"esai", "ipg", "mlb", "mlb_phy";
> 
> I had a hard time understanding what you are doing here.
> 
> With this the clk names in arch/arm/mach-imx/clk-imx6q.c become an API
> between the Kernel and the devicetree. Don't do that.
> 
> There is a standardized devicetree binding for clocks. Use it.
 
I think I should first explain to you what this part is doing:
The driver needs to set Clk_source bit for TX/RX to select the 
clock from a clock mux. The names listed above are those of the 
clocks connecting to the mux, while they are not only internal 
clocks which're included in clk-imx6q.c but also external ones,
an on-board external osc for example.

The driver does get the clock by using the standard DT binding,
see the 'clocks = <&clks 197>' above, and then compare this
obtained clock->name with the name list to decide which value
should be set to the Clk_source bit.

==================================================================
ClkSrc_Sel from i.MX6Q reference manual:

Clock source selection, all other settings not shown are reserved:
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
==================================================================

So the name list here basically is not being used to obtain a
clock like what standardized DT binding does but to provide the
driver a full list to look up which value should be exactly used
according to the obtained clock.

I think I should revise the binding doc for these two lists. It 
might be hard to explain within that kinda short paragraph. 

Surely, if I misunderstand your point, please correct me. And
if you have any sage idea, please guide me.

Thank you,
Nicolin Chen




WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <b42378@freescale.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	lars@metafoo.de, timur@tabi.org, rob.herring@calxeda.com,
	broonie@kernel.org, p.zabel@pengutronix.de,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v4 resent 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Date: Wed, 14 Aug 2013 16:48:02 +0800	[thread overview]
Message-ID: <20130814084801.GH31651@MrMyself> (raw)
In-Reply-To: <20130814075017.GE2324@pengutronix.de>

Hi Sascha,

On Wed, Aug 14, 2013 at 09:50:17AM +0200, Sascha Hauer wrote:
> > +  - tx-clksrc-names : The names for all available clock sources for tx, which
> > +  is also being listed in SoC reference manual, ClkSrc_Sel bit of SPDIF_SRPC.
> > +  And the name list would be different between different SoC. Use 'null' for
> > +  those unlisted names, and the max number of tx-clksrc-names should be 8.
> > +
> > +  - rx-clksrc-names : The names for all available clock sources for rx, which
> > +  is also being listed in SoC reference manual, TxClk_Source bit of SPDIF_STC.
> > +  And the name list would be different between different SoC. Use 'null' for
> > +  those unlisted names, and the max number of rx-clksrc-names should be 16.
> > +
> > +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.
> > +
> > +Example1:
> > +
> > +spdif: spdif@02004000 {
> > +	clocks = <&clks 197>;
> > +	clock-names = "core";
> > +	rx-clksrc-lock;
> > +	rx-clksrc-names =
> > +		"lock.ext", "lock.spdif", "lock.asrc",
> > +		"lock.spdif_ext", "lock.esai", "ext",
> > +		"spdif", "asrc", "spdif_ext", "esai",
> > +		"lock.mlb", "lock.mlb_phy", "mlb",
> > +		"mlb_phy";
> > +	tx-clksrc-names =
> > +		"xtal", "spdif", "asrc", "spdif_ext",
> > +		"esai", "ipg", "mlb", "mlb_phy";
> 
> I had a hard time understanding what you are doing here.
> 
> With this the clk names in arch/arm/mach-imx/clk-imx6q.c become an API
> between the Kernel and the devicetree. Don't do that.
> 
> There is a standardized devicetree binding for clocks. Use it.
 
I think I should first explain to you what this part is doing:
The driver needs to set Clk_source bit for TX/RX to select the 
clock from a clock mux. The names listed above are those of the 
clocks connecting to the mux, while they are not only internal 
clocks which're included in clk-imx6q.c but also external ones,
an on-board external osc for example.

The driver does get the clock by using the standard DT binding,
see the 'clocks = <&clks 197>' above, and then compare this
obtained clock->name with the name list to decide which value
should be set to the Clk_source bit.

==================================================================
ClkSrc_Sel from i.MX6Q reference manual:

Clock source selection, all other settings not shown are reserved:
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
==================================================================

So the name list here basically is not being used to obtain a
clock like what standardized DT binding does but to provide the
driver a full list to look up which value should be exactly used
according to the obtained clock.

I think I should revise the binding doc for these two lists. It 
might be hard to explain within that kinda short paragraph. 

Surely, if I misunderstand your point, please correct me. And
if you have any sage idea, please guide me.

Thank you,
Nicolin Chen

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

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-12 12:05 [PATCH v4 resent 0/2] Add freescale S/PDIF CPU DAI and machine drivers Nicolin Chen
2013-08-12 12:05 ` Nicolin Chen
2013-08-12 12:05 ` Nicolin Chen
2013-08-12 12:05 ` [PATCH v4 resent 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver Nicolin Chen
2013-08-12 12:05   ` Nicolin Chen
2013-08-12 12:05   ` Nicolin Chen
2013-08-14  7:50   ` Sascha Hauer
2013-08-14  7:50     ` Sascha Hauer
2013-08-14  8:48     ` Nicolin Chen [this message]
2013-08-14  8:48       ` Nicolin Chen
2013-08-14  9:56       ` [alsa-devel] " Sascha Hauer
2013-08-14  9:56         ` Sascha Hauer
2013-08-14 10:23         ` [alsa-devel] " Nicolin Chen
2013-08-14 10:23           ` Nicolin Chen
2013-08-14 10:23           ` Nicolin Chen
2013-08-14 12:19           ` [alsa-devel] " Sascha Hauer
2013-08-14 12:19             ` Sascha Hauer
2013-08-15  2:33             ` [alsa-devel] " Nicolin Chen
2013-08-15  2:33               ` Nicolin Chen
2013-08-14 12:06       ` Philipp Zabel
2013-08-14 12:06         ` Philipp Zabel
2013-08-15  2:28         ` Nicolin Chen
2013-08-15  2:28           ` Nicolin Chen
2013-08-12 12:05 ` [PATCH v4 resent 2/2] ASoC: fsl: Add S/PDIF machine driver Nicolin Chen
2013-08-12 12:05   ` Nicolin Chen
2013-08-12 12:05   ` 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=20130814084801.GH31651@MrMyself \
    --to=b42378@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lars@metafoo.de \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=p.zabel@pengutronix.de \
    --cc=rob.herring@calxeda.com \
    --cc=s.hauer@pengutronix.de \
    --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 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.