| Message ID | 1398815562-24113-2-git-send-email-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Tony Lindgren <tony@atomide.com> [140429 16:53]: > Otherwise we can get often errors like the following and the > display won't come on: > > omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay > omapdss APPLY error: SYNC_LOST on channel lcd, restarting > the output with video overlays disabled > > There are some earlier references to this issue: > > http://www.spinics.net/lists/linux-omap/msg59511.html > http://www.spinics.net/lists/linux-omap/msg59724.html > > It seems that it's safe to set the lower values even for 3630. > If we can confirm that 3630 works with the higher values > reliably we can add further detection. BTW, I'm also seeing this warning on 3730-evm it may be related: [ 3.523101] ------------[ cut here ]------------ [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c() [ 3.538360] clk rate mismatch: 108000000 != 115200000 [ 3.543518] Modules linked in: [ 3.546966] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.15.0-rc3-00015-gaa296fa-dirty #391 [ 3.557159] Workqueue: deferwq deferred_probe_work_func [ 3.562774] [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14) [ 3.571014] [<c001191c>] (show_stack) from [<c05660b4>] (dump_stack+0x80/0x9c) [ 3.578704] [<c05660b4>] (dump_stack) from [<c003f558>] (warn_slowpath_common+0x68/0x8c) [ 3.587249] [<c003f558>] (warn_slowpath_common) from [<c003f610>] (warn_slowpath_fmt+0x30/0x40) [ 3.596496] [<c003f610>] (warn_slowpath_fmt) from [<c03129f0>] (dss_set_fck_rate+0x6c/0x8c) [ 3.605407] [<c03129f0>] (dss_set_fck_rate) from [<c0323728>] (dpi_display_enable+0x23c/0x2e4) [ 3.614562] [<c0323728>] (dpi_display_enable) from [<c03323a8>] (sharp_ls_enable+0x58/0xc4) [ 3.623474] [<c03323a8>] (sharp_ls_enable) from [<c0335ee0>] (omapfb_probe+0x548/0x848) [ 3.631988] [<c0335ee0>] (omapfb_probe) from [<c0378cfc>] (platform_drv_probe+0x18/0x48) [ 3.640594] [<c0378cfc>] (platform_drv_probe) from [<c0377938>] (driver_probe_device+0x110/0x22c) [ 3.650024] [<c0377938>] (driver_probe_device) from [<c0376038>] (bus_for_each_drv+0x44/0x8c) [ 3.659088] [<c0376038>] (bus_for_each_drv) from [<c03777f0>] (device_attach+0x74/0x8c) [ 3.667541] [<c03777f0>] (device_attach) from [<c0376ecc>] (bus_probe_device+0x88/0xb0) [ 3.676025] [<c0376ecc>] (bus_probe_device) from [<c03772d0>] (deferred_probe_work_func+0x64/0x94) [ 3.685546] [<c03772d0>] (deferred_probe_work_func) from [<c0057220>] (process_one_work+0x1b4/0x4bc) [ 3.695251] [<c0057220>] (process_one_work) from [<c0057908>] (worker_thread+0x11c/0x398) [ 3.704620] [<c0057908>] (worker_thread) from [<c005df10>] (kthread+0xc8/0xe4) [ 3.712280] [<c005df10>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c) [ 3.719909] ---[ end trace 1c9526c1a2975498 ]--- > Signed-off-by: Tony Lindgren <tony@atomide.com> > --- > drivers/video/fbdev/omap2/dss/dss.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c > index d55266c..ad6561f 100644 > --- a/drivers/video/fbdev/omap2/dss/dss.c > +++ b/drivers/video/fbdev/omap2/dss/dss.c > @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = { > .dpi_select_source = &dss_dpi_select_source_omap2_omap3, > }; > > +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */ > static const struct dss_features omap3630_dss_feats __initconst = { > - .fck_div_max = 32, > - .dss_fck_multiplier = 1, > + .fck_div_max = 16, > + .dss_fck_multiplier = 2, > .parent_clk_name = "dpll4_ck", > .dpi_select_source = &dss_dpi_select_source_omap2_omap3, > }; > -- > 1.8.1.1 > > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 30/04/14 02:52, Tony Lindgren wrote: > Otherwise we can get often errors like the following and the > display won't come on: > > omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay > omapdss APPLY error: SYNC_LOST on channel lcd, restarting > the output with video overlays disabled > > There are some earlier references to this issue: > > http://www.spinics.net/lists/linux-omap/msg59511.html > http://www.spinics.net/lists/linux-omap/msg59724.html Those don't sound like the same issue, but it's hard to say. What kind of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and without this patch? What resolution do you have? If it's a very high resolution (say, DVI output to a monitor), it could just be an issue of not-enough-memory-bandwidth. > It seems that it's safe to set the lower values even for 3630. > If we can confirm that 3630 works with the higher values > reliably we can add further detection. > > Signed-off-by: Tony Lindgren <tony@atomide.com> > --- > drivers/video/fbdev/omap2/dss/dss.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c > index d55266c..ad6561f 100644 > --- a/drivers/video/fbdev/omap2/dss/dss.c > +++ b/drivers/video/fbdev/omap2/dss/dss.c > @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = { > .dpi_select_source = &dss_dpi_select_source_omap2_omap3, > }; > > +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */ > static const struct dss_features omap3630_dss_feats __initconst = { > - .fck_div_max = 32, > - .dss_fck_multiplier = 1, > + .fck_div_max = 16, > + .dss_fck_multiplier = 2, These values tell about the clock hardware, they are not settings that can be changed to change the clock. OMAP3630 has a fixed x2 multiplier and a divider with maximum value of 16. Tomi
On 09/05/14 02:20, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [140429 16:53]: >> Otherwise we can get often errors like the following and the >> display won't come on: >> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting >> the output with video overlays disabled >> >> There are some earlier references to this issue: >> >> http://www.spinics.net/lists/linux-omap/msg59511.html >> http://www.spinics.net/lists/linux-omap/msg59724.html >> >> It seems that it's safe to set the lower values even for 3630. >> If we can confirm that 3630 works with the higher values >> reliably we can add further detection. > > BTW, I'm also seeing this warning on 3730-evm it may be related: > > [ 3.523101] ------------[ cut here ]------------ > [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c() > [ 3.538360] clk rate mismatch: 108000000 != 115200000 > [ 3.543518] Modules linked in: Hmm... Can you paste the clk_summary from debugfs? Somehow the clock framework calculates the clock rate differently than the dss. Or do we have different clock.dts files used for 3730 and 3630? Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:39]: > On 30/04/14 02:52, Tony Lindgren wrote: > > Otherwise we can get often errors like the following and the > > display won't come on: > > > > omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay > > omapdss APPLY error: SYNC_LOST on channel lcd, restarting > > the output with video overlays disabled > > > > There are some earlier references to this issue: > > > > http://www.spinics.net/lists/linux-omap/msg59511.html > > http://www.spinics.net/lists/linux-omap/msg59724.html > > Those don't sound like the same issue, but it's hard to say. What kind > of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and > without this patch? Without this patch: # cat /sys/kernel/debug/omapdss/clk [ 24.833831] DSS: dss_runtime_get [ 24.837554] DSS: dss_runtime_put [ 24.840972] DISPC: dispc_runtime_get [ 24.844757] DISPC: dispc_runtime_put - DSS - DSS_FCK (DSS1_ALWON_FCLK) = 57600000 - DISPC - dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) fck 57600000 - LCD - LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) lck 57600000 lck div 1 pck 19200000 pck div 3 With this patch: # cat /sys/kernel/debug/omapdss/clk [ 34.580688] DSS: dss_runtime_get [ 34.584197] DSS: dss_runtime_put [ 34.587768] DISPC: dispc_runtime_get [ 34.591552] DISPC: dispc_runtime_put - DSS - DSS_FCK (DSS1_ALWON_FCLK) = 108000000 - DISPC - dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) fck 108000000 - LCD - LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) lck 108000000 lck div 1 pck 18000000 pck div 6 > What resolution do you have? If it's a very high resolution (say, DVI > output to a monitor), it could just be an issue of > not-enough-memory-bandwidth. This is just the 3730-evm with the Sharp VGA panel mentioned in this series. > > It seems that it's safe to set the lower values even for 3630. > > If we can confirm that 3630 works with the higher values > > reliably we can add further detection. > > > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > --- > > drivers/video/fbdev/omap2/dss/dss.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c > > index d55266c..ad6561f 100644 > > --- a/drivers/video/fbdev/omap2/dss/dss.c > > +++ b/drivers/video/fbdev/omap2/dss/dss.c > > @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = { > > .dpi_select_source = &dss_dpi_select_source_omap2_omap3, > > }; > > > > +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */ > > static const struct dss_features omap3630_dss_feats __initconst = { > > - .fck_div_max = 32, > > - .dss_fck_multiplier = 1, > > + .fck_div_max = 16, > > + .dss_fck_multiplier = 2, > > These values tell about the clock hardware, they are not settings that > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier > and a divider with maximum value of 16. > > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:02]: > On 09/05/14 02:20, Tony Lindgren wrote: > > * Tony Lindgren <tony@atomide.com> [140429 16:53]: > >> Otherwise we can get often errors like the following and the > >> display won't come on: > >> > >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay > >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting > >> the output with video overlays disabled > >> > >> There are some earlier references to this issue: > >> > >> http://www.spinics.net/lists/linux-omap/msg59511.html > >> http://www.spinics.net/lists/linux-omap/msg59724.html > >> > >> It seems that it's safe to set the lower values even for 3630. > >> If we can confirm that 3630 works with the higher values > >> reliably we can add further detection. > > > > BTW, I'm also seeing this warning on 3730-evm it may be related: > > > > [ 3.523101] ------------[ cut here ]------------ > > [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c() > > [ 3.538360] clk rate mismatch: 108000000 != 115200000 > > [ 3.543518] Modules linked in: > > Hmm... Can you paste the clk_summary from debugfs? Somehow the clock > framework calculates the clock rate differently than the dss. Or do we > have different clock.dts files used for 3730 and 3630? OK pasted to the other email in this thread. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > On 30/04/14 02:52, Tony Lindgren wrote: >> Otherwise we can get often errors like the following and the >> display won't come on: >> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting >> the output with video overlays disabled >> >> There are some earlier references to this issue: >> >> http://www.spinics.net/lists/linux-omap/msg59511.html >> http://www.spinics.net/lists/linux-omap/msg59724.html > resend - my client had HTML enabled... FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had still the reboot problem on old 600MHz OMAP 3530. Applying this patch solved the issues. For other versions I had no chance to reproduce the original wakup issue mentioned in old thread [1] http://marc.info/?l=linux-omap&m=136250904607413&w=2 Andreas > Those don't sound like the same issue, but it's hard to say. What kind > of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and > without this patch? > > What resolution do you have? If it's a very high resolution (say, DVI > output to a monitor), it could just be an issue of > not-enough-memory-bandwidth. > >> It seems that it's safe to set the lower values even for 3630. >> If we can confirm that 3630 works with the higher values >> reliably we can add further detection. >> >> Signed-off-by: Tony Lindgren <tony@atomide.com> >> --- >> drivers/video/fbdev/omap2/dss/dss.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c >> index d55266c..ad6561f 100644 >> --- a/drivers/video/fbdev/omap2/dss/dss.c >> +++ b/drivers/video/fbdev/omap2/dss/dss.c >> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = { >> .dpi_select_source = &dss_dpi_select_source_omap2_omap3, >> }; >> >> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */ >> static const struct dss_features omap3630_dss_feats __initconst = { >> - .fck_div_max = 32, >> - .dss_fck_multiplier = 1, >> + .fck_div_max = 16, >> + .dss_fck_multiplier = 2, > > These values tell about the clock hardware, they are not settings that > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier > and a divider with maximum value of 16. > > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]: > On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > > On 30/04/14 02:52, Tony Lindgren wrote: > >> Otherwise we can get often errors like the following and the > >> display won't come on: > >> > >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay > >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting > >> the output with video overlays disabled > >> > >> There are some earlier references to this issue: > >> > >> http://www.spinics.net/lists/linux-omap/msg59511.html > >> http://www.spinics.net/lists/linux-omap/msg59724.html > > > resend - my client had HTML enabled... > > FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had > still the reboot problem on old 600MHz OMAP 3530. Applying this patch > solved the issues. For other versions I had no chance to reproduce the > original wakup issue mentioned in old thread Sorry I'm a bit confused now. Is the reboot issue a separate issue related to the twl4030 generic scripts for 3530? And then this patch fixes dm3730 wake-up (from suspend?) issues? Or do we have some other bug where we wrongly hit omap3630_dss_feats on 3530 somehow? Regards, Tony > [1] http://marc.info/?l=linux-omap&m=136250904607413&w=2 > > Andreas > > Those don't sound like the same issue, but it's hard to say. What kind > > of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and > > without this patch? > > > > What resolution do you have? If it's a very high resolution (say, DVI > > output to a monitor), it could just be an issue of > > not-enough-memory-bandwidth. > > > >> It seems that it's safe to set the lower values even for 3630. > >> If we can confirm that 3630 works with the higher values > >> reliably we can add further detection. > >> > >> Signed-off-by: Tony Lindgren <tony@atomide.com> > >> --- > >> drivers/video/fbdev/omap2/dss/dss.c | 5 +++-- > >> 1 file changed, 3 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c > >> index d55266c..ad6561f 100644 > >> --- a/drivers/video/fbdev/omap2/dss/dss.c > >> +++ b/drivers/video/fbdev/omap2/dss/dss.c > >> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = { > >> .dpi_select_source = &dss_dpi_select_source_omap2_omap3, > >> }; > >> > >> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */ > >> static const struct dss_features omap3630_dss_feats __initconst = { > >> - .fck_div_max = 32, > >> - .dss_fck_multiplier = 1, > >> + .fck_div_max = 16, > >> + .dss_fck_multiplier = 2, > > > > These values tell about the clock hardware, they are not settings that > > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier > > and a divider with maximum value of 16. > > > > Tomi > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren <tony@atomide.com> wrote: > * Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]: >> On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: >> > On 30/04/14 02:52, Tony Lindgren wrote: >> >> Otherwise we can get often errors like the following and the >> >> display won't come on: >> >> >> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay >> >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting >> >> the output with video overlays disabled >> >> >> >> There are some earlier references to this issue: >> >> >> >> http://www.spinics.net/lists/linux-omap/msg59511.html >> >> http://www.spinics.net/lists/linux-omap/msg59724.html >> > >> resend - my client had HTML enabled... >> >> FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had >> still the reboot problem on old 600MHz OMAP 3530. Applying this patch >> solved the issues. For other versions I had no chance to reproduce the >> original wakup issue mentioned in old thread > > Sorry I'm a bit confused now. Is the reboot issue a separate issue > related to the twl4030 generic scripts for 3530? > > And then this patch fixes dm3730 wake-up (from suspend?) issues? > > Or do we have some other bug where we wrongly hit omap3630_dss_feats > on 3530 somehow? (What I think) I have done: Have 3.14.3 still booting with legacy board init (please don't kill me for that). Without applying your patch old OMAP3530 crashed at every reboot with SYNCH_LOST. After applying your patch reboot works fine. Looking into id-code makes me wonder what changes on 36xx-features do to 35xx devices (treated as 34xx - right?). The only way that this happens is for unknown hawkeye fallthough. I suggest you simply forget my note and I will find out what really 'fixed' dss reboot problem. Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/05/14 17:37, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:39]: >> On 30/04/14 02:52, Tony Lindgren wrote: >>> Otherwise we can get often errors like the following and the >>> display won't come on: >>> >>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay >>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting >>> the output with video overlays disabled >>> >>> There are some earlier references to this issue: >>> >>> http://www.spinics.net/lists/linux-omap/msg59511.html >>> http://www.spinics.net/lists/linux-omap/msg59724.html >> >> Those don't sound like the same issue, but it's hard to say. What kind >> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and >> without this patch? > > Without this patch: > # cat /sys/kernel/debug/omapdss/clk > [ 24.833831] DSS: dss_runtime_get > [ 24.837554] DSS: dss_runtime_put > [ 24.840972] DISPC: dispc_runtime_get > [ 24.844757] DISPC: dispc_runtime_put > - DSS - > DSS_FCK (DSS1_ALWON_FCLK) = 57600000 > - DISPC - > dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) > fck 57600000 > - LCD - > LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) > lck 57600000 lck div 1 > pck 19200000 pck div 3 > > > With this patch: > # cat /sys/kernel/debug/omapdss/clk > [ 34.580688] DSS: dss_runtime_get > [ 34.584197] DSS: dss_runtime_put > [ 34.587768] DISPC: dispc_runtime_get > [ 34.591552] DISPC: dispc_runtime_put > - DSS - > DSS_FCK (DSS1_ALWON_FCLK) = 108000000 > - DISPC - > dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) > fck 108000000 > - LCD - > LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) > lck 108000000 lck div 1 > pck 18000000 pck div 6 > >> What resolution do you have? If it's a very high resolution (say, DVI >> output to a monitor), it could just be an issue of >> not-enough-memory-bandwidth. > > This is just the 3730-evm with the Sharp VGA panel mentioned in > this series. Hmm, well, those both look fine. The fck is well below the maximum, which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher with this patch, but that should affect the GFX overlay. So you're just booting, and there are no applications that use the framebuffer? And there is no rotation or such configured? Tomi
On 09/05/14 17:37, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:02]: >> On 09/05/14 02:20, Tony Lindgren wrote: >>> * Tony Lindgren <tony@atomide.com> [140429 16:53]: >>>> Otherwise we can get often errors like the following and the >>>> display won't come on: >>>> >>>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay >>>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting >>>> the output with video overlays disabled >>>> >>>> There are some earlier references to this issue: >>>> >>>> http://www.spinics.net/lists/linux-omap/msg59511.html >>>> http://www.spinics.net/lists/linux-omap/msg59724.html >>>> >>>> It seems that it's safe to set the lower values even for 3630. >>>> If we can confirm that 3630 works with the higher values >>>> reliably we can add further detection. >>> >>> BTW, I'm also seeing this warning on 3730-evm it may be related: >>> >>> [ 3.523101] ------------[ cut here ]------------ >>> [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c() >>> [ 3.538360] clk rate mismatch: 108000000 != 115200000 >>> [ 3.543518] Modules linked in: >> >> Hmm... Can you paste the clk_summary from debugfs? Somehow the clock >> framework calculates the clock rate differently than the dss. Or do we >> have different clock.dts files used for 3730 and 3630? > > OK pasted to the other email in this thread. I mean the debugs for clock framework. The above warning means that the clock framework says the clock rate is X, but the dss had calculated that it should be Y. So there's a difference how the clock framework calculates the rate and how the dss calculates it. And yes, dss shouldn't calculate it. But I don't know how to get good pixel clocks if we didn't. Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]: > On 09/05/14 17:37, Tony Lindgren wrote: > > > > This is just the 3730-evm with the Sharp VGA panel mentioned in > > this series. > > Hmm, well, those both look fine. The fck is well below the maximum, > which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher > with this patch, but that should affect the GFX overlay. > > So you're just booting, and there are no applications that use the > framebuffer? And there is no rotation or such configured? Right. The rotation is set to 3 though. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Andreas Müller <schnitzeltony@googlemail.com> [140512 01:20]: > On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren <tony@atomide.com> wrote: > > * Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]: > >> On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > >> > On 30/04/14 02:52, Tony Lindgren wrote: > >> >> Otherwise we can get often errors like the following and the > >> >> display won't come on: > >> >> > >> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay > >> >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting > >> >> the output with video overlays disabled > >> >> > >> >> There are some earlier references to this issue: > >> >> > >> >> http://www.spinics.net/lists/linux-omap/msg59511.html > >> >> http://www.spinics.net/lists/linux-omap/msg59724.html > >> > > >> resend - my client had HTML enabled... > >> > >> FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had > >> still the reboot problem on old 600MHz OMAP 3530. Applying this patch > >> solved the issues. For other versions I had no chance to reproduce the > >> original wakup issue mentioned in old thread > > > > Sorry I'm a bit confused now. Is the reboot issue a separate issue > > related to the twl4030 generic scripts for 3530? > > > > And then this patch fixes dm3730 wake-up (from suspend?) issues? > > > > Or do we have some other bug where we wrongly hit omap3630_dss_feats > > on 3530 somehow? > (What I think) I have done: Have 3.14.3 still booting with legacy > board init (please don't kill me for that). Without applying your > patch old OMAP3530 crashed at every reboot with SYNCH_LOST. > > After applying your patch reboot works fine. > > Looking into id-code makes me wonder what changes on 36xx-features do > to 35xx devices (treated as 34xx - right?). The only way that this > happens is for unknown hawkeye fallthough. I suggest you simply forget > my note and I will find out what really 'fixed' dss reboot problem. Yeah 35xx should be treated as 34xx so sounds like there might be some detection problem if this patch does something for your board. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/05/14 17:39, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]: >> On 09/05/14 17:37, Tony Lindgren wrote: >>> >>> This is just the 3730-evm with the Sharp VGA panel mentioned in >>> this series. >> >> Hmm, well, those both look fine. The fck is well below the maximum, >> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher >> with this patch, but that should affect the GFX overlay. >> >> So you're just booting, and there are no applications that use the >> framebuffer? And there is no rotation or such configured? > > Right. The rotation is set to 3 though. Hmm, that's probably the issue then. VRFB rotation is very heavy on the memory bandwidth, and is generally a very easy way to get sync lost errors. My opinion is that VRFB should only be used when you know your system will handle it fine with the clock rates and bandwidth usage you have for your use cases. Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:45]: > On 12/05/14 17:39, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]: > >> On 09/05/14 17:37, Tony Lindgren wrote: > >>> > >>> This is just the 3730-evm with the Sharp VGA panel mentioned in > >>> this series. > >> > >> Hmm, well, those both look fine. The fck is well below the maximum, > >> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher > >> with this patch, but that should affect the GFX overlay. > >> > >> So you're just booting, and there are no applications that use the > >> framebuffer? And there is no rotation or such configured? > > > > Right. The rotation is set to 3 though. > > Hmm, that's probably the issue then. VRFB rotation is very heavy on the > memory bandwidth, and is generally a very easy way to get sync lost errors. I found another case without rotation where the error always triggers. By forcing 3730-evm LCD panel to QVGA mode it always seems to happen even without rotation. Without this patch with errors and no image: # cat /sys/kernel/debug/omapdss/clk [ 55.185729] DSS: dss_runtime_get [ 55.189422] DSS: dss_runtime_put [ 55.192810] DISPC: dispc_runtime_get [ 55.196685] DISPC: dispc_runtime_put - DSS - DSS_FCK (DSS1_ALWON_FCLK) = 27000000 - DISPC - dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) fck 27000000 - LCD - LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) lck 27000000 lck div 1 pck 5400000 pck div 5 With this patch without errors and penguin showing: # cat /sys/kernel/debug/omapdss/clk [ 19.905792] DSS: dss_runtime_get [ 19.909545] DSS: dss_runtime_put [ 19.912933] DISPC: dispc_runtime_get [ 19.916778] DISPC: dispc_runtime_put - DSS - DSS_FCK (DSS1_ALWON_FCLK) = 108000000 - DISPC - dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) fck 108000000 - LCD - LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) lck 108000000 lck div 1 pck 5400000 pck div 20 In this case the errors are different too: DISPC: channel 0 xres 240 yres 320 DISPC: pck 5400000 DISPC: hsw 3 hfp 3 hbp 39 vsw 1 vfp 2 vbp 7 DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1 de_level 0 sync_pclk_edge 0 DISPC: hsync 18947Hz, vsync 57Hz DISPC: lck = 27000000 (1) DISPC: pck = 5400000 (5) APPLY: DISPC IRQ: 0x60: GFX_FIFO_UNDERFLOW APPLY: DISPC IRQ: 0x4062: GFX_FIFO_UNDERFLOW SYNC_LOST DISPC: dispc_runtime_get omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay Regarding rotation, it does look like that with VGA mode enabling rotation makes the error trigger quite often on 3730. > will handle it fine with the clock rates and bandwidth usage you have > for your use cases. I don't think it's all because of rotation. And rotating my head makes my neck hurt! Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13/05/14 18:26, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:45]: >> On 12/05/14 17:39, Tony Lindgren wrote: >>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]: >>>> On 09/05/14 17:37, Tony Lindgren wrote: >>>>> >>>>> This is just the 3730-evm with the Sharp VGA panel mentioned in >>>>> this series. >>>> >>>> Hmm, well, those both look fine. The fck is well below the maximum, >>>> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher >>>> with this patch, but that should affect the GFX overlay. >>>> >>>> So you're just booting, and there are no applications that use the >>>> framebuffer? And there is no rotation or such configured? >>> >>> Right. The rotation is set to 3 though. >> >> Hmm, that's probably the issue then. VRFB rotation is very heavy on the >> memory bandwidth, and is generally a very easy way to get sync lost errors. > > I found another case without rotation where the error always triggers. > By forcing 3730-evm LCD panel to QVGA mode it always seems to happen > even without rotation. > > Without this patch with errors and no image: > > # cat /sys/kernel/debug/omapdss/clk > [ 55.185729] DSS: dss_runtime_get > [ 55.189422] DSS: dss_runtime_put > [ 55.192810] DISPC: dispc_runtime_get > [ 55.196685] DISPC: dispc_runtime_put > - DSS - > DSS_FCK (DSS1_ALWON_FCLK) = 27000000 > - DISPC - > dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) > fck 27000000 > - LCD - > LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) > lck 27000000 lck div 1 > pck 5400000 pck div 5 > > With this patch without errors and penguin showing: > > # cat /sys/kernel/debug/omapdss/clk > [ 19.905792] DSS: dss_runtime_get > [ 19.909545] DSS: dss_runtime_put > [ 19.912933] DISPC: dispc_runtime_get > [ 19.916778] DISPC: dispc_runtime_put > - DSS - > DSS_FCK (DSS1_ALWON_FCLK) = 108000000 > - DISPC - > dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) > fck 108000000 > - LCD - > LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) > lck 108000000 lck div 1 > pck 5400000 pck div 20 > > In this case the errors are different too: > > DISPC: channel 0 xres 240 yres 320 > DISPC: pck 5400000 > DISPC: hsw 3 hfp 3 hbp 39 vsw 1 vfp 2 vbp 7 > DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1 de_level 0 sync_pclk_edge 0 > DISPC: hsync 18947Hz, vsync 57Hz > DISPC: lck = 27000000 (1) > DISPC: pck = 5400000 (5) > APPLY: DISPC IRQ: 0x60: GFX_FIFO_UNDERFLOW > APPLY: DISPC IRQ: 0x4062: GFX_FIFO_UNDERFLOW SYNC_LOST > DISPC: dispc_runtime_get > omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay I'm quite out of ideas... The pixel clock is so low that underflow shouldn't really happen. I was trying to find 3730 documentation that would describe the PRCM's multipliers and dividers for DSS (i.e. the ones you change in this patch), but I didn't find anything. Maybe the DSS clock's fixed multiplier has been changed for 3730. But in that case our .dts files related to the clocks are wrong too. The clock nodes related to this are dpll4_m4x2_mul_ck, which is corresponds to the "dss_fck_multiplier" value in omapdss, and dpll4_m4_ck, which corresponds to the "fck_div_max" value. One thing to try out is, without this patch, change CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK to force the dss func clock higher. With QVGA mode, you could try, say, value of 19, which should make sure the fck is at least 19 times higher than pck. > Regarding rotation, it does look like that with VGA mode enabling > rotation makes the error trigger quite often on 3730. > >> will handle it fine with the clock rates and bandwidth usage you have >> for your use cases. > > I don't think it's all because of rotation. And rotating my head No, probably not. The pixel clocks are so low that the rotation should work fine. Except if there's something wrong the the VRFB or the memory bus, which make the VRFB rotation not work even with low pixel clocks. > makes my neck hurt! You need to learn to hold the device a bit differently! Tomi
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c index d55266c..ad6561f 100644 --- a/drivers/video/fbdev/omap2/dss/dss.c +++ b/drivers/video/fbdev/omap2/dss/dss.c @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = { .dpi_select_source = &dss_dpi_select_source_omap2_omap3, }; +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */ static const struct dss_features omap3630_dss_feats __initconst = { - .fck_div_max = 32, - .dss_fck_multiplier = 1, + .fck_div_max = 16, + .dss_fck_multiplier = 2, .parent_clk_name = "dpll4_ck", .dpi_select_source = &dss_dpi_select_source_omap2_omap3, };
Otherwise we can get often errors like the following and the display won't come on: omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay omapdss APPLY error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled There are some earlier references to this issue: http://www.spinics.net/lists/linux-omap/msg59511.html http://www.spinics.net/lists/linux-omap/msg59724.html It seems that it's safe to set the lower values even for 3630. If we can confirm that 3630 works with the higher values reliably we can add further detection. Signed-off-by: Tony Lindgren <tony@atomide.com> --- drivers/video/fbdev/omap2/dss/dss.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)