From: Tero Kristo <t-kristo@ti.com>
To: Christoph Fritz <chf.fritz@googlemail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
linux-kernel@vger.kernel.org, pali.rohar@gmail.com, pavel@ucw.cz,
Nishanth Menon <nm@ti.com>
Subject: Re: OMAP: clock DT conversion issues with omap36xx
Date: Wed, 29 Jan 2014 16:57:00 +0200 [thread overview]
Message-ID: <52E916BC.5040906@ti.com> (raw)
In-Reply-To: <1390994505.5023.32.camel@mars>
On 01/29/2014 01:21 PM, Christoph Fritz wrote:
> On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:
>> On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
>>>
>>>>> Due to a regression since next-20140122 the following errors are present:
>>>>>
>>>>> - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch
>>>>> in this set, erroneously outputs only 12 Mhz.
>>>>> Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz.
>>>>>
>>>>> - omap_dss, which gets configured by the third patch in this set, fails
>>>>> to do 'dss_set_fck_rate(fck);' in
>>>>> drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to:
>>>>>
>>>>> | omapdss_dss: probe of omapdss_dss failed with error -22
>>>>> | omapdss CORE error: Failed to initialize DSS platform driver
>>>>> | panel-dpi panel-dpi.0: failed to find video source 'dpi.0
>>>>>
>>>>> Both regressions seem to have something to do with the clock framework.
>>>>> Could this be related to the DT clock conversion patches?
>>>>
>>>
>>> Yea its definitely possible, as the clock DT conversion touches pretty
>>> much everything. Have you tried whether this works properly with legacy
>>> boot? Personally I don't have access to any omap3 devices that would
>>> have display and have no possibility to check this out myself. Anyway,
>>> my initial guess is that some clock divider setup might be wrong with
>>> omap3, or we are missing some ti,set-rate-parent flag for some clock
>>> node which prevents escalating clk_set_rate properly. However, it should
>>> be easy to debug this by looking at the clock node in question, and its
>>> parent nodes to see if there are any problems.
>>
>> 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.
>>
>> So I added this patch:
>>
>> Subject: [PATCH] ARM: dts: fix omap3 clock multiplier for dpll4_m2x2_ck
>>
>> Before DT clock conversion, there was no multiplier for dpll4_m2x2_ck.
>> So to be compatible again, set dpll4_m2x2_mul_ck multiplier back to 1.
>> ---
>> arch/arm/boot/dts/omap3xxx-clocks.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
>> index cb04d4b..b594050 100644
>> --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
>> +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
>> @@ -212,7 +212,7 @@
>> #clock-cells = <0>;
>> compatible = "fixed-factor-clock";
>> clocks = <&dpll4_m2_ck>;
>> - clock-mult = <2>;
>> + clock-mult = <1>;
>> clock-div = <1>;
>> };
>>
>> And it works again. But due to the fact that sys_clkout2 was at 12 Mhz
>> instead of 24, shouldn't it have been at 48 caused by "clock-mult = 2 ?
>
> Any ideas on that?
>
> I reverted the patch above and added:
Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding
ti,min-div = <2>; and ti,max-div = <4>; to properties of the clock node.
-Tero
>
> From: Tero Kristo <t-kristo@ti.com>
> Date: Wed, 29 Jan 2014 11:03:46 +0200
> Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck
>
> OMAP36xx has different hardware implementation for the omap96m_alwon_fck
> compared to other OMAP3 variants. Reflect this properly in the dts file.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> arch/arm/boot/dts/omap36xx-clocks.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> index 2fcf253..24ddf3f 100644
> --- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> @@ -88,3 +88,12 @@
> <&mcbsp4_ick>, <&uart4_fck>;
> };
> };
> +
> +&omap_96m_alwon_fck {
> + compatible = "ti,divider-clock";
> + clocks = <&omap_192m_alwon_fck>;
> + ti,bit-shift = <12>;
> + ti,max-div = <2>;
> + reg = <0x0a40>;
> + ti,index-starts-at-one;
> +};
>
> But the output of sys_clkout2 is still wrong.
>
> clk_summary__next-20140124__patch_tero_fix_omap96m_alwon_fck
> dpll4_m2_ck 1 1 96000000
> dpll4_m2x2_mul_ck 1 1 192000000
> dpll4_m2x2_ck 1 1 192000000
> omap_192m_alwon_fck 1 1 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
>
> Thanks
> -- Christoph
>
WARNING: multiple messages have this Message-ID (diff)
From: Tero Kristo <t-kristo@ti.com>
To: Christoph Fritz <chf.fritz@googlemail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <pali.rohar@gmail.com>,
<pavel@ucw.cz>, Nishanth Menon <nm@ti.com>
Subject: Re: OMAP: clock DT conversion issues with omap36xx
Date: Wed, 29 Jan 2014 16:57:00 +0200 [thread overview]
Message-ID: <52E916BC.5040906@ti.com> (raw)
In-Reply-To: <1390994505.5023.32.camel@mars>
On 01/29/2014 01:21 PM, Christoph Fritz wrote:
> On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:
>> On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
>>>
>>>>> Due to a regression since next-20140122 the following errors are present:
>>>>>
>>>>> - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch
>>>>> in this set, erroneously outputs only 12 Mhz.
>>>>> Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz.
>>>>>
>>>>> - omap_dss, which gets configured by the third patch in this set, fails
>>>>> to do 'dss_set_fck_rate(fck);' in
>>>>> drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to:
>>>>>
>>>>> | omapdss_dss: probe of omapdss_dss failed with error -22
>>>>> | omapdss CORE error: Failed to initialize DSS platform driver
>>>>> | panel-dpi panel-dpi.0: failed to find video source 'dpi.0
>>>>>
>>>>> Both regressions seem to have something to do with the clock framework.
>>>>> Could this be related to the DT clock conversion patches?
>>>>
>>>
>>> Yea its definitely possible, as the clock DT conversion touches pretty
>>> much everything. Have you tried whether this works properly with legacy
>>> boot? Personally I don't have access to any omap3 devices that would
>>> have display and have no possibility to check this out myself. Anyway,
>>> my initial guess is that some clock divider setup might be wrong with
>>> omap3, or we are missing some ti,set-rate-parent flag for some clock
>>> node which prevents escalating clk_set_rate properly. However, it should
>>> be easy to debug this by looking at the clock node in question, and its
>>> parent nodes to see if there are any problems.
>>
>> 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.
>>
>> So I added this patch:
>>
>> Subject: [PATCH] ARM: dts: fix omap3 clock multiplier for dpll4_m2x2_ck
>>
>> Before DT clock conversion, there was no multiplier for dpll4_m2x2_ck.
>> So to be compatible again, set dpll4_m2x2_mul_ck multiplier back to 1.
>> ---
>> arch/arm/boot/dts/omap3xxx-clocks.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
>> index cb04d4b..b594050 100644
>> --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
>> +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
>> @@ -212,7 +212,7 @@
>> #clock-cells = <0>;
>> compatible = "fixed-factor-clock";
>> clocks = <&dpll4_m2_ck>;
>> - clock-mult = <2>;
>> + clock-mult = <1>;
>> clock-div = <1>;
>> };
>>
>> And it works again. But due to the fact that sys_clkout2 was at 12 Mhz
>> instead of 24, shouldn't it have been at 48 caused by "clock-mult = 2 ?
>
> Any ideas on that?
>
> I reverted the patch above and added:
Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding
ti,min-div = <2>; and ti,max-div = <4>; to properties of the clock node.
-Tero
>
> From: Tero Kristo <t-kristo@ti.com>
> Date: Wed, 29 Jan 2014 11:03:46 +0200
> Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck
>
> OMAP36xx has different hardware implementation for the omap96m_alwon_fck
> compared to other OMAP3 variants. Reflect this properly in the dts file.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> arch/arm/boot/dts/omap36xx-clocks.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> index 2fcf253..24ddf3f 100644
> --- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
> @@ -88,3 +88,12 @@
> <&mcbsp4_ick>, <&uart4_fck>;
> };
> };
> +
> +&omap_96m_alwon_fck {
> + compatible = "ti,divider-clock";
> + clocks = <&omap_192m_alwon_fck>;
> + ti,bit-shift = <12>;
> + ti,max-div = <2>;
> + reg = <0x0a40>;
> + ti,index-starts-at-one;
> +};
>
> But the output of sys_clkout2 is still wrong.
>
> clk_summary__next-20140124__patch_tero_fix_omap96m_alwon_fck
> dpll4_m2_ck 1 1 96000000
> dpll4_m2x2_mul_ck 1 1 192000000
> dpll4_m2x2_ck 1 1 192000000
> omap_192m_alwon_fck 1 1 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
>
> Thanks
> -- Christoph
>
next prev parent reply other threads:[~2014-01-29 14:57 UTC|newest]
Thread overview: 51+ 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:04 ` Tomi Valkeinen
2014-01-28 9:35 ` Christoph Fritz
2014-01-28 9:48 ` Tomi Valkeinen
2014-01-28 9:48 ` Tomi Valkeinen
2014-01-28 13:40 ` Tero Kristo
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 [this message]
2014-01-29 14:57 ` Tero Kristo
2014-02-01 18:55 ` Christoph Fritz
2014-01-29 19:03 ` Nishanth Menon
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-04 15:50 ` Tero Kristo
2014-02-07 10:12 ` Christoph Fritz
2014-02-07 13:49 ` Tomi Valkeinen
2014-02-07 13:49 ` Tomi Valkeinen
2014-02-10 20:54 ` Christoph Fritz
2014-02-11 14:53 ` Tomi Valkeinen
2014-02-11 14:53 ` Tomi Valkeinen
2014-02-12 13:18 ` Tomi Valkeinen
2014-02-12 13:18 ` Tomi Valkeinen
2014-02-12 22:30 ` Belisko Marek
2014-02-13 9:03 ` Tomi Valkeinen
2014-02-13 9:03 ` Tomi Valkeinen
2014-02-13 10:05 ` 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 7:50 ` Tomi Valkeinen
2014-01-28 8:48 ` 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:10 ` Tero Kristo
2014-01-29 9:29 ` Ivaylo Dimitrov
2014-01-29 9:38 ` Tomi Valkeinen
2014-01-29 9:38 ` Tomi Valkeinen
2014-01-29 9:50 ` Tero Kristo
2014-01-29 9:50 ` Tero Kristo
2014-01-29 11:30 ` Tomi Valkeinen
2014-01-29 11:30 ` Tomi Valkeinen
2014-01-29 18:52 ` Ivaylo Dimitrov
2014-01-30 6:04 ` Tomi Valkeinen
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=52E916BC.5040906@ti.com \
--to=t-kristo@ti.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=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 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.