* [BISECTED] OMAP: DSS: clk rate mismatch
@ 2014-01-27 17:30 Ivaylo Dimitrov
2014-01-27 18:41 ` Christoph Fritz
2014-01-28 7:50 ` [BISECTED] OMAP: DSS: clk rate mismatch Tomi Valkeinen
0 siblings, 2 replies; 33+ messages in thread
From: Ivaylo Dimitrov @ 2014-01-27 17:30 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-kernel, pali.rohar, pavel
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
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
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 7:50 ` [BISECTED] OMAP: DSS: clk rate mismatch Tomi Valkeinen
1 sibling, 1 reply; 33+ messages in thread
From: Christoph Fritz @ 2014-01-27 18:41 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: tomi.valkeinen, linux-omap, linux-kernel, pali.rohar, pavel,
Tero Kristo, Nishanth Menon
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-27 17:30 [BISECTED] OMAP: DSS: clk rate mismatch Ivaylo Dimitrov
2014-01-27 18:41 ` Christoph Fritz
@ 2014-01-28 7:50 ` Tomi Valkeinen
2014-01-28 8:48 ` Tomi Valkeinen
1 sibling, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-01-28 7:50 UTC (permalink / raw)
To: Ivaylo Dimitrov; +Cc: linux-omap, linux-kernel, pali.rohar, pavel
[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]
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/1383736008-22764-1-git-send-email-tomi.valkeinen@ti.com
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
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
0 siblings, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-01-28 8:48 UTC (permalink / raw)
To: Ivaylo Dimitrov; +Cc: linux-omap, linux-kernel, pali.rohar, pavel
[-- Attachment #1.1: Type: text/plain, Size: 1372 bytes --]
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/1383736008-22764-1-git-send-email-tomi.valkeinen@ti.com
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-OMAPDSS-DSS-fclk-rate-rounding-test.patch --]
[-- Type: text/x-diff; name="0001-OMAPDSS-DSS-fclk-rate-rounding-test.patch", Size: 1144 bytes --]
From f633a151a01b06a7b86107d93f9f53e05601c02c Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Tue, 28 Jan 2014 10:19:07 +0200
Subject: [PATCH] OMAPDSS: DSS: fclk rate rounding test
---
drivers/video/omap2/dss/dss.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 9009f62defd0..de35be6d6e20 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -473,8 +473,22 @@ bool dss_div_calc(unsigned long pck, unsigned long fck_min,
fckd_stop = max(DIV_ROUND_UP(prate * m, fck_hw_max), 1ul);
for (fckd = fckd_start; fckd >= fckd_stop; --fckd) {
+ unsigned long rfclk;
fck = prate / fckd * m;
+ /* do we get the right rate with this? */
+ rfclk = clk_round_rate(dss.dss_clk, fck);
+
+ if (rfclk != fck) {
+ /* no we don't. try rounding the other way */
+ fck += 1;
+
+ rfclk = clk_round_rate(dss.dss_clk, fck);
+
+ if (rfclk != fck)
+ DSSERR("mismatch %lu != %lu\n", rfclk, fck);
+ }
+
if (func(fck, data))
return true;
}
--
1.8.3.2
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-27 18:41 ` Christoph Fritz
@ 2014-01-28 9:04 ` Tomi Valkeinen
2014-01-28 9:35 ` Christoph Fritz
0 siblings, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-01-28 9:04 UTC (permalink / raw)
To: Christoph Fritz
Cc: Ivaylo Dimitrov, linux-omap, linux-kernel, pali.rohar, pavel,
Tero Kristo, Nishanth Menon
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-28 9:04 ` Tomi Valkeinen
@ 2014-01-28 9:35 ` Christoph Fritz
2014-01-28 9:48 ` Tomi Valkeinen
0 siblings, 1 reply; 33+ messages in thread
From: Christoph Fritz @ 2014-01-28 9:35 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Ivaylo Dimitrov, linux-omap, linux-kernel, pali.rohar, pavel,
Tero Kristo, Nishanth Menon
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-28 9:35 ` Christoph Fritz
@ 2014-01-28 9:48 ` Tomi Valkeinen
2014-01-28 13:40 ` Tero Kristo
0 siblings, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-01-28 9:48 UTC (permalink / raw)
To: Christoph Fritz
Cc: Ivaylo Dimitrov, linux-omap, linux-kernel, pali.rohar, pavel,
Tero Kristo, Nishanth Menon
[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-28 9:48 ` Tomi Valkeinen
@ 2014-01-28 13:40 ` Tero Kristo
2014-01-28 17:02 ` Christoph Fritz
0 siblings, 1 reply; 33+ messages in thread
From: Tero Kristo @ 2014-01-28 13:40 UTC (permalink / raw)
To: Tomi Valkeinen, Christoph Fritz
Cc: Ivaylo Dimitrov, linux-omap, linux-kernel, pali.rohar, pavel,
Nishanth Menon
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
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
0 siblings, 1 reply; 33+ messages in thread
From: Christoph Fritz @ 2014-01-28 17:02 UTC (permalink / raw)
To: Tero Kristo
Cc: Tomi Valkeinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
[-- Attachment #1: Type: text/plain, Size: 6172 bytes --]
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 <chf.fritz@googlemail.com>
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
[-- Attachment #2: clk_summary__next-20140115__works_as_expected.txt --]
[-- Type: text/plain, Size: 14779 bytes --]
clock enable_cnt prepare_cnt rate
---------------------------------------------------------------------
secure_32k_fck 0 1 32768
wdt1_fck 0 0 32768
gpt12_fck 0 1 32768
mcbsp_clks 0 5 0
sys_altclk 0 0 0
virt_38_4m_ck 0 0 38400000
virt_26000000_ck 1 1 26000000
osc_sys_ck 1 1 26000000
sys_clkout1 0 0 26000000
sys_ck 4 18 13000000
traceclk_src_fck 0 0 13000000
traceclk_fck 0 0 13000000
emu_src_ck 0 1 13000000
atclk_fck 0 0 13000000
pclkx2_fck 0 0 13000000
pclk_fck 0 0 6500000
gpt9_fck 0 1 13000000
gpt8_fck 0 1 13000000
gpt7_fck 0 1 13000000
gpt6_fck 0 1 13000000
gpt5_fck 0 1 13000000
gpt4_fck 0 1 13000000
gpt3_fck 0 1 13000000
gpt2_fck 0 1 13000000
dss2_alwon_fck 0 2 13000000
dpll4_ck 2 3 864000000
dpll4_m6_ck 0 0 288000000
dpll4_m6x2_ck 0 0 288000000
emu_per_alwon_ck 0 0 288000000
dpll4_m5_ck 0 0 216000000
dpll4_m5x2_ck 0 0 216000000
cam_mclk 0 0 216000000
dpll4_m4_ck 1 1 57600000
dpll4_m4x2_ck 1 1 57600000
dss1_alwon_fck_3430es2 2 4 57600000
dpll4_m3_ck 0 1 54000000
dpll4_m3x2_ck 0 1 54000000
omap_54m_fck 0 1 54000000
dss_tv_fck 0 2 54000000
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
omap_48m_fck 3 4 48000000
per_48m_fck 2 2 48000000
uart3_fck 1 1 48000000
uart4_fck 1 1 48000000
core_48m_fck 2 6 48000000
uart1_fck 1 1 48000000
uart2_fck 1 1 48000000
mcspi1_fck 0 1 48000000
mcspi2_fck 0 1 48000000
mcspi3_fck 0 1 48000000
mcspi4_fck 0 1 48000000
omap_12m_fck 0 1 12000000
core_12m_fck 0 1 12000000
hdq_fck 0 1 12000000
usbhost_48m_fck 1 1 48000000
omap_96m_fck 0 2 96000000
dss_96m_fck 0 2 96000000
core_96m_fck 0 10 96000000
mcbsp1_fck 0 1 96000000
mcbsp5_fck 0 1 96000000
i2c1_fck 0 1 96000000
i2c2_fck 0 1 96000000
i2c3_fck 0 1 96000000
mmchs1_fck 0 1 96000000
mmchs2_fck 0 1 96000000
csi2_96m_fck 0 0 96000000
mspro_fck 0 0 96000000
mmchs3_fck 0 1 96000000
dpll4_x2_ck 0 0 1728000000
dpll3_ck 1 1 400000000
dpll3_m3_ck 0 0 200000000
dpll3_m3x2_ck 0 0 400000000
emu_core_alwon_ck 0 0 400000000
dpll3_m2_ck 1 1 400000000
dpll3_m2x2_ck 0 0 800000000
corex2_fck 0 0 800000000
ssi_ssr_fck_3430es2 0 0 266666666
ssi_sst_fck_3430es2 0 0 133333333
core_ck 1 1 400000000
l3_ick 2 3 200000000
core_l3_ick 8 10 200000000
gpmc_fck 2 2 200000000
sdrc_ick 1 1 200000000
hsotgusb_ick_3430es2 0 1 200000000
l4_ick 6 7 100000000
per_l4_ick 16 18 100000000
mcbsp4_ick 2 2 100000000
mcbsp3_ick 2 2 100000000
mcbsp2_ick 1 1 100000000
gpt2_ick 1 1 100000000
gpt3_ick 1 1 100000000
gpt4_ick 1 1 100000000
gpt5_ick 1 1 100000000
gpt6_ick 1 1 100000000
gpt7_ick 1 1 100000000
gpt8_ick 1 1 100000000
gpt9_ick 1 1 100000000
uart4_ick 1 1 100000000
uart3_ick 1 1 100000000
wdt3_ick 0 0 100000000
gpio2_ick 0 1 100000000
gpio3_ick 0 1 100000000
gpio4_ick 1 1 100000000
gpio5_ick 1 1 100000000
gpio6_ick 1 1 100000000
core_l4_ick 21 23 100000000
omapctrl_ick 1 1 100000000
mcbsp1_ick 1 1 100000000
mcbsp5_ick 1 1 100000000
gpt10_ick 1 1 100000000
gpt11_ick 1 1 100000000
uart1_ick 1 1 100000000
uart2_ick 1 1 100000000
i2c1_ick 1 1 100000000
i2c2_ick 1 1 100000000
i2c3_ick 1 1 100000000
mcspi1_ick 1 1 100000000
mcspi2_ick 1 1 100000000
mcspi3_ick 1 1 100000000
mcspi4_ick 1 1 100000000
hdq_ick 0 1 100000000
mmchs1_ick 1 1 100000000
mmchs2_ick 1 1 100000000
icr_ick 0 0 100000000
aes2_ick 1 2 100000000
sha12_ick 1 2 100000000
des2_ick 0 0 100000000
mspro_ick 0 0 100000000
mailboxes_ick 0 1 100000000
usbtll_ick 1 1 100000000
mmchs3_ick 1 1 100000000
rm_ick 0 0 50000000
cam_ick 0 1 100000000
ssi_l4_ick 0 0 100000000
ssi_ick_3430es2 0 0 100000000
sr_l4_ick 2 2 100000000
security_l4_ick2 0 0 100000000
aes1_ick 0 0 100000000
rng_ick 0 0 100000000
sha11_ick 0 0 100000000
des1_ick 0 0 100000000
dss_ick_3430es2 4 6 100000000
usbhost_ick 1 1 100000000
security_l3_ick 0 0 200000000
pka_ick 0 0 200000000
sad2d_ick 0 1 200000000
mad2d_ick 0 0 200000000
sgx_ick 0 0 200000000
dpll1_fck 0 0 200000000
dpll2_fck 0 0 400000000
sgx_fck 0 0 200000000
dpll3_x2_ck 0 0 800000000
dpll1_ck 0 1 600000000
dpll1_x2_ck 0 1 1200000000
dpll1_x2m2_ck 0 1 1200000000
mpu_ck 0 1 1200000000
emu_mpu_alwon_ck 0 0 1200000000
arm_fck 0 1 600000000
usim_fck 0 0 6500000
sr1_fck 0 1 13000000
sr2_fck 0 1 13000000
wkup_l4_ick 5 5 13000000
gpt1_ick 1 1 13000000
gpt12_ick 1 1 13000000
omap_32ksync_ick 1 1 13000000
gpio1_ick 1 1 13000000
wdt1_ick 0 0 13000000
wdt2_ick 1 1 13000000
usim_ick 0 0 13000000
modem_fck 0 0 13000000
dpll2_ck 0 1 260000000
dpll2_m2_ck 0 1 260000000
iva2_ck 0 1 260000000
dpll5_ck 1 1 120000000
dpll5_m2_ck 2 2 120000000
usbhost_120m_fck 1 2 120000000
usbtll_fck 1 1 120000000
cpefuse_fck 0 0 13000000
virt_19200000_ck 0 0 19200000
virt_13m_ck 0 0 13000000
virt_12m_ck 0 0 12000000
omap_32k_fck 2 8 32768
gpt1_fck 1 1 32768
per_32k_alwon_fck 0 5 32768
wdt3_fck 0 0 32768
gpio2_dbck 0 1 32768
gpio3_dbck 0 1 32768
gpio4_dbck 0 1 32768
gpio5_dbck 0 1 32768
gpio6_dbck 0 1 32768
wkup_32k_fck 1 3 32768
wdt2_fck 0 1 32768
gpio1_dbck 0 1 32768
gpt11_fck 0 1 32768
gpt10_fck 0 1 32768
ts_fck 0 0 32768
dummy_apb_pclk 0 0 0
virt_16_8m_ck 0 0 16800000
dummy_clk 0 0 0
[-- Attachment #3: clk_summary__next-20140124__sysclkout2_dss_fails.txt --]
[-- Type: text/plain, Size: 16501 bytes --]
clock enable_cnt prepare_cnt rate
------------------------------------------------------------------
secure_32k_fck 0 1 32768
wdt1_fck 0 0 32768
gpt12_fck 0 1 32768
dummy_ck 0 0 0
mcbsp_clks 0 5 0
sys_altclk 0 0 0
virt_38_4m_ck 0 0 38400000
virt_26000000_ck 1 1 26000000
osc_sys_ck 1 1 26000000
sys_clkout1 0 0 26000000
sys_ck 4 18 13000000
cpefuse_fck 0 0 13000000
dpll5_ck 1 1 120000000
dpll5_m2_ck 2 2 120000000
usbhost_120m_fck 1 2 120000000
usbtll_fck 1 1 120000000
dpll5_m2_d4_ck 0 0 30000000
dpll5_m2_d8_ck 0 0 15000000
dpll5_m2_d16_ck 0 0 7500000
dpll5_m2_d20_ck 0 0 6000000
sys_d2_ck 0 0 6500000
usim_fck 0 0 6500000
modem_fck 0 0 13000000
dpll2_ck 0 1 260000000
dpll2_m2_ck 0 1 260000000
iva2_ck 0 1 260000000
sr2_fck 0 1 13000000
sr1_fck 0 1 13000000
traceclk_src_fck 0 0 13000000
traceclk_fck 0 0 13000000
emu_src_mux_ck 0 1 13000000
emu_src_ck 0 1 13000000
atclk_fck 0 0 13000000
pclkx2_fck 0 0 13000000
pclk_fck 0 0 6500000
gpt9_fck 0 1 13000000
gpt8_fck 0 1 13000000
gpt7_fck 0 1 13000000
gpt6_fck 0 1 13000000
gpt5_fck 0 1 13000000
gpt4_fck 0 1 13000000
gpt3_fck 0 1 13000000
gpt2_fck 0 1 13000000
dss2_alwon_fck 0 2 13000000
dpll1_ck 0 1 600000000
dpll1_x2_ck 0 1 1200000000 0
dpll1_x2m2_ck 0 1 1200000000 0
mpu_ck 0 1 1200000000 0
emu_mpu_alwon_ck 0 0 1200000000 0
arm_fck 0 1 600000000
dpll3_ck 1 1 400000000
dpll3_m2_ck 1 1 400000000
core_ck 1 1 400000000
core_d2_ck 0 0 200000000
sgx_fck 0 0 200000000
core_d6_ck 0 0 66666666
core_d4_ck 0 0 100000000
core_d3_ck 0 0 133333333
dpll2_fck 0 0 400000000
l3_ick 2 3 200000000
sgx_ick 0 0 200000000
mad2d_ick 0 0 200000000
sad2d_ick 0 1 200000000
security_l3_ick 0 0 200000000
pka_ick 0 0 200000000
core_l3_ick 8 10 200000000
hsotgusb_ick_3430es2 0 1 200000000
gpmc_fck 2 2 200000000
sdrc_ick 1 1 200000000
l4_ick 6 7 100000000
usbhost_ick 1 1 100000000
dss_ick_3430es2 4 6 100000000
sr_l4_ick 2 2 100000000
ssi_l4_ick 0 0 100000000
ssi_ick_3430es2 0 0 100000000
cam_ick 0 1 100000000
security_l4_ick2 0 0 100000000
des1_ick 0 0 100000000
sha11_ick 0 0 100000000
rng_ick 0 0 100000000
aes1_ick 0 0 100000000
per_l4_ick 16 18 100000000
mcbsp4_ick 2 2 100000000
mcbsp3_ick 2 2 100000000
mcbsp2_ick 1 1 100000000
gpt2_ick 1 1 100000000
gpt3_ick 1 1 100000000
gpt4_ick 1 1 100000000
gpt5_ick 1 1 100000000
gpt6_ick 1 1 100000000
gpt7_ick 1 1 100000000
gpt8_ick 1 1 100000000
gpt9_ick 1 1 100000000
uart4_ick 1 1 100000000
uart3_ick 1 1 100000000
wdt3_ick 0 0 100000000
gpio2_ick 0 1 100000000
gpio3_ick 0 1 100000000
gpio4_ick 1 1 100000000
gpio5_ick 1 1 100000000
gpio6_ick 1 1 100000000
core_l4_ick 21 23 100000000
mmchs3_ick 1 1 100000000
usbtll_ick 1 1 100000000
mailboxes_ick 0 1 100000000
mspro_ick 0 0 100000000
des2_ick 0 0 100000000
icr_ick 0 0 100000000
sha12_ick 1 2 100000000
aes2_ick 1 2 100000000
omapctrl_ick 1 1 100000000
mcbsp1_ick 1 1 100000000
mcbsp5_ick 1 1 100000000
gpt10_ick 1 1 100000000
gpt11_ick 1 1 100000000
uart1_ick 1 1 100000000
uart2_ick 1 1 100000000
i2c1_ick 1 1 100000000
i2c2_ick 1 1 100000000
i2c3_ick 1 1 100000000
mcspi1_ick 1 1 100000000
mcspi2_ick 1 1 100000000
mcspi3_ick 1 1 100000000
mcspi4_ick 1 1 100000000
hdq_ick 0 1 100000000
mmchs1_ick 1 1 100000000
mmchs2_ick 1 1 100000000
rm_ick 0 0 50000000
dpll1_fck 0 0 200000000
dpll3_m2x2_ck 0 0 800000000
corex2_fck 0 0 800000000
ssi_ssr_fck_3430es2 0 0 266666666
ssi_sst_fck_3430es2 0 0 133333333
corex2_d5_fck 0 0 160000000
corex2_d3_fck 0 0 266666666
dpll3_m3_ck 0 0 200000000
dpll3_m3x2_mul_ck 0 0 400000000
dpll3_m3x2_ck 0 0 400000000
emu_core_alwon_ck 0 0 400000000
dpll3_x2_ck 0 0 800000000
dpll4_ck 1 3 864000000
dpll4_m6_ck 0 0 288000000
dpll4_m6x2_mul_ck 0 0 576000000
dpll4_m6x2_ck 0 0 576000000
emu_per_alwon_ck 0 0 576000000
dpll4_m5_ck 0 0 216000000
dpll4_m5x2_mul_ck 0 0 432000000
dpll4_m5x2_ck 0 0 432000000
cam_mclk 0 0 432000000
dpll4_m4_ck 0 1 96000000
dpll4_m4x2_mul_ck 0 1 192000000
dpll4_m4x2_ck 0 1 192000000
dss1_alwon_fck_3430es2 0 4 192000000
dpll4_m3_ck 0 1 54000000
dpll4_m3x2_mul_ck 0 1 108000000
dpll4_m3x2_ck 0 1 108000000
omap_54m_fck 0 1 108000000
dss_tv_fck 0 2 108000000
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
cm_96m_d2_fck 1 1 96000000
omap_48m_fck 3 4 96000000
usbhost_48m_fck 1 1 96000000
per_48m_fck 1 2 96000000
uart4_fck 0 1 96000000
uart3_fck 1 1 96000000
core_48m_fck 2 6 96000000
uart1_fck 1 1 96000000
uart2_fck 1 1 96000000
mcspi1_fck 0 1 96000000
mcspi2_fck 0 1 96000000
mcspi3_fck 0 1 96000000
mcspi4_fck 0 1 96000000
omap_12m_fck 0 1 24000000
core_12m_fck 0 1 24000000
hdq_fck 0 1 24000000
omap_96m_fck 0 2 192000000
omap_96m_d10_fck 0 0 19200000
omap_96m_d8_fck 0 0 24000000
omap_96m_d4_fck 0 0 48000000
omap_96m_d2_fck 0 0 96000000
dss_96m_fck 0 2 192000000
core_96m_fck 0 10 192000000
mcbsp1_fck 0 1 192000000
mcbsp5_fck 0 1 192000000
mmchs3_fck 0 1 192000000
mspro_fck 0 0 192000000
csi2_96m_fck 0 0 192000000
i2c1_fck 0 1 192000000
i2c2_fck 0 1 192000000
i2c3_fck 0 1 192000000
mmchs1_fck 0 1 192000000
mmchs2_fck 0 1 192000000
dpll4_x2_ck 0 0 1728000000 0
wkup_l4_ick 5 5 13000000
usim_ick 0 0 13000000
gpt1_ick 1 1 13000000
gpt12_ick 1 1 13000000
omap_32ksync_ick 1 1 13000000
gpio1_ick 1 1 13000000
wdt1_ick 0 0 13000000
wdt2_ick 1 1 13000000
virt_19200000_ck 0 0 19200000
virt_13m_ck 0 0 13000000
virt_12m_ck 0 0 12000000
omap_32k_fck 2 8 32768
gpt1_fck 1 1 32768
ts_fck 0 0 32768
per_32k_alwon_fck 0 5 32768
wdt3_fck 0 0 32768
gpio2_dbck 0 1 32768
gpio3_dbck 0 1 32768
gpio4_dbck 0 1 32768
gpio5_dbck 0 1 32768
gpio6_dbck 0 1 32768
wkup_32k_fck 1 3 32768
wdt2_fck 0 1 32768
gpio1_dbck 0 1 32768
gpt11_fck 0 1 32768
gpt10_fck 0 1 32768
dummy_apb_pclk 0 0 0
virt_16_8m_ck 0 0 16800000
[-- Attachment #4: clk_summary_diff.txt --]
[-- Type: text/plain, Size: 22756 bytes --]
--- clk_summary__next-20140115__works_as_expected.txt 2014-01-28 16:44:07.226039395 +0100
+++ clk_summary__next-20140124__sysclkout2_dss_fails.txt 2014-01-28 16:44:00.596273550 +0100
@@ -1,8 +1,9 @@
clock enable_cnt prepare_cnt rate
----------------------------------------------------------------------
+------------------------------------------------------------------
secure_32k_fck 0 1 32768
wdt1_fck 0 0 32768
gpt12_fck 0 1 32768
+ dummy_ck 0 0 0
mcbsp_clks 0 5 0
sys_altclk 0 0 0
virt_38_4m_ck 0 0 38400000
@@ -10,12 +11,30 @@
osc_sys_ck 1 1 26000000
sys_clkout1 0 0 26000000
sys_ck 4 18 13000000
+ cpefuse_fck 0 0 13000000
+ dpll5_ck 1 1 120000000
+ dpll5_m2_ck 2 2 120000000
+ usbhost_120m_fck 1 2 120000000
+ usbtll_fck 1 1 120000000
+ dpll5_m2_d4_ck 0 0 30000000
+ dpll5_m2_d8_ck 0 0 15000000
+ dpll5_m2_d16_ck 0 0 7500000
+ dpll5_m2_d20_ck 0 0 6000000
+ sys_d2_ck 0 0 6500000
+ usim_fck 0 0 6500000
+ modem_fck 0 0 13000000
+ dpll2_ck 0 1 260000000
+ dpll2_m2_ck 0 1 260000000
+ iva2_ck 0 1 260000000
+ sr2_fck 0 1 13000000
+ sr1_fck 0 1 13000000
traceclk_src_fck 0 0 13000000
traceclk_fck 0 0 13000000
- emu_src_ck 0 1 13000000
- atclk_fck 0 0 13000000
- pclkx2_fck 0 0 13000000
- pclk_fck 0 0 6500000
+ emu_src_mux_ck 0 1 13000000
+ emu_src_ck 0 1 13000000
+ atclk_fck 0 0 13000000
+ pclkx2_fck 0 0 13000000
+ pclk_fck 0 0 6500000
gpt9_fck 0 1 13000000
gpt8_fck 0 1 13000000
gpt7_fck 0 1 13000000
@@ -25,76 +44,43 @@
gpt3_fck 0 1 13000000
gpt2_fck 0 1 13000000
dss2_alwon_fck 0 2 13000000
- dpll4_ck 2 3 864000000
- dpll4_m6_ck 0 0 288000000
- dpll4_m6x2_ck 0 0 288000000
- emu_per_alwon_ck 0 0 288000000
- dpll4_m5_ck 0 0 216000000
- dpll4_m5x2_ck 0 0 216000000
- cam_mclk 0 0 216000000
- dpll4_m4_ck 1 1 57600000
- dpll4_m4x2_ck 1 1 57600000
- dss1_alwon_fck_3430es2 2 4 57600000
- dpll4_m3_ck 0 1 54000000
- dpll4_m3x2_ck 0 1 54000000
- omap_54m_fck 0 1 54000000
- dss_tv_fck 0 2 54000000
- 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
- omap_48m_fck 3 4 48000000
- per_48m_fck 2 2 48000000
- uart3_fck 1 1 48000000
- uart4_fck 1 1 48000000
- core_48m_fck 2 6 48000000
- uart1_fck 1 1 48000000
- uart2_fck 1 1 48000000
- mcspi1_fck 0 1 48000000
- mcspi2_fck 0 1 48000000
- mcspi3_fck 0 1 48000000
- mcspi4_fck 0 1 48000000
- omap_12m_fck 0 1 12000000
- core_12m_fck 0 1 12000000
- hdq_fck 0 1 12000000
- usbhost_48m_fck 1 1 48000000
- omap_96m_fck 0 2 96000000
- dss_96m_fck 0 2 96000000
- core_96m_fck 0 10 96000000
- mcbsp1_fck 0 1 96000000
- mcbsp5_fck 0 1 96000000
- i2c1_fck 0 1 96000000
- i2c2_fck 0 1 96000000
- i2c3_fck 0 1 96000000
- mmchs1_fck 0 1 96000000
- mmchs2_fck 0 1 96000000
- csi2_96m_fck 0 0 96000000
- mspro_fck 0 0 96000000
- mmchs3_fck 0 1 96000000
- dpll4_x2_ck 0 0 1728000000
+ dpll1_ck 0 1 600000000
+ dpll1_x2_ck 0 1 1200000000 0
+ dpll1_x2m2_ck 0 1 1200000000 0
+ mpu_ck 0 1 1200000000 0
+ emu_mpu_alwon_ck 0 0 1200000000 0
+ arm_fck 0 1 600000000
dpll3_ck 1 1 400000000
- dpll3_m3_ck 0 0 200000000
- dpll3_m3x2_ck 0 0 400000000
- emu_core_alwon_ck 0 0 400000000
dpll3_m2_ck 1 1 400000000
- dpll3_m2x2_ck 0 0 800000000
- corex2_fck 0 0 800000000
- ssi_ssr_fck_3430es2 0 0 266666666
- ssi_sst_fck_3430es2 0 0 133333333
core_ck 1 1 400000000
+ core_d2_ck 0 0 200000000
+ sgx_fck 0 0 200000000
+ core_d6_ck 0 0 66666666
+ core_d4_ck 0 0 100000000
+ core_d3_ck 0 0 133333333
+ dpll2_fck 0 0 400000000
l3_ick 2 3 200000000
+ sgx_ick 0 0 200000000
+ mad2d_ick 0 0 200000000
+ sad2d_ick 0 1 200000000
+ security_l3_ick 0 0 200000000
+ pka_ick 0 0 200000000
core_l3_ick 8 10 200000000
+ hsotgusb_ick_3430es2 0 1 200000000
gpmc_fck 2 2 200000000
sdrc_ick 1 1 200000000
- hsotgusb_ick_3430es2 0 1 200000000
l4_ick 6 7 100000000
+ usbhost_ick 1 1 100000000
+ dss_ick_3430es2 4 6 100000000
+ sr_l4_ick 2 2 100000000
+ ssi_l4_ick 0 0 100000000
+ ssi_ick_3430es2 0 0 100000000
+ cam_ick 0 1 100000000
+ security_l4_ick2 0 0 100000000
+ des1_ick 0 0 100000000
+ sha11_ick 0 0 100000000
+ rng_ick 0 0 100000000
+ aes1_ick 0 0 100000000
per_l4_ick 16 18 100000000
mcbsp4_ick 2 2 100000000
mcbsp3_ick 2 2 100000000
@@ -116,6 +102,14 @@
gpio5_ick 1 1 100000000
gpio6_ick 1 1 100000000
core_l4_ick 21 23 100000000
+ mmchs3_ick 1 1 100000000
+ usbtll_ick 1 1 100000000
+ mailboxes_ick 0 1 100000000
+ mspro_ick 0 0 100000000
+ des2_ick 0 0 100000000
+ icr_ick 0 0 100000000
+ sha12_ick 1 2 100000000
+ aes2_ick 1 2 100000000
omapctrl_ick 1 1 100000000
mcbsp1_ick 1 1 100000000
mcbsp5_ick 1 1 100000000
@@ -133,66 +127,97 @@
hdq_ick 0 1 100000000
mmchs1_ick 1 1 100000000
mmchs2_ick 1 1 100000000
- icr_ick 0 0 100000000
- aes2_ick 1 2 100000000
- sha12_ick 1 2 100000000
- des2_ick 0 0 100000000
- mspro_ick 0 0 100000000
- mailboxes_ick 0 1 100000000
- usbtll_ick 1 1 100000000
- mmchs3_ick 1 1 100000000
rm_ick 0 0 50000000
- cam_ick 0 1 100000000
- ssi_l4_ick 0 0 100000000
- ssi_ick_3430es2 0 0 100000000
- sr_l4_ick 2 2 100000000
- security_l4_ick2 0 0 100000000
- aes1_ick 0 0 100000000
- rng_ick 0 0 100000000
- sha11_ick 0 0 100000000
- des1_ick 0 0 100000000
- dss_ick_3430es2 4 6 100000000
- usbhost_ick 1 1 100000000
- security_l3_ick 0 0 200000000
- pka_ick 0 0 200000000
- sad2d_ick 0 1 200000000
- mad2d_ick 0 0 200000000
- sgx_ick 0 0 200000000
dpll1_fck 0 0 200000000
- dpll2_fck 0 0 400000000
- sgx_fck 0 0 200000000
+ dpll3_m2x2_ck 0 0 800000000
+ corex2_fck 0 0 800000000
+ ssi_ssr_fck_3430es2 0 0 266666666
+ ssi_sst_fck_3430es2 0 0 133333333
+ corex2_d5_fck 0 0 160000000
+ corex2_d3_fck 0 0 266666666
+ dpll3_m3_ck 0 0 200000000
+ dpll3_m3x2_mul_ck 0 0 400000000
+ dpll3_m3x2_ck 0 0 400000000
+ emu_core_alwon_ck 0 0 400000000
dpll3_x2_ck 0 0 800000000
- dpll1_ck 0 1 600000000
- dpll1_x2_ck 0 1 1200000000
- dpll1_x2m2_ck 0 1 1200000000
- mpu_ck 0 1 1200000000
- emu_mpu_alwon_ck 0 0 1200000000
- arm_fck 0 1 600000000
- usim_fck 0 0 6500000
- sr1_fck 0 1 13000000
- sr2_fck 0 1 13000000
+ dpll4_ck 1 3 864000000
+ dpll4_m6_ck 0 0 288000000
+ dpll4_m6x2_mul_ck 0 0 576000000
+ dpll4_m6x2_ck 0 0 576000000
+ emu_per_alwon_ck 0 0 576000000
+ dpll4_m5_ck 0 0 216000000
+ dpll4_m5x2_mul_ck 0 0 432000000
+ dpll4_m5x2_ck 0 0 432000000
+ cam_mclk 0 0 432000000
+ dpll4_m4_ck 0 1 96000000
+ dpll4_m4x2_mul_ck 0 1 192000000
+ dpll4_m4x2_ck 0 1 192000000
+ dss1_alwon_fck_3430es2 0 4 192000000
+ dpll4_m3_ck 0 1 54000000
+ dpll4_m3x2_mul_ck 0 1 108000000
+ dpll4_m3x2_ck 0 1 108000000
+ omap_54m_fck 0 1 108000000
+ dss_tv_fck 0 2 108000000
+ 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
+ cm_96m_d2_fck 1 1 96000000
+ omap_48m_fck 3 4 96000000
+ usbhost_48m_fck 1 1 96000000
+ per_48m_fck 1 2 96000000
+ uart4_fck 0 1 96000000
+ uart3_fck 1 1 96000000
+ core_48m_fck 2 6 96000000
+ uart1_fck 1 1 96000000
+ uart2_fck 1 1 96000000
+ mcspi1_fck 0 1 96000000
+ mcspi2_fck 0 1 96000000
+ mcspi3_fck 0 1 96000000
+ mcspi4_fck 0 1 96000000
+ omap_12m_fck 0 1 24000000
+ core_12m_fck 0 1 24000000
+ hdq_fck 0 1 24000000
+ omap_96m_fck 0 2 192000000
+ omap_96m_d10_fck 0 0 19200000
+ omap_96m_d8_fck 0 0 24000000
+ omap_96m_d4_fck 0 0 48000000
+ omap_96m_d2_fck 0 0 96000000
+ dss_96m_fck 0 2 192000000
+ core_96m_fck 0 10 192000000
+ mcbsp1_fck 0 1 192000000
+ mcbsp5_fck 0 1 192000000
+ mmchs3_fck 0 1 192000000
+ mspro_fck 0 0 192000000
+ csi2_96m_fck 0 0 192000000
+ i2c1_fck 0 1 192000000
+ i2c2_fck 0 1 192000000
+ i2c3_fck 0 1 192000000
+ mmchs1_fck 0 1 192000000
+ mmchs2_fck 0 1 192000000
+ dpll4_x2_ck 0 0 1728000000 0
wkup_l4_ick 5 5 13000000
+ usim_ick 0 0 13000000
gpt1_ick 1 1 13000000
gpt12_ick 1 1 13000000
omap_32ksync_ick 1 1 13000000
gpio1_ick 1 1 13000000
wdt1_ick 0 0 13000000
wdt2_ick 1 1 13000000
- usim_ick 0 0 13000000
- modem_fck 0 0 13000000
- dpll2_ck 0 1 260000000
- dpll2_m2_ck 0 1 260000000
- iva2_ck 0 1 260000000
- dpll5_ck 1 1 120000000
- dpll5_m2_ck 2 2 120000000
- usbhost_120m_fck 1 2 120000000
- usbtll_fck 1 1 120000000
- cpefuse_fck 0 0 13000000
virt_19200000_ck 0 0 19200000
virt_13m_ck 0 0 13000000
virt_12m_ck 0 0 12000000
omap_32k_fck 2 8 32768
gpt1_fck 1 1 32768
+ ts_fck 0 0 32768
per_32k_alwon_fck 0 5 32768
wdt3_fck 0 0 32768
gpio2_dbck 0 1 32768
@@ -205,7 +230,5 @@
gpio1_dbck 0 1 32768
gpt11_fck 0 1 32768
gpt10_fck 0 1 32768
- ts_fck 0 0 32768
dummy_apb_pclk 0 0 0
virt_16_8m_ck 0 0 16800000
- dummy_clk 0 0 0
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-28 8:48 ` Tomi Valkeinen
@ 2014-01-28 18:17 ` Ivaylo Dimitrov
2014-01-29 9:10 ` Tero Kristo
2014-01-29 11:30 ` Tomi Valkeinen
0 siblings, 2 replies; 33+ messages in thread
From: Ivaylo Dimitrov @ 2014-01-28 18:17 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-kernel, pali.rohar, pavel, chf.fritz, Tero Kristo, nm
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
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
[-- Attachment #2: clk_summary.txt --]
[-- Type: text/plain, Size: 17575 bytes --]
clock enable_cnt prepare_cnt rate accuracy
---------------------------------------------------------------------------------
secure_32k_fck 0 0 32768 0
wdt1_fck 0 0 32768 0
gpt12_fck 0 0 32768 0
mcbsp_clks 0 5 0 0
sys_altclk 0 0 0 0
virt_38_4m_ck 0 0 38400000 0
virt_26000000_ck 0 0 26000000 0
virt_19200000_ck 1 1 19200000 0
osc_sys_ck 1 1 19200000 0
sys_clkout1 0 0 19200000 0
sys_ck 4 14 19200000 0
dpll1_ck 0 1 600000000 0
dpll1_x2_ck 0 1 1200000000 0
dpll1_x2m2_ck 0 1 1200000000 0
mpu_ck 0 1 1200000000 0
emu_mpu_alwon_ck 0 0 1200000000 0
arm_fck 0 1 600000000 0
traceclk_src_fck 0 0 19200000 0
traceclk_fck 0 0 19200000 0
emu_src_ck 0 1 19200000 0
atclk_fck 0 0 19200000 0
pclkx2_fck 0 0 19200000 0
pclk_fck 0 0 9600000 0
gpt9_fck 0 1 19200000 0
gpt4_fck 0 1 19200000 0
gpt3_fck 0 1 19200000 0
gpt2_fck 0 1 19200000 0
dss2_alwon_fck 0 2 19200000 0
dpll4_ck 2 3 432000000 0
dpll4_m6_ck 0 0 144000000 0
dpll4_m6x2_ck 0 0 288000000 0
emu_per_alwon_ck 0 0 288000000 0
dpll4_m5_ck 0 0 86400000 0
dpll4_m5x2_ck 0 0 172800000 0
cam_mclk 0 0 172800000 0
cam_xclkb 0 0 10800000 0
cam_xclka 0 0 9600000 0
dpll4_m4_ck 1 1 36000000 0
dpll4_m4x2_ck 1 1 72000000 0
dss1_alwon_fck_3430es2 2 4 72000000 0
dpll4_m3_ck 0 1 27000000 0
dpll4_m3x2_ck 0 1 54000000 0
omap_54m_fck 0 1 54000000 0
dss_tv_fck 0 2 54000000 0
clkout2_src_ck 0 0 54000000 0
sys_clkout2 0 0 54000000 0
dpll4_m2_ck 1 1 48000000 0
dpll4_m2x2_ck 1 1 96000000 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 2 96000000 0
omap_48m_fck 2 4 48000000 0
per_48m_fck 1 1 48000000 0
uart3_fck 1 1 48000000 0
core_48m_fck 3 6 48000000 0
uart1_fck 1 1 48000000 0
uart2_fck 1 1 48000000 0
mcspi1_fck 0 1 48000000 0
mcspi2_fck 0 1 48000000 0
mcspi3_fck 0 1 48000000 0
mcspi4_fck 1 1 48000000 0
omap_12m_fck 0 1 12000000 0
core_12m_fck 0 1 12000000 0
hdq_fck 0 1 12000000 0
usbhost_48m_fck 0 1 48000000 0
omap_96m_fck 1 2 96000000 0
dss_96m_fck 0 2 96000000 0
core_96m_fck 3 10 96000000 0
mcbsp1_fck 0 1 96000000 0
mcbsp5_fck 0 1 96000000 0
i2c1_fck 1 1 96000000 0
i2c2_fck 1 1 96000000 0
i2c3_fck 1 1 96000000 0
mmchs1_fck 0 1 96000000 0
mmchs2_fck 0 1 96000000 0
csi2_96m_fck 0 0 96000000 0
mspro_fck 0 0 96000000 0
mmchs3_fck 0 1 96000000 0
dpll4_x2_ck 0 0 864000000 0
dpll3_ck 1 1 664000000 0
dpll3_m3_ck 0 0 221333333 0
dpll3_m3x2_ck 0 0 442666666 0
emu_core_alwon_ck 0 0 442666666 0
dpll3_m2_ck 1 2 332000000 0
dpll3_m2x2_ck 0 1 664000000 0
corex2_fck 0 1 664000000 0
ssi_ssr_fck_3430es2 0 2 221333333 0
ssi_sst_fck_3430es2 0 1 110666666 0
core_ck 1 1 332000000 0
l3_ick 2 3 166000000 0
core_l3_ick 8 10 166000000 0
gpmc_fck 2 2 166000000 0
sdrc_ick 1 1 166000000 0
hsotgusb_ick_3430es2 0 1 166000000 0
l4_ick 7 8 83000000 0
per_l4_ick 17 18 83000000 0
mcbsp4_ick 2 2 83000000 0
mcbsp3_ick 2 2 83000000 0
mcbsp2_ick 1 1 83000000 0
gpt2_ick 1 1 83000000 0
gpt3_ick 1 1 83000000 0
gpt4_ick 1 1 83000000 0
gpt5_ick 1 1 83000000 0
gpt6_ick 1 1 83000000 0
gpt7_ick 1 1 83000000 0
gpt8_ick 1 1 83000000 0
gpt9_ick 1 1 83000000 0
uart4_ick 0 0 83000000 0
uart3_ick 1 1 83000000 0
wdt3_ick 0 1 83000000 0
gpio2_ick 1 1 83000000 0
gpio3_ick 1 1 83000000 0
gpio4_ick 1 1 83000000 0
gpio5_ick 1 1 83000000 0
gpio6_ick 1 1 83000000 0
core_l4_ick 20 21 83000000 0
omapctrl_ick 1 1 83000000 0
mcbsp1_ick 1 1 83000000 0
mcbsp5_ick 1 1 83000000 0
gpt10_ick 1 1 83000000 0
gpt11_ick 1 1 83000000 0
uart1_ick 1 1 83000000 0
uart2_ick 1 1 83000000 0
i2c1_ick 1 1 83000000 0
i2c2_ick 1 1 83000000 0
i2c3_ick 1 1 83000000 0
mcspi1_ick 1 1 83000000 0
mcspi2_ick 1 1 83000000 0
mcspi3_ick 1 1 83000000 0
mcspi4_ick 1 1 83000000 0
hdq_ick 0 1 83000000 0
mmchs1_ick 1 1 83000000 0
mmchs2_ick 1 1 83000000 0
icr_ick 0 0 83000000 0
aes2_ick 0 0 83000000 0
sha12_ick 0 0 83000000 0
des2_ick 0 0 83000000 0
mspro_ick 0 0 83000000 0
mailboxes_ick 1 1 83000000 0
usbtll_ick 1 1 83000000 0
mmchs3_ick 1 1 83000000 0
rm_ick 0 0 41500000 0
cam_ick 1 1 83000000 0
ssi_l4_ick 0 1 83000000 0
ssi_ick_3430es2 0 1 83000000 0
sr_l4_ick 2 2 83000000 0
security_l4_ick2 0 0 83000000 0
aes1_ick 0 0 83000000 0
rng_ick 0 0 83000000 0
sha11_ick 0 0 83000000 0
des1_ick 0 0 83000000 0
dss_ick_3430es2 4 6 83000000 0
usbhost_ick 1 1 83000000 0
security_l3_ick 0 0 166000000 0
pka_ick 0 0 166000000 0
sad2d_ick 0 1 166000000 0
mad2d_ick 0 0 166000000 0
sgx_ick 0 0 166000000 0
dpll1_fck 0 0 166000000 0
dpll2_fck 0 0 332000000 0
sgx_fck 0 0 110666666 0
dpll3_x2_ck 0 0 1328000000 0
sr1_fck 0 1 19200000 0
sr2_fck 0 1 19200000 0
wkup_l4_ick 4 4 19200000 0
gpt1_ick 1 1 19200000 0
gpt12_ick 0 0 19200000 0
omap_32ksync_ick 1 1 19200000 0
gpio1_ick 1 1 19200000 0
wdt1_ick 0 0 19200000 0
wdt2_ick 1 1 19200000 0
usim_ick 0 0 19200000 0
modem_fck 0 0 19200000 0
dpll2_ck 1 1 249600000 0
dpll2_m2_ck 1 1 249600000 0
iva2_ck 1 4 249600000 0
usim_fck 0 0 9600000 0
dpll5_ck 0 1 120000000 0
dpll5_m2_ck 0 2 120000000 0
usbhost_120m_fck 0 1 120000000 0
usbtll_fck 0 1 120000000 0
cpefuse_fck 0 0 19200000 0
virt_13m_ck 0 0 13000000 0
virt_12m_ck 0 0 12000000 0
omap_32k_fck 2 12 32768 0
gpt8_fck 0 1 32768 0
gpt7_fck 0 1 32768 0
gpt6_fck 0 1 32768 0
gpt5_fck 0 1 32768 0
per_32k_alwon_fck 0 6 32768 0
wdt3_fck 0 1 32768 0
gpio2_dbck 0 1 32768 0
gpio3_dbck 0 1 32768 0
gpio4_dbck 0 1 32768 0
gpio5_dbck 0 1 32768 0
gpio6_dbck 0 1 32768 0
wkup_32k_fck 1 3 32768 0
wdt2_fck 0 1 32768 0
gpio1_dbck 0 1 32768 0
gpt1_fck 1 1 32768 0
gpt11_fck 0 1 32768 0
gpt10_fck 0 1 32768 0
ts_fck 0 0 32768 0
dummy_apb_pclk 0 0 0 0
virt_16_8m_ck 0 0 16800000 0
dummy_clk 0 0 0 0
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-28 18:17 ` Ivaylo Dimitrov
@ 2014-01-29 9:10 ` Tero Kristo
2014-01-29 9:29 ` Ivaylo Dimitrov
2014-01-29 11:30 ` Tomi Valkeinen
1 sibling, 1 reply; 33+ messages in thread
From: Tero Kristo @ 2014-01-29 9:10 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tomi Valkeinen
Cc: linux-omap, linux-kernel, pali.rohar, pavel, chf.fritz, nm
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 <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;
+};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-29 9:10 ` Tero Kristo
@ 2014-01-29 9:29 ` Ivaylo Dimitrov
2014-01-29 9:38 ` Tomi Valkeinen
0 siblings, 1 reply; 33+ messages in thread
From: Ivaylo Dimitrov @ 2014-01-29 9:29 UTC (permalink / raw)
To: Tero Kristo, Tomi Valkeinen
Cc: linux-omap, linux-kernel, pali.rohar, pavel, chf.fritz, nm
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-29 9:29 ` Ivaylo Dimitrov
@ 2014-01-29 9:38 ` Tomi Valkeinen
2014-01-29 9:50 ` Tero Kristo
0 siblings, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-01-29 9:38 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tero Kristo
Cc: linux-omap, linux-kernel, pali.rohar, pavel, chf.fritz, nm
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-29 9:38 ` Tomi Valkeinen
@ 2014-01-29 9:50 ` Tero Kristo
0 siblings, 0 replies; 33+ messages in thread
From: Tero Kristo @ 2014-01-29 9:50 UTC (permalink / raw)
To: Tomi Valkeinen, Ivaylo Dimitrov
Cc: linux-omap, linux-kernel, pali.rohar, pavel, chf.fritz, nm
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* OMAP: clock DT conversion issues with omap36xx
2014-01-28 17:02 ` Christoph Fritz
@ 2014-01-29 11:21 ` Christoph Fritz
2014-01-29 14:57 ` Tero Kristo
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Christoph Fritz @ 2014-01-29 11:21 UTC (permalink / raw)
To: Tero Kristo
Cc: Tomi Valkeinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
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 <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
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-28 18:17 ` Ivaylo Dimitrov
2014-01-29 9:10 ` Tero Kristo
@ 2014-01-29 11:30 ` Tomi Valkeinen
2014-01-29 18:52 ` Ivaylo Dimitrov
1 sibling, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-01-29 11:30 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: linux-omap, linux-kernel, pali.rohar, pavel, chf.fritz, Tero Kristo, nm
[-- Attachment #1: Type: text/plain, Size: 2799 bytes --]
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 <tomi.valkeinen@ti.com>
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
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-04 15:50 ` Tero Kristo
2 siblings, 1 reply; 33+ messages in thread
From: Tero Kristo @ 2014-01-29 14:57 UTC (permalink / raw)
To: Christoph Fritz
Cc: Tomi Valkeinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
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
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-29 11:30 ` Tomi Valkeinen
@ 2014-01-29 18:52 ` Ivaylo Dimitrov
2014-01-30 6:04 ` Tomi Valkeinen
0 siblings, 1 reply; 33+ messages in thread
From: Ivaylo Dimitrov @ 2014-01-29 18:52 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-kernel, pali.rohar, pavel, chf.fritz, Tero Kristo, nm
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 <tomi.valkeinen@ti.com>
> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-01-29 11:21 ` OMAP: clock DT conversion issues with omap36xx Christoph Fritz
2014-01-29 14:57 ` Tero Kristo
@ 2014-01-29 19:03 ` Nishanth Menon
2014-02-01 18:52 ` Christoph Fritz
2014-02-04 15:50 ` Tero Kristo
2 siblings, 1 reply; 33+ messages in thread
From: Nishanth Menon @ 2014-01-29 19:03 UTC (permalink / raw)
To: Christoph Fritz, Tero Kristo
Cc: Tomi Valkeinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [BISECTED] OMAP: DSS: clk rate mismatch
2014-01-29 18:52 ` Ivaylo Dimitrov
@ 2014-01-30 6:04 ` Tomi Valkeinen
0 siblings, 0 replies; 33+ messages in thread
From: Tomi Valkeinen @ 2014-01-30 6:04 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: linux-omap, linux-kernel, pali.rohar, pavel, chf.fritz, Tero Kristo, nm
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]
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 <tomi.valkeinen@ti.com>
>> 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-01-29 19:03 ` Nishanth Menon
@ 2014-02-01 18:52 ` Christoph Fritz
2014-02-02 20:09 ` Christoph Fritz
0 siblings, 1 reply; 33+ messages in thread
From: Christoph Fritz @ 2014-02-01 18:52 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Tomi Valkeinen, Ivaylo Dimitrov, linux-omap,
linux-kernel, pali.rohar, pavel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-01-29 14:57 ` Tero Kristo
@ 2014-02-01 18:55 ` Christoph Fritz
0 siblings, 0 replies; 33+ messages in thread
From: Christoph Fritz @ 2014-02-01 18:55 UTC (permalink / raw)
To: Tero Kristo
Cc: Tomi Valkeinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-01 18:52 ` Christoph Fritz
@ 2014-02-02 20:09 ` Christoph Fritz
0 siblings, 0 replies; 33+ messages in thread
From: Christoph Fritz @ 2014-02-02 20:09 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Tomi Valkeinen, Ivaylo Dimitrov, linux-omap,
linux-kernel, pali.rohar, pavel
[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]
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.
[-- Attachment #2: ctt_dump_lil_a83x_next_20140124__breaks.rd1 --]
[-- Type: text/plain, Size: 1148 bytes --]
DeviceName OMAP3630_ES1.x
0x48002274 0x05000000
0x480022d8 0x00000000
0x48004000 0x00000000
0x48004004 0x00000017
0x48004040 0x00081400
0x48004044 0x00000001
0x48004904 0x00000037
0x48004940 0x0012580c
0x48004944 0x00000001
0x48004a00 0x00006000
0x48004a08 0x00000004
0x48004a10 0x5b3ffe42
0x48004a18 0x00000004
0x48004a30 0x7ffffed9
0x48004a38 0x0000000c
0x48004a40 0x0000130a
0x48004b00 0x00000000
0x48004b10 0x00000000
0x48004b40 0x00000005
0x48004c00 0x00000001
0x48004c10 0x0000002f
0x48004c30 0x0000023f
0x48004c40 0x00000014
0x48004d00 0xf0371037
0x48004d04 0x00000017
0x48004d40 0x09900c00
0x48004d44 0x0483600c
0x48004d48 0x00000009
0x48004d4c 0x0000780c
0x48004d50 0x00000001
0x48004d70 0x0000009a
0x48004e00 0x00000000
0x48004e10 0x00000001
0x48004e30 0x00000001
0x48004e40 0x00001009
0x48004f00 0x00000000
0x48004f10 0x00000000
0x48004f30 0x00000001
0x48004f40 0x00000004
0x48005000 0x00000800
0x48005010 0x00078fff
0x48005030 0x0007ffff
0x48005040 0x000000ff
0x48005140 0x03020a50
0x48005400 0x00000003
0x48005410 0x00000001
0x48005430 0x00000001
0x48306ae0 0x000f0317
0x48306d70 0x00000000
0x48307270 0x00000088
0x483074e0 0x00030105
[-- Attachment #3: ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 --]
[-- Type: text/plain, Size: 1148 bytes --]
DeviceName OMAP3630_ES1.x
0x48002274 0x05000000
0x480022d8 0x00000000
0x48004000 0x00000000
0x48004004 0x00000017
0x48004040 0x00081400
0x48004044 0x00000001
0x48004904 0x00000037
0x48004940 0x0012580c
0x48004944 0x00000001
0x48004a00 0x00006000
0x48004a08 0x00000004
0x48004a10 0x5b3ffe42
0x48004a18 0x00000004
0x48004a30 0x7ffffed9
0x48004a38 0x0000000c
0x48004a40 0x0000130a
0x48004b00 0x00000000
0x48004b10 0x00000000
0x48004b40 0x00000005
0x48004c00 0x00000001
0x48004c10 0x0000002f
0x48004c30 0x0000023f
0x48004c40 0x00000014
0x48004d00 0x10370037
0x48004d04 0x00000017
0x48004d40 0x09900c00
0x48004d44 0x0483600c
0x48004d48 0x00000009
0x48004d4c 0x0000780c
0x48004d50 0x00000001
0x48004d70 0x00000092
0x48004e00 0x00000001
0x48004e10 0x00000001
0x48004e30 0x00000001
0x48004e40 0x0000100f
0x48004f00 0x00000000
0x48004f10 0x00000000
0x48004f30 0x00000001
0x48004f40 0x00000004
0x48005000 0x00040800
0x48005010 0x00078fff
0x48005030 0x0007ffff
0x48005040 0x000000ff
0x48005140 0x03020a50
0x48005400 0x00000003
0x48005410 0x00000001
0x48005430 0x00000001
0x48306ae0 0x000f0317
0x48306d70 0x00000000
0x48307270 0x00000088
0x483074e0 0x00030105
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-01-29 11:21 ` OMAP: clock DT conversion issues with omap36xx Christoph Fritz
2014-01-29 14:57 ` Tero Kristo
2014-01-29 19:03 ` Nishanth Menon
@ 2014-02-04 15:50 ` Tero Kristo
2014-02-07 10:12 ` Christoph Fritz
2 siblings, 1 reply; 33+ messages in thread
From: Tero Kristo @ 2014-02-04 15:50 UTC (permalink / raw)
To: Christoph Fritz
Cc: Tomi Valkeinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
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 <t-kristo@ti.com>
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 <t-kristo@ti.com>
---
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
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-04 15:50 ` Tero Kristo
@ 2014-02-07 10:12 ` Christoph Fritz
2014-02-07 13:49 ` Tomi Valkeinen
2014-02-12 13:18 ` Tomi Valkeinen
0 siblings, 2 replies; 33+ messages in thread
From: Christoph Fritz @ 2014-02-07 10:12 UTC (permalink / raw)
To: Tero Kristo
Cc: Tomi Valkeinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
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
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 <chf.fritz@googlemail.com>
---
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
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-07 10:12 ` Christoph Fritz
@ 2014-02-07 13:49 ` Tomi Valkeinen
2014-02-10 20:54 ` Christoph Fritz
2014-02-12 13:18 ` Tomi Valkeinen
1 sibling, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-02-07 13:49 UTC (permalink / raw)
To: Christoph Fritz, Tero Kristo
Cc: Ivaylo Dimitrov, linux-omap, linux-kernel, pali.rohar, pavel,
Nishanth Menon
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
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 <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
>
> 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-07 13:49 ` Tomi Valkeinen
@ 2014-02-10 20:54 ` Christoph Fritz
2014-02-11 14:53 ` Tomi Valkeinen
0 siblings, 1 reply; 33+ messages in thread
From: Christoph Fritz @ 2014-02-10 20:54 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tero Kristo, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
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 <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
> >
> > 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-10 20:54 ` Christoph Fritz
@ 2014-02-11 14:53 ` Tomi Valkeinen
0 siblings, 0 replies; 33+ messages in thread
From: Tomi Valkeinen @ 2014-02-11 14:53 UTC (permalink / raw)
To: Christoph Fritz
Cc: Tero Kristo, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-07 10:12 ` Christoph Fritz
2014-02-07 13:49 ` Tomi Valkeinen
@ 2014-02-12 13:18 ` Tomi Valkeinen
2014-02-12 22:30 ` Belisko Marek
2014-02-13 9:03 ` Tomi Valkeinen
1 sibling, 2 replies; 33+ messages in thread
From: Tomi Valkeinen @ 2014-02-12 13:18 UTC (permalink / raw)
To: Christoph Fritz, Tero Kristo
Cc: Ivaylo Dimitrov, linux-omap, linux-kernel, pali.rohar, pavel,
Nishanth Menon
[-- Attachment #1: Type: text/plain, Size: 7287 bytes --]
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?
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-12 13:18 ` Tomi Valkeinen
@ 2014-02-12 22:30 ` Belisko Marek
2014-02-13 9:03 ` Tomi Valkeinen
1 sibling, 0 replies; 33+ messages in thread
From: Belisko Marek @ 2014-02-12 22:30 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Christoph Fritz, Tero Kristo, Ivaylo Dimitrov, linux-omap, LKML,
pali.rohar, Pavel Machek, Nishanth Menon
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-12 13:18 ` Tomi Valkeinen
2014-02-12 22:30 ` Belisko Marek
@ 2014-02-13 9:03 ` Tomi Valkeinen
2014-02-13 10:05 ` Tomi Valkeinen
1 sibling, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-02-13 9:03 UTC (permalink / raw)
To: Christoph Fritz, Tero Kristo
Cc: Ivaylo Dimitrov, linux-omap, linux-kernel, pali.rohar, pavel,
Nishanth Menon
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-13 9:03 ` Tomi Valkeinen
@ 2014-02-13 10:05 ` Tomi Valkeinen
2014-02-14 2:18 ` Christoph Fritz
0 siblings, 1 reply; 33+ messages in thread
From: Tomi Valkeinen @ 2014-02-13 10:05 UTC (permalink / raw)
To: Christoph Fritz, Tero Kristo
Cc: Ivaylo Dimitrov, linux-omap, linux-kernel, pali.rohar, pavel,
Nishanth Menon
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: OMAP: clock DT conversion issues with omap36xx
2014-02-13 10:05 ` Tomi Valkeinen
@ 2014-02-14 2:18 ` Christoph Fritz
0 siblings, 0 replies; 33+ messages in thread
From: Christoph Fritz @ 2014-02-14 2:18 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tero Kristo, Ivaylo Dimitrov, linux-omap, linux-kernel,
pali.rohar, pavel, Nishanth Menon
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 <chf.fritz@googlemail.com>
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
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2014-02-14 2:18 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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).