* [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 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
* 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: 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: 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-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: 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-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
* 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-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
* 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: [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: [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
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).