| Message ID | 52E697C0.6000202@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
On 2014-01-27 20:41, Christoph Fritz wrote: > On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote: >> linux-next-20140124 DSS is broken on N900 - display stays black (there >> is some noise though). I booted the kernel with qemu and it gives the >> following warning: >> >> [ 0.623779] DSS: set fck to 172800000 >> [ 0.624237] ------------[ cut here ]------------ >> [ 0.624298] WARNING: CPU: 0 PID: 1 at >> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() >> [ 0.624359] clk rate mismatch: 288000000 != 172800000 > > Here are also clock regressions since next-20140122 regarding > dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a > dm37xx100 board. Please see here: I presume you get a similar warning on your board? What rates does it report? Tomi
On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote: > On 2014-01-27 20:41, Christoph Fritz wrote: > > On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote: > >> linux-next-20140124 DSS is broken on N900 - display stays black (there > >> is some noise though). I booted the kernel with qemu and it gives the > >> following warning: > >> > >> [ 0.623779] DSS: set fck to 172800000 > >> [ 0.624237] ------------[ cut here ]------------ > >> [ 0.624298] WARNING: CPU: 0 PID: 1 at > >> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() > >> [ 0.624359] clk rate mismatch: 288000000 != 172800000 > > > > Here are also clock regressions since next-20140122 regarding > > dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a > > dm37xx100 board. Please see here: > > I presume you get a similar warning on your board? What rates does it > report? None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22. To quote the cover-letter[1] of my board-support patch series here: Due to a regression since next-20140122 the following errors are present: - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch in this set, erroneously outputs only 12 Mhz. Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. - omap_dss, which gets configured by the third patch in this set, fails to do 'dss_set_fck_rate(fck);' in drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: | omapdss_dss: probe of omapdss_dss failed with error -22 | omapdss CORE error: Failed to initialize DSS platform driver | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 Both regressions seem to have something to do with the clock framework. Could this be related to the DT clock conversion patches? [1]: http://thread.gmane.org/gmane.linux.ports.arm.omap/110095 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2014-01-28 11:35, Christoph Fritz wrote: > On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote: >> On 2014-01-27 20:41, Christoph Fritz wrote: >>> On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote: >>>> linux-next-20140124 DSS is broken on N900 - display stays black (there >>>> is some noise though). I booted the kernel with qemu and it gives the >>>> following warning: >>>> >>>> [ 0.623779] DSS: set fck to 172800000 >>>> [ 0.624237] ------------[ cut here ]------------ >>>> [ 0.624298] WARNING: CPU: 0 PID: 1 at >>>> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() >>>> [ 0.624359] clk rate mismatch: 288000000 != 172800000 >>> >>> Here are also clock regressions since next-20140122 regarding >>> dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a >>> dm37xx100 board. Please see here: >> >> I presume you get a similar warning on your board? What rates does it >> report? > > None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22. Ok, then it's something else. That means clk_set_rate() fails. If you can do some tests, you could print the rate that the dss_set_fck_rate() is given, to see that it's something reasonable, and also do a clk_get_rate(dss.dss_clk) to see that the clock itself is ok and there's some valid rate there. > To quote the cover-letter[1] of my board-support patch series here: > > Due to a regression since next-20140122 the following errors are present: > > - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch > in this set, erroneously outputs only 12 Mhz. > Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. > > - omap_dss, which gets configured by the third patch in this set, fails > to do 'dss_set_fck_rate(fck);' in > drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: > > | omapdss_dss: probe of omapdss_dss failed with error -22 > | omapdss CORE error: Failed to initialize DSS platform driver > | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 > > Both regressions seem to have something to do with the clock framework. > Could this be related to the DT clock conversion patches? No idea... Tomi
On 01/28/2014 11:48 AM, Tomi Valkeinen wrote: > On 2014-01-28 11:35, Christoph Fritz wrote: >> On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote: >>> On 2014-01-27 20:41, Christoph Fritz wrote: >>>> On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote: >>>>> linux-next-20140124 DSS is broken on N900 - display stays black (there >>>>> is some noise though). I booted the kernel with qemu and it gives the >>>>> following warning: >>>>> >>>>> [ 0.623779] DSS: set fck to 172800000 >>>>> [ 0.624237] ------------[ cut here ]------------ >>>>> [ 0.624298] WARNING: CPU: 0 PID: 1 at >>>>> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() >>>>> [ 0.624359] clk rate mismatch: 288000000 != 172800000 >>>> >>>> Here are also clock regressions since next-20140122 regarding >>>> dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a >>>> dm37xx100 board. Please see here: >>> >>> I presume you get a similar warning on your board? What rates does it >>> report? >> >> None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22. > > Ok, then it's something else. That means clk_set_rate() fails. > > If you can do some tests, you could print the rate that the > dss_set_fck_rate() is given, to see that it's something reasonable, and > also do a clk_get_rate(dss.dss_clk) to see that the clock itself is ok > and there's some valid rate there. > >> To quote the cover-letter[1] of my board-support patch series here: >> >> Due to a regression since next-20140122 the following errors are present: >> >> - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch >> in this set, erroneously outputs only 12 Mhz. >> Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. >> >> - omap_dss, which gets configured by the third patch in this set, fails >> to do 'dss_set_fck_rate(fck);' in >> drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: >> >> | omapdss_dss: probe of omapdss_dss failed with error -22 >> | omapdss CORE error: Failed to initialize DSS platform driver >> | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 >> >> Both regressions seem to have something to do with the clock framework. >> Could this be related to the DT clock conversion patches? > > No idea... Yea its definitely possible, as the clock DT conversion touches pretty much everything. Have you tried whether this works properly with legacy boot? Personally I don't have access to any omap3 devices that would have display and have no possibility to check this out myself. Anyway, my initial guess is that some clock divider setup might be wrong with omap3, or we are missing some ti,set-rate-parent flag for some clock node which prevents escalating clk_set_rate properly. However, it should be easy to debug this by looking at the clock node in question, and its parent nodes to see if there are any problems. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);