Hi Tomi,
linux-next-20140124 DSS is broken on N900 - display stays black (there
is some noise though). I booted the kernel with qemu and it gives the
following warning:
[ 0.623779] DSS: set fck to 172800000
[ 0.624237] ------------[ cut here ]------------
[ 0.624298] WARNING: CPU: 0 PID: 1 at
drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
[ 0.624359] clk rate mismatch: 288000000 != 172800000
[ 0.624389] Modules linked in:
[ 0.624481] CPU: 0 PID: 1 Comm: swapper Tainted: G W
3.13.0-next-20140124+ #35
[ 0.624572] [<c00126dc>] (unwind_backtrace) from [<c0010c30>]
(show_stack+0x10/0x14)
[ 0.624633] [<c0010c30>] (show_stack) from [<c0032d8c>]
(warn_slowpath_common+0x64/0x84)
[ 0.624694] [<c0032d8c>] (warn_slowpath_common) from [<c0032e2c>]
(warn_slowpath_fmt+0x2c/0x3c)
[ 0.624755] [<c0032e2c>] (warn_slowpath_fmt) from [<c01edb88>]
(dss_set_fck_rate+0x68/0x8c)
[ 0.624816] [<c01edb88>] (dss_set_fck_rate) from [<c056f300>]
(omap_dsshw_probe+0x1e4/0x2f8)
[ 0.624877] [<c056f300>] (omap_dsshw_probe) from [<c023e5f8>]
(platform_drv_probe+0x18/0x48)
[ 0.624938] [<c023e5f8>] (platform_drv_probe) from [<c023d1f0>]
(driver_probe_device+0xb0/0x200)
[ 0.624999] [<c023d1f0>] (driver_probe_device) from [<c023d3a8>]
(__driver_attach+0x68/0x8c)
[ 0.625061] [<c023d3a8>] (__driver_attach) from [<c023bac0>]
(bus_for_each_dev+0x50/0x88)
[ 0.625122] [<c023bac0>] (bus_for_each_dev) from [<c023ca28>]
(bus_add_driver+0xcc/0x1c8)
[ 0.625183] [<c023ca28>] (bus_add_driver) from [<c023da24>]
(driver_register+0x9c/0xe0)
[ 0.625244] [<c023da24>] (driver_register) from [<c023e540>]
(platform_driver_probe+0x20/0xc0)
[ 0.625305] [<c023e540>] (platform_driver_probe) from [<c056f088>]
(omap_dss_init+0x1c/0xb0)
[ 0.625366] [<c056f088>] (omap_dss_init) from [<c0008758>]
(do_one_initcall+0x94/0x138)
[ 0.625427] [<c0008758>] (do_one_initcall) from [<c054db64>]
(kernel_init_freeable+0xe4/0x1ac)
[ 0.625488] [<c054db64>] (kernel_init_freeable) from [<c03a0108>]
(kernel_init+0x8/0x100)
[ 0.625549] [<c03a0108>] (kernel_init) from [<c000ded8>]
(ret_from_fork+0x14/0x3c)
[ 0.625610] ---[ end trace 9f1065fe5ada0e27 ]---
According to git bisect, this
http://permalink.gmane.org/gmane.linux.ports.arm.omap/107355 is the
commit that broke it. Unfortunately that commit cannot be reverted, so I
did a quick'n'dirty hack(just for the sake of it):
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 9a145da..10e2fab 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -482,7 +482,8 @@ bool dss_div_calc(unsigned long pck, unsigned long
fck_min,
int dss_set_fck_rate(unsigned long rate)
{
- int r;
+ int r, mul, div;
+ unsigned long prate;
DSSDBG("set fck to %lu\n", rate);
@@ -490,8 +491,22 @@ int dss_set_fck_rate(unsigned long rate)
if (r)
return r;
- dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
+ prate = clk_get_rate(dss.dss_clk);
+
+ for (mul = 1; mul < 16; mul++)
+ for(div = 1; div< 16; div++)
+ if(((prate*mul)/div) == rate)
+ goto found;
+
+found:
+ if(mul != 16)
+ r = clk_set_rate(dss.dss_clk, (rate*mul)/div);
+
+ if (r)
+ return r;
+
+ dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
WARN_ONCE(dss.dss_clk_rate != rate,
"clk rate mismatch: %lu != %lu", dss.dss_clk_rate,
rate);
and it solves the problem. I hope the above will give you a better idea
on what is really broken (and how to fix it :) ).
Regards,
Ivo
On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote:
> linux-next-20140124 DSS is broken on N900 - display stays black (there
> is some noise though). I booted the kernel with qemu and it gives the
> following warning:
>
> [ 0.623779] DSS: set fck to 172800000
> [ 0.624237] ------------[ cut here ]------------
> [ 0.624298] WARNING: CPU: 0 PID: 1 at
> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
> [ 0.624359] clk rate mismatch: 288000000 != 172800000
Here are also clock regressions since next-20140122 regarding
dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a
dm37xx100 board. Please see here:
[PATCH v3 0/4] ARM: add omap3 INCOstartec board support
http://thread.gmane.org/gmane.linux.ports.arm.omap/110095
Thanks
-- chf
On 2014-01-27 19:30, Ivaylo Dimitrov wrote:
> Hi Tomi,
>
> linux-next-20140124 DSS is broken on N900 - display stays black (there
> is some noise though). I booted the kernel with qemu and it gives the
> following warning:
>
> [ 0.623779] DSS: set fck to 172800000
> [ 0.624237] ------------[ cut here ]------------
> [ 0.624298] WARNING: CPU: 0 PID: 1 at
> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
> [ 0.624359] clk rate mismatch: 288000000 != 172800000
That says that the omapdss tries to set the func clock to 172.8 MHz, but
after setting the rate, the clock is at 288 MHz.
I just hit the same warning with beagle-xm yesterday, with v3.13-rc6 +
DSS device tree patches, although it might be a different thing. I see
that the actual clock is lower than what omapdss tries to set, you have
the other way around.
The beagle-xm issue is related to a clk-divider fix I have sent some
time ago:
http://mid.gmane.org/[email protected]
Basically the issue is that omapdss needs to produce very precise pixel
clocks, derived from fck, but the fck rate options are quite limited. So
omapdss tries to find out what kind of rates it could get for the fck,
i.e. it does the clock divider calculations itself that would normally
be left to the clock framework.
That means the omapdss should do rounding the same way as the clock
framework does. But clock framework has no rules about the rounding, so
omapdss easily gets it wrong. And when you add the bug for which I
posted the patch above, it seems the omapdss clock calculations are not
very functional at the moment with fractional clock rates.
However, I think the issue I see with beagle-xm should always result in
lower actual fck than requested, but you see the other way around. So I
wonder if it's something else... N900 clock calculations do initiate
from sdi.c, instead of dpi.c for beagle, but they do look rather
similar, and use the same helper functions from dss.c and dispc.c.
How is the dss clock calculated on n900? Can you attach
debug/clk/clk_summary output?
Tomi
On 2014-01-28 09:50, Tomi Valkeinen wrote:
> On 2014-01-27 19:30, Ivaylo Dimitrov wrote:
>> Hi Tomi,
>>
>> linux-next-20140124 DSS is broken on N900 - display stays black (there
>> is some noise though). I booted the kernel with qemu and it gives the
>> following warning:
>>
>> [ 0.623779] DSS: set fck to 172800000
>> [ 0.624237] ------------[ cut here ]------------
>> [ 0.624298] WARNING: CPU: 0 PID: 1 at
>> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
>> [ 0.624359] clk rate mismatch: 288000000 != 172800000
>
> That says that the omapdss tries to set the func clock to 172.8 MHz, but
> after setting the rate, the clock is at 288 MHz.
>
> I just hit the same warning with beagle-xm yesterday, with v3.13-rc6 +
> DSS device tree patches, although it might be a different thing. I see
> that the actual clock is lower than what omapdss tries to set, you have
> the other way around.
>
> The beagle-xm issue is related to a clk-divider fix I have sent some
> time ago:
>
> http://mid.gmane.org/[email protected]
I made a somewhat hacky quickfix for beagle. Applying that and the
clk-divider from the link above makes things work for me. However, as I
said, the issue with n900 might be different, but it'd be interesting to
hear if it has any effect.
Tomi
On 2014-01-27 20:41, Christoph Fritz wrote:
> On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote:
>> linux-next-20140124 DSS is broken on N900 - display stays black (there
>> is some noise though). I booted the kernel with qemu and it gives the
>> following warning:
>>
>> [ 0.623779] DSS: set fck to 172800000
>> [ 0.624237] ------------[ cut here ]------------
>> [ 0.624298] WARNING: CPU: 0 PID: 1 at
>> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
>> [ 0.624359] clk rate mismatch: 288000000 != 172800000
>
> Here are also clock regressions since next-20140122 regarding
> dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a
> dm37xx100 board. Please see here:
I presume you get a similar warning on your board? What rates does it
report?
Tomi
On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote:
> On 2014-01-27 20:41, Christoph Fritz wrote:
> > On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote:
> >> linux-next-20140124 DSS is broken on N900 - display stays black (there
> >> is some noise though). I booted the kernel with qemu and it gives the
> >> following warning:
> >>
> >> [ 0.623779] DSS: set fck to 172800000
> >> [ 0.624237] ------------[ cut here ]------------
> >> [ 0.624298] WARNING: CPU: 0 PID: 1 at
> >> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
> >> [ 0.624359] clk rate mismatch: 288000000 != 172800000
> >
> > Here are also clock regressions since next-20140122 regarding
> > dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a
> > dm37xx100 board. Please see here:
>
> I presume you get a similar warning on your board? What rates does it
> report?
None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22.
To quote the cover-letter[1] of my board-support patch series here:
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?
[1]: http://thread.gmane.org/gmane.linux.ports.arm.omap/110095
On 2014-01-28 11:35, Christoph Fritz wrote:
> On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote:
>> On 2014-01-27 20:41, Christoph Fritz wrote:
>>> On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote:
>>>> linux-next-20140124 DSS is broken on N900 - display stays black (there
>>>> is some noise though). I booted the kernel with qemu and it gives the
>>>> following warning:
>>>>
>>>> [ 0.623779] DSS: set fck to 172800000
>>>> [ 0.624237] ------------[ cut here ]------------
>>>> [ 0.624298] WARNING: CPU: 0 PID: 1 at
>>>> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
>>>> [ 0.624359] clk rate mismatch: 288000000 != 172800000
>>>
>>> Here are also clock regressions since next-20140122 regarding
>>> dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a
>>> dm37xx100 board. Please see here:
>>
>> I presume you get a similar warning on your board? What rates does it
>> report?
>
> None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22.
Ok, then it's something else. That means clk_set_rate() fails.
If you can do some tests, you could print the rate that the
dss_set_fck_rate() is given, to see that it's something reasonable, and
also do a clk_get_rate(dss.dss_clk) to see that the clock itself is ok
and there's some valid rate there.
> To quote the cover-letter[1] of my board-support patch series here:
>
> 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?
No idea...
Tomi
On 01/28/2014 11:48 AM, Tomi Valkeinen wrote:
> On 2014-01-28 11:35, Christoph Fritz wrote:
>> On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote:
>>> On 2014-01-27 20:41, Christoph Fritz wrote:
>>>> On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote:
>>>>> linux-next-20140124 DSS is broken on N900 - display stays black (there
>>>>> is some noise though). I booted the kernel with qemu and it gives the
>>>>> following warning:
>>>>>
>>>>> [ 0.623779] DSS: set fck to 172800000
>>>>> [ 0.624237] ------------[ cut here ]------------
>>>>> [ 0.624298] WARNING: CPU: 0 PID: 1 at
>>>>> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
>>>>> [ 0.624359] clk rate mismatch: 288000000 != 172800000
>>>>
>>>> Here are also clock regressions since next-20140122 regarding
>>>> dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a
>>>> dm37xx100 board. Please see here:
>>>
>>> I presume you get a similar warning on your board? What rates does it
>>> report?
>>
>> None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22.
>
> Ok, then it's something else. That means clk_set_rate() fails.
>
> If you can do some tests, you could print the rate that the
> dss_set_fck_rate() is given, to see that it's something reasonable, and
> also do a clk_get_rate(dss.dss_clk) to see that the clock itself is ok
> and there's some valid rate there.
>
>> To quote the cover-letter[1] of my board-support patch series here:
>>
>> 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?
>
> No idea...
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.
-Tero
On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
> On 01/28/2014 11:48 AM, Tomi Valkeinen wrote:
> > On 2014-01-28 11:35, Christoph Fritz wrote:
> >> On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote:
> >>> On 2014-01-27 20:41, Christoph Fritz wrote:
> >>>> On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote:
> >>>>> linux-next-20140124 DSS is broken on N900 - display stays black (there
> >>>>> is some noise though). I booted the kernel with qemu and it gives the
> >>>>> following warning:
> >>>>>
> >>>>> [ 0.623779] DSS: set fck to 172800000
> >>>>> [ 0.624237] ------------[ cut here ]------------
> >>>>> [ 0.624298] WARNING: CPU: 0 PID: 1 at
> >>>>> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
> >>>>> [ 0.624359] clk rate mismatch: 288000000 != 172800000
> >>>>
> >>>> Here are also clock regressions since next-20140122 regarding
> >>>> dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a
> >>>> dm37xx100 board. Please see here:
> >>>
> >>> I presume you get a similar warning on your board? What rates does it
> >>> report?
> >>
> >> None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22.
> >
> > Ok, then it's something else. That means clk_set_rate() fails.
> >
> > If you can do some tests, you could print the rate that the
> > dss_set_fck_rate() is given, to see that it's something reasonable, and
> > also do a clk_get_rate(dss.dss_clk) to see that the clock itself is ok
> > and there's some valid rate there.
> >
> >> To quote the cover-letter[1] of my board-support patch series here:
> >>
> >> 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?
> >
> > No idea...
>
> 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:
>From c1f8a2aa60cb8973f7eeeb517fb067b1fce66c1f Mon Sep 17 00:00:00 2001
From: Christoph Fritz <[email protected]>
Date: Tue, 28 Jan 2014 17:35:10 +0100
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 ?
Thanks
-- Christoph
On 28.01.2014 10:48, Tomi Valkeinen wrote:
> I made a somewhat hacky quickfix for beagle. Applying that and the
> clk-divider from the link above makes things work for me. However, as I
> said, the issue with n900 might be different, but it'd be interesting to
> hear if it has any effect.
>
> Tomi
>
Applying those 2 patches doesn't help, still get exactly the same warning.
Find attached my clk_summary (with my hacky patch applied, otherwise I
cannot boot the device)
Ivo
On 01/28/2014 08:17 PM, Ivaylo Dimitrov wrote:
>
>
> On 28.01.2014 10:48, Tomi Valkeinen wrote:
>
>> I made a somewhat hacky quickfix for beagle. Applying that and the
>> clk-divider from the link above makes things work for me. However, as I
>> said, the issue with n900 might be different, but it'd be interesting to
>> hear if it has any effect.
>>
>> Tomi
>>
>
> Applying those 2 patches doesn't help, still get exactly the same warning.
>
> Find attached my clk_summary (with my hacky patch applied, otherwise I
> cannot boot the device)
>
> Ivo
It looks like the omap36xx version of the omap96m_alwon_fck is modelled
improperly in the dts files. I don't have access to omap36xx hardware
myself, but give a try for the following patch:
From: Tero Kristo <[email protected]>
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 <[email protected]>
---
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;
+};
--
1.7.9.5
On 29.01.2014 11:10, Tero Kristo wrote:
>
> It looks like the omap36xx version of the omap96m_alwon_fck is modelled
> improperly in the dts files. I don't have access to omap36xx hardware
> myself, but give a try for the following patch:
>
>
It could be that 36xx omap96m_alwon_fck clock is wrongly modeled, but I
am testing on 1) 3430es2 (Nokia N900) and 2) legacy boot, so I guess
that patch won't help much (unless I am missing something and DT is used
even with legacy boot and 36xx clocks are used on 3430es2)
Thanks,
Ivo
On 2014-01-29 11:29, Ivaylo Dimitrov wrote:
>
>
> On 29.01.2014 11:10, Tero Kristo wrote:
>
>>
>> It looks like the omap36xx version of the omap96m_alwon_fck is modelled
>> improperly in the dts files. I don't have access to omap36xx hardware
>> myself, but give a try for the following patch:
>>
>>
>
> It could be that 36xx omap96m_alwon_fck clock is wrongly modeled, but I
> am testing on 1) 3430es2 (Nokia N900) and 2) legacy boot, so I guess
> that patch won't help much (unless I am missing something and DT is used
> even with legacy boot and 36xx clocks are used on 3430es2)
I think Tero's reply was to Christoph. I believe the issues you see and
what Christoph sees are totally different.
Tomi
On 01/29/2014 11:38 AM, Tomi Valkeinen wrote:
> On 2014-01-29 11:29, Ivaylo Dimitrov wrote:
>>
>>
>> On 29.01.2014 11:10, Tero Kristo wrote:
>>
>>>
>>> It looks like the omap36xx version of the omap96m_alwon_fck is modelled
>>> improperly in the dts files. I don't have access to omap36xx hardware
>>> myself, but give a try for the following patch:
>>>
>>>
>>
>> It could be that 36xx omap96m_alwon_fck clock is wrongly modeled, but I
>> am testing on 1) 3430es2 (Nokia N900) and 2) legacy boot, so I guess
>> that patch won't help much (unless I am missing something and DT is used
>> even with legacy boot and 36xx clocks are used on 3430es2)
>
> I think Tero's reply was to Christoph. I believe the issues you see and
> what Christoph sees are totally different.
>
> Tomi
Oh yea sorry about the confusion, have too many separate issues listed
under this thread. :P That was definitely for Christoph.
For the DSS clk rate part, Tomi should answer that as it seems to come
from some display driver changes. This might be caused by the infamous
rounding issues with the clk_set_rate / clk_round_rate and the hackery
around it in display driver...
-Tero
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:
From: Tero Kristo <[email protected]>
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 <[email protected]>
---
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
On 2014-01-28 20:17, Ivaylo Dimitrov wrote:
>
>
> On 28.01.2014 10:48, Tomi Valkeinen wrote:
>
>> I made a somewhat hacky quickfix for beagle. Applying that and the
>> clk-divider from the link above makes things work for me. However, as I
>> said, the issue with n900 might be different, but it'd be interesting to
>> hear if it has any effect.
>>
>> Tomi
>>
>
> Applying those 2 patches doesn't help, still get exactly the same warning.
>
> Find attached my clk_summary (with my hacky patch applied, otherwise I
> cannot boot the device)
Can you try this one:
From e511789f7be00beeeee0712910c60a57c51b2705 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <[email protected]>
Date: Wed, 29 Jan 2014 13:28:53 +0200
Subject: [PATCH] clkoutx2 fix
---
arch/arm/mach-omap2/cclock3xxx_data.c | 7 +++++++
arch/arm/mach-omap2/dpll3xxx.c | 20 ++++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..49247701a56c 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -428,12 +428,19 @@ static const char *dpll4_m5x2_ck_parent_names[] = {
"dpll4_m5_ck",
};
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate);
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long target_rate,
+ unsigned long *parent_rate);
+
static const struct clk_ops dpll4_m5x2_ck_ops = {
.init = &omap2_init_clk_clkdm,
.enable = &omap2_dflt_clk_enable,
.disable = &omap2_dflt_clk_disable,
.is_enabled = &omap2_dflt_clk_is_enabled,
+ .set_rate = &omap3_clkoutx2_set_rate,
.recalc_rate = &omap3_clkoutx2_recalc,
+ .round_rate = &omap3_clkoutx2_round_rate,
};
static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3a0296cfcace..794665fe234b 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -669,6 +669,26 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
return rate;
}
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ return 0;
+}
+
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+ unsigned long best_parent;
+
+ best_parent = (rate / 2);
+ *prate = __clk_round_rate(__clk_get_parent(hw->clk),
+ best_parent);
+ }
+
+ return *prate * 2;
+}
+
/* OMAP3/4 non-CORE DPLL clkops */
const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
.allow_idle = omap3_dpll_allow_idle,
--
1.8.3.2
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 <[email protected]>
> 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 <[email protected]>
> ---
> 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
>
On 29.01.2014 13:30, Tomi Valkeinen wrote:
> On 2014-01-28 20:17, Ivaylo Dimitrov wrote:
>>
>>
>> On 28.01.2014 10:48, Tomi Valkeinen wrote:
>>
>>> I made a somewhat hacky quickfix for beagle. Applying that and the
>>> clk-divider from the link above makes things work for me. However, as I
>>> said, the issue with n900 might be different, but it'd be interesting to
>>> hear if it has any effect.
>>>
>>> Tomi
>>>
>>
>> Applying those 2 patches doesn't help, still get exactly the same warning.
>>
>> Find attached my clk_summary (with my hacky patch applied, otherwise I
>> cannot boot the device)
>
> Can you try this one:
>
> From e511789f7be00beeeee0712910c60a57c51b2705 Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <[email protected]>
> Date: Wed, 29 Jan 2014 13:28:53 +0200
> Subject: [PATCH] clkoutx2 fix
>
> ---
> arch/arm/mach-omap2/cclock3xxx_data.c | 7 +++++++
> arch/arm/mach-omap2/dpll3xxx.c | 20 ++++++++++++++++++++
> 2 files changed, 27 insertions(+)
>
Yep, that one fixes the problem. Thanks!
Now I only need to find why maemo is 10 times slower with linux-next
compared to 3.13-rc7, but that is another story :).
Ivo
On 01/29/2014 05:21 AM, 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):
To help us debug similar problems, I wrote a tool today:
https://github.com/nmenon/ctt-dump - it is a simple memory read utility,
Input file is CTT dump-out
For example: 3630 CTT is here:
http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip
to give an idea - i posted a screen shot here:
https://plus.google.com/112464029509057661457/posts/hNdee4gNfob
After generating the the rd1 file from CTT,
we pick up the registers using ctt-dump -> any tool which can do
register reads could do, but it might be handy having this.
Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium
importing it back into CTT and after setting up the correct sysclk, we
can compare clock frequencies Vs debugfs output - example:
http://slexy.org/view/s21iQyDTct
I mean, it is awesome having to debugfs data, but with nascent
systems, it is always good to compare to what the hardware is really
configured to - and CTT is the easy way to deal with it.
--
Regards,
Nishanth Menon
On 2014-01-29 20:52, Ivaylo Dimitrov wrote:
>> Can you try this one:
>>
>> From e511789f7be00beeeee0712910c60a57c51b2705 Mon Sep 17 00:00:00 2001
>> From: Tomi Valkeinen <[email protected]>
>> Date: Wed, 29 Jan 2014 13:28:53 +0200
>> Subject: [PATCH] clkoutx2 fix
>>
>> ---
>> arch/arm/mach-omap2/cclock3xxx_data.c | 7 +++++++
>> arch/arm/mach-omap2/dpll3xxx.c | 20 ++++++++++++++++++++
>> 2 files changed, 27 insertions(+)
>>
>
> Yep, that one fixes the problem. Thanks!
Ok, good. I'll probably do some studying about clk framework and clean
up the patch and post it.
Btw, the clkoutx2 fix makes the DSS clocks work for you generally, but
if you happen to hit clock rates that don't divide evenly, you may also
need the patches for clk-divider and dss I posted earlier.
> Now I only need to find why maemo is 10 times slower with linux-next
> compared to 3.13-rc7, but that is another story :).
I sure hope it's not DSS's doings =).
Tomi
On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote:
> To help us debug similar problems, I wrote a tool today:
> https://github.com/nmenon/ctt-dump - it is a simple memory read utility,
> Input file is CTT dump-out
> For example: 3630 CTT is here:
> http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip
>
> to give an idea - i posted a screen shot here:
> https://plus.google.com/112464029509057661457/posts/hNdee4gNfob
>
> After generating the the rd1 file from CTT,
> we pick up the registers using ctt-dump -> any tool which can do
> register reads could do, but it might be handy having this.
> Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium
> importing it back into CTT and after setting up the correct sysclk, we
> can compare clock frequencies Vs debugfs output - example:
> http://slexy.org/view/s21iQyDTct
>
>
> I mean, it is awesome having to debugfs data, but with nascent
> systems, it is always good to compare to what the hardware is really
> configured to - and CTT is the easy way to deal with it.
Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on
this hardware here (omap3-lil-a83x). Its corresponding rd1 file,
generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware
has a 26 Mhz crystal.
The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE
right. 0x2 is CM_96M_FCLK not CORE_CLK for example.
This is the diff of clk registers before and after DT clock
conversion patches:
--- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1
+++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01
@@ -22,23 +22,23 @@
0x48004c10 0x0000002f
0x48004c30 0x0000023f
0x48004c40 0x00000014
-0x48004d00 0x10370037
+0x48004d00 0xf0371037
0x48004d04 0x00000017
0x48004d40 0x09900c00
0x48004d44 0x0483600c
0x48004d48 0x00000009
0x48004d4c 0x0000780c
0x48004d50 0x00000001
-0x48004d70 0x00000092
-0x48004e00 0x00000001
+0x48004d70 0x0000009a
+0x48004e00 0x00000000
0x48004e10 0x00000001
0x48004e30 0x00000001
-0x48004e40 0x0000100f
+0x48004e40 0x00001009
0x48004f00 0x00000000
0x48004f10 0x00000000
0x48004f30 0x00000001
0x48004f40 0x00000004
-0x48005000 0x00040800
+0x48005000 0x00000800
0x48005010 0x00078fff
0x48005030 0x0007ffff
0x48005040 0x000000ff
Thanks
-- Christoph
On Wed, Jan 29, 2014 at 04:57:00PM +0200, Tero Kristo wrote:
>
> 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.
Hmm, doesn't change anything here.
Thanks
-- Christoph
On Sat, 2014-02-01 at 19:52 +0100, Christoph Fritz wrote:
> On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote:
> > To help us debug similar problems, I wrote a tool today:
> > https://github.com/nmenon/ctt-dump - it is a simple memory read utility,
> > Input file is CTT dump-out
> > For example: 3630 CTT is here:
> > http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip
> >
> > to give an idea - i posted a screen shot here:
> > https://plus.google.com/112464029509057661457/posts/hNdee4gNfob
> >
> > After generating the the rd1 file from CTT,
> > we pick up the registers using ctt-dump -> any tool which can do
> > register reads could do, but it might be handy having this.
> > Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium
> > importing it back into CTT and after setting up the correct sysclk, we
> > can compare clock frequencies Vs debugfs output - example:
> > http://slexy.org/view/s21iQyDTct
> >
> >
> > I mean, it is awesome having to debugfs data, but with nascent
> > systems, it is always good to compare to what the hardware is really
> > configured to - and CTT is the easy way to deal with it.
>
> Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on
> this hardware here (omap3-lil-a83x). Its corresponding rd1 file,
> generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware
> has a 26 Mhz crystal.
>
> The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE
> right. 0x2 is CM_96M_FCLK not CORE_CLK for example.
>
>
> This is the diff of clk registers before and after DT clock
> conversion patches:
>
> --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1
> +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01
> @@ -22,23 +22,23 @@
> 0x48004c10 0x0000002f
> 0x48004c30 0x0000023f
> 0x48004c40 0x00000014
> -0x48004d00 0x10370037
> +0x48004d00 0xf0371037
> 0x48004d04 0x00000017
> 0x48004d40 0x09900c00
> 0x48004d44 0x0483600c
> 0x48004d48 0x00000009
> 0x48004d4c 0x0000780c
> 0x48004d50 0x00000001
> -0x48004d70 0x00000092
> -0x48004e00 0x00000001
> +0x48004d70 0x0000009a
> +0x48004e00 0x00000000
> 0x48004e10 0x00000001
> 0x48004e30 0x00000001
> -0x48004e40 0x0000100f
> +0x48004e40 0x00001009
> 0x48004f00 0x00000000
> 0x48004f10 0x00000000
> 0x48004f30 0x00000001
> 0x48004f40 0x00000004
> -0x48005000 0x00040800
> +0x48005000 0x00000800
> 0x48005010 0x00078fff
> 0x48005030 0x0007ffff
> 0x48005040 0x000000ff
Origin files of this diff added as attachment to this mail.
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.
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)?
From: Tero Kristo <[email protected]>
Date: Tue, 4 Feb 2014 17:37:37 +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 <[email protected]>
---
arch/arm/boot/dts/omap36xx-clocks.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi
b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 2fcf253..24869cb 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -70,6 +70,10 @@
};
};
+&omap_96m_alwon_fck {
+ clock-div = <2>;
+};
+
&cm_clockdomains {
dpll4_clkdm: dpll4_clkdm {
compatible = "ti,clockdomain";
--
1.7.9.5
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 <[email protected]>
Below is my clock fix for dss:
>From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001
From: Christoph Fritz <[email protected]>
Date: Fri, 7 Feb 2014 10:51:15 +0100
Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree
OMAP36xx has different hardware implementation for the dpll4_m4_ck tree
compared to other OMAP3 variants. Reflect this properly in the dts file.
before omap dt clock conversion:
dpll4_m4_ck 1 1 57600000
dpll4_m4x2_ck 1 1 57600000
dss1_alwon_fck_3430es2 2 4 57600000
after omap dt clock conversion:
dpll4_m4_ck 0 1 96000000 0
dpll4_m4x2_mul_ck 0 1 192000000 0
dpll4_m4x2_ck 0 1 192000000 0
dss1_alwon_fck_3430es2 0 4 192000000 0
with this patch:
dpll4_m4_ck 1 1 57600000 0
dss1_alwon_fck_3430es2 2 4 57600000 0
dpll4_m4x2_mul_ck 0 0 115200000 0
dpll4_m4x2_ck 0 0 115200000 0
Signed-off-by: Christoph Fritz <[email protected]>
---
arch/arm/boot/dts/omap36xx-clocks.dtsi | 8 ++++++++
arch/arm/boot/dts/omap36xx.dtsi | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 24869cb..8ac8926 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -74,6 +74,14 @@
clock-div = <2>;
};
+&dpll4_m4_ck {
+ clock-div = <15>;
+};
+
+&dss1_alwon_fck_3430es2 {
+ clocks = <&dpll4_m4_ck>;
+};
+
&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 7e8dee9..5e1bcd0 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.7.10.4
Hi,
On 07/02/14 12:12, Christoph Fritz wrote:
> Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want,
> you can add my:
> Tested-by: Christoph Fritz <[email protected]>
>
> Below is my clock fix for dss:
>
> From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001
> From: Christoph Fritz <[email protected]>
> Date: Fri, 7 Feb 2014 10:51:15 +0100
> Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree
>
> OMAP36xx has different hardware implementation for the dpll4_m4_ck tree
> compared to other OMAP3 variants. Reflect this properly in the dts file.
I rebased the DSS DT branch on top of v3.14-rc1, and I'm trying to get
beagle-xM working. Pinmuxing was wrong, but after fixing that, the
clk_set_rate for dss fclk failed. I applied Tero's and your patches, but
now when starting omapdss I see:
[ 19.704193] omap clock: module associated with clock
dss1_alwon_fck_3430es2 didn't enable in 1000
00 tries
I wonder if I'm still missing some patch?
Tomi
On Fri, 2014-02-07 at 15:49 +0200, Tomi Valkeinen wrote:
> On 07/02/14 12:12, Christoph Fritz wrote:
>
> > Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want,
> > you can add my:
> > Tested-by: Christoph Fritz <[email protected]>
> >
> > Below is my clock fix for dss:
> >
> > From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001
> > From: Christoph Fritz <[email protected]>
> > Date: Fri, 7 Feb 2014 10:51:15 +0100
> > Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree
> >
> > OMAP36xx has different hardware implementation for the dpll4_m4_ck tree
> > compared to other OMAP3 variants. Reflect this properly in the dts file.
>
> I rebased the DSS DT branch on top of v3.14-rc1, and I'm trying to get
> beagle-xM working. Pinmuxing was wrong, but after fixing that, the
> clk_set_rate for dss fclk failed. I applied Tero's and your patches, but
> now when starting omapdss I see:
>
> [ 19.704193] omap clock: module associated with clock
> dss1_alwon_fck_3430es2 didn't enable in 1000
> 00 tries
>
> I wonder if I'm still missing some patch?
Is beagle-xM using DSI? Because here the LILLY-A83X board is not. The
clock registers are all fine now as before the dt clock conversion
patches.
I suppose you are using current linus tree. I tested 'next' but didn't
get DSS working. I guessed that it would have something to do with early
DSS DT integration issues.
I'll rebase my current dt board support patchset for LILLY-A83X to
current linus tree and investigate DSS further.
Thanks
-- Christoph
On 10/02/14 22:54, Christoph Fritz wrote:
>> I wonder if I'm still missing some patch?
>
> Is beagle-xM using DSI? Because here the LILLY-A83X board is not. The
> clock registers are all fine now as before the dt clock conversion
> patches.
No, Beagle xM doesn't use DSI, plain DPI.
Tomi
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 <[email protected]>
>
> Below is my clock fix for dss:
>
> From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001
> From: Christoph Fritz <[email protected]>
> 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?
Tomi
From ab29f9a3a43d95cdf06421bd9f29c4d7418f37de Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <[email protected]>
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
Hi Tomi,
On Wed, Feb 12, 2014 at 2:18 PM, Tomi Valkeinen <[email protected]> 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 <[email protected]>
>>
>> Below is my clock fix for dss:
>>
>> From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001
>> From: Christoph Fritz <[email protected]>
>> 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 <[email protected]>
> 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
On 12/02/14 15:18, Tomi Valkeinen wrote:
> 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?
Aaand the hack patch I sent is crap... We can't skip the x2 clock path,
as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is
present on 3630 also.
I think the best and simplest way to fix this is by setting the
multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I
didn't think of it yesterday.
I have a bunch of other patches needed to get the clocks right, so I'll
send a series separately a bit later today.
Tomi
On 13/02/14 11:03, Tomi Valkeinen wrote:
> On 12/02/14 15:18, Tomi Valkeinen wrote:
>
>> 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?
>
> Aaand the hack patch I sent is crap... We can't skip the x2 clock path,
> as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is
> present on 3630 also.
>
> I think the best and simplest way to fix this is by setting the
> multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I
> didn't think of it yesterday.
>
> I have a bunch of other patches needed to get the clocks right, so I'll
> send a series separately a bit later today.
I just sent the "OMAP: OMAP3 DSS related clock patches" series to l-o
and arm lists, which hopefully solves issues discussed in this thread.
Tomi
On Thu, 2014-02-13 at 12:05 +0200, Tomi Valkeinen wrote:
> On 13/02/14 11:03, Tomi Valkeinen wrote:
> > On 12/02/14 15:18, Tomi Valkeinen wrote:
> >
> >> 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?
> >
> > Aaand the hack patch I sent is crap... We can't skip the x2 clock path,
> > as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is
> > present on 3630 also.
> >
> > I think the best and simplest way to fix this is by setting the
> > multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I
> > didn't think of it yesterday.
> >
> > I have a bunch of other patches needed to get the clocks right, so I'll
> > send a series separately a bit later today.
>
> I just sent the "OMAP: OMAP3 DSS related clock patches" series to l-o
> and arm lists, which hopefully solves issues discussed in this thread.
Yes, thanks Tomi. I tested your patch series on a83x board. 96m clock
and DSS-clocks are fine now. If you want, you can add my:
Tested-by: Christoph Fritz <[email protected]>
to your series "OMAP: OMAP3 DSS related clock patches".
The only issue left on current mainline for a83x board is that twl4030
(tps65920) doesn't set VIO as on next-20140120.
Thanks
-- Christoph