linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Belisko Marek <marek.belisko@gmail.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Christoph Fritz <chf.fritz@googlemail.com>,
	Tero Kristo <t-kristo@ti.com>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	pali.rohar@gmail.com, Pavel Machek <pavel@ucw.cz>,
	Nishanth Menon <nm@ti.com>
Subject: Re: OMAP: clock DT conversion issues with omap36xx
Date: Wed, 12 Feb 2014 23:30:15 +0100	[thread overview]
Message-ID: <CAAfyv37FOA8spxCbxLra+sn8BJFh2dsnMTU4NU8LUKteFdzsBA@mail.gmail.com> (raw)
In-Reply-To: <52FB748E.6050007@ti.com>

Hi Tomi,

On Wed, Feb 12, 2014 at 2:18 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Tero, Christoph,
>
> On 07/02/14 12:12, Christoph Fritz wrote:
>> On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote:
>>> On 01/29/2014 01:21 PM, Christoph Fritz wrote:
>>>>> Currently I only analyzed sys_clkout2 (see attachments for full
>>>>> clk_summary files):
>>>>>
>>>>> clk_summary__next-20140115__works_as_expected:
>>>>>               dpll4_m2_ck        1           1            96000000
>>>>>                  dpll4_m2x2_ck   1           1            96000000
>>>>>                     omap_192m_alwon_fck 1           1            96000000
>>>>>                        omap_96m_alwon_fck 1           2            96000000
>>>>>                           per_96m_fck 0           6            96000000
>>>>>                              mcbsp4_fck 0           1            96000000
>>>>>                              mcbsp3_fck 0           2            96000000
>>>>>                              mcbsp2_fck 0           2            96000000
>>>>>                           cm_96m_fck 2           3            96000000
>>>>>                              clkout2_src_ck 1           1            96000000
>>>>>                                 sys_clkout2 1           1            24000000
>>>>>
>>>>> For real, on pin sys_clkout2 are correctly 24 Mhz measured.
>>>>>
>>>>> clk_summary__next-20140124__sysclkout2_dss_fails:
>>>>>               dpll4_m2_ck        1           1            96000000
>>>>>                  dpll4_m2x2_mul_ck 1           1            192000000
>>>>>                     dpll4_m2x2_ck 1           1            192000000
>>>>>                        omap_192m_alwon_fck 0           0            192000000
>>>>>                        omap_96m_alwon_fck 1           2            192000000
>>>>>                           per_96m_fck 0           6            192000000
>>>>>                              mcbsp4_fck 0           1            192000000
>>>>>                              mcbsp3_fck 0           2            192000000
>>>>>                              mcbsp2_fck 0           2            192000000
>>>>>                           cm_96m_fck 2           3            192000000
>>>>>                              clkout2_src_ck 1           1            192000000
>>>>>                                 sys_clkout2 1           1            24000000
>>>>>
>>>>> For real, on pin sys_clkout2 are only ~12 Mhz measured.
>>>
>>> Hey Christoph,
>>>
>>> I had a chance to look at this in more detail, and it looks like your
>>> patch above was almost the correct one (except that I think you modified
>>> wrong property and also modified the clock node for all omap3 variants.)
>>> Can you give this one a shot? Can you also send me the clk-summary dump
>>> with this patch (with the relevant nodes)?
>>
>>              dpll4_m2_ck        1           1            96000000   0
>>                 dpll4_m2x2_mul_ck 1           1            192000000  0
>>                    dpll4_m2x2_ck 1           1            192000000  0
>>                       omap_192m_alwon_fck 0           0            192000000  0
>>                       omap_96m_alwon_fck 1           2            96000000   0
>>                          per_96m_fck 0           6            96000000   0
>>                             mcbsp4_fck 0           1            96000000   0
>>                             mcbsp3_fck 0           2            96000000   0
>>                             mcbsp2_fck 0           2            96000000   0
>>                          cm_96m_fck 2           3            96000000   0
>>                             clkout2_src_ck 1           1            96000000   0
>>                                sys_clkout2 1           1            24000000   0
>>
>> Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want,
>> you can add my:
>> Tested-by: Christoph Fritz <chf.fritz@googlemail.com>
>>
>> Below is my clock fix for dss:
>>
>> From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001
>> From: Christoph Fritz <chf.fritz@googlemail.com>
>> Date: Fri, 7 Feb 2014 10:51:15 +0100
>> Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree
>
> Ookay, I finally got Beagle xM working with DSS DT. So, to summarize the
> problem: DPLL4 on omap3630 is a Type B DPLL. Type B DPLL does not have
> x2 multiplier like other DPLLs. Afaik, DPLL4 on 3630 is the only Type B
> DPLL on OMAP3 SoCs.
>
> Tero's patch fixed 96m clock, which comes from dpll4_m2, by adding an
> extra /2 divider to that clock path. So the 96m clock first gets
> mutiplied by 2, even though the HW doesn't do that, and then divided by
> 2, even though the HW doesn't do that.
>
> Christoph's patch fixes DSS fclk, which comes from dpll4_m4, by skipping
> the x2 clock nodes totally, which is much better. However, it leaves the
> old x2 clock nodes there, and when dpll4_m4 clock rate changes (as it
> does when omapdss sets the fclk), the unused x2 clocks do recalcs,
> breaking everything. This last bit is a bit guesswork, I didn't actually
> verify it, but the fact is that if I remove the x2 clocks totally,
> omapdss work fine.
>
> Sooo... What should be done is create new DPLL4 clock paths for
> OMAP3630, which do not have the x2 clocks at all. I tried to do that,
> but it wasn't trivial (at least to me who is not so familiar with the
> clock data in DT).
>
> However, I hacked together the patch below, which "fixes" the issue for
> 96m and dss fclk. It sets the clock parents so that the x2 clocks are
> skipped, and makes the x2 clock nodes compatible with "unused", making
> them effectively disappear. I only verified dss fclk, so Christoph, can
> you verify the 96m clock?
With below hack dss v3 (rebased on top 3.14-rc2) works (without it
fails to probe).
>
>  Tomi
>
> From ab29f9a3a43d95cdf06421bd9f29c4d7418f37de Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Wed, 12 Feb 2014 15:07:03 +0200
> Subject: [PATCH] HACK: OMAP3630: fix for 96m and dss fclks
>
> ---
>  arch/arm/boot/dts/omap36xx-clocks.dtsi | 26 ++++++++++++++++++++++++++
>  arch/arm/boot/dts/omap36xx.dtsi        |  2 +-
>  2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> index 2fcf253b677c..9fe91ebf41fd 100644
> --- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> @@ -70,6 +70,32 @@
>         };
>  };
>
> +/* HACK to skip x2 multiplier for 96m clock */
> +&omap_96m_alwon_fck {
> +       clocks = <&dpll4_m2_ck>;
> +};
> +
> +&dpll4_m2x2_mul_ck {
> +       compatible = "unused";
> +};
> +
> +&dpll4_m2x2_ck {
> +       compatible = "unused";
> +};
> +
> +/* HACK to skip x2 multiplier for dss clock */
> +&dss1_alwon_fck_3430es2 {
> +       clocks = <&dpll4_m4_ck>;
> +};
> +
> +&dpll4_m4x2_mul_ck {
> +       compatible = "unused";
> +};
> +
> +&dpll4_m4x2_ck {
> +       compatible = "unused";
> +};
> +
>  &cm_clockdomains {
>         dpll4_clkdm: dpll4_clkdm {
>                 compatible = "ti,clockdomain";
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi
> b/arch/arm/boot/dts/omap36xx.dtsi
> index 7e8dee9175d6..5e1bcd06a996 100644
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -52,7 +52,7 @@
>         };
>  };
>
> -/include/ "omap36xx-clocks.dtsi"
>  /include/ "omap34xx-omap36xx-clocks.dtsi"
>  /include/ "omap36xx-omap3430es2plus-clocks.dtsi"
>  /include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
> +/include/ "omap36xx-clocks.dtsi"
> --
> 1.8.3.2
>
>
>

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

  reply	other threads:[~2014-02-12 22:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27 17:30 [BISECTED] OMAP: DSS: clk rate mismatch Ivaylo Dimitrov
2014-01-27 18:41 ` Christoph Fritz
2014-01-28  9:04   ` Tomi Valkeinen
2014-01-28  9:35     ` Christoph Fritz
2014-01-28  9:48       ` Tomi Valkeinen
2014-01-28 13:40         ` Tero Kristo
2014-01-28 17:02           ` Christoph Fritz
2014-01-29 11:21             ` OMAP: clock DT conversion issues with omap36xx Christoph Fritz
2014-01-29 14:57               ` Tero Kristo
2014-02-01 18:55                 ` Christoph Fritz
2014-01-29 19:03               ` Nishanth Menon
2014-02-01 18:52                 ` Christoph Fritz
2014-02-02 20:09                   ` Christoph Fritz
2014-02-04 15:50               ` Tero Kristo
2014-02-07 10:12                 ` Christoph Fritz
2014-02-07 13:49                   ` Tomi Valkeinen
2014-02-10 20:54                     ` Christoph Fritz
2014-02-11 14:53                       ` Tomi Valkeinen
2014-02-12 13:18                   ` Tomi Valkeinen
2014-02-12 22:30                     ` Belisko Marek [this message]
2014-02-13  9:03                     ` Tomi Valkeinen
2014-02-13 10:05                       ` Tomi Valkeinen
2014-02-14  2:18                         ` Christoph Fritz
2014-01-28  7:50 ` [BISECTED] OMAP: DSS: clk rate mismatch Tomi Valkeinen
2014-01-28  8:48   ` Tomi Valkeinen
2014-01-28 18:17     ` Ivaylo Dimitrov
2014-01-29  9:10       ` Tero Kristo
2014-01-29  9:29         ` Ivaylo Dimitrov
2014-01-29  9:38           ` Tomi Valkeinen
2014-01-29  9:50             ` Tero Kristo
2014-01-29 11:30       ` Tomi Valkeinen
2014-01-29 18:52         ` Ivaylo Dimitrov
2014-01-30  6:04           ` Tomi Valkeinen

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=CAAfyv37FOA8spxCbxLra+sn8BJFh2dsnMTU4NU8LUKteFdzsBA@mail.gmail.com \
    --to=marek.belisko@gmail.com \
    --cc=chf.fritz@googlemail.com \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=pali.rohar@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=t-kristo@ti.com \
    --cc=tomi.valkeinen@ti.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).