From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jassi Brar <jaswinder.singh@linaro.org>
Cc: mythripk@ti.com, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, andy.green@linaro.org,
n-dechesne@ti.com
Subject: Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
Date: Tue, 26 Jun 2012 09:07:40 +0000 [thread overview]
Message-ID: <1340701660.24530.17.camel@deskari> (raw)
In-Reply-To: <CAJe_Zhev3V85K1jhj+W+d+0kv132MZ=-7rChhCLgtWO7WN4u1w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]
On Tue, 2012-06-26 at 14:02 +0530, Jassi Brar wrote:
> Something non-omapdss in vanilla breaks suspend/resume.
I was able to reproduce (probably) the same issue with omap3 overo. Does
this looks familiar:
[ 2267.140197] ------------[ cut here ]------------
[ 2267.145172] WARNING: at drivers/video/omap2/dss/dispc.c:377 dispc_runtime_get+0x60/0x7c [omapdss]
()
[ 2267.154846] Modules linked in: omapfb panel_generic_dpi omapdss cfbimgblt cfbfillrect cfbcopyarea
[last unloaded: omapdss]
[ 2267.166595] [<c001b61c>] (unwind_backtrace+0x0/0xf0) from [<c0040238>] (warn_slowpath_common+0x4c
/0x64)
[ 2267.176605] [<c0040238>] (warn_slowpath_common+0x4c/0x64) from [<c004026c>] (warn_slowpath_null+0
x1c/0x24)
[ 2267.186859] [<c004026c>] (warn_slowpath_null+0x1c/0x24) from [<bf0d7918>] (dispc_runtime_get+0x60
/0x7c [omapdss])
[ 2267.197814] [<bf0d7918>] (dispc_runtime_get+0x60/0x7c [omapdss]) from [<bf0e3148>] (omapdss_dpi_d
isplay_enable+0x48/0x230 [omapdss])
[ 2267.210479] [<bf0e3148>] (omapdss_dpi_display_enable+0x48/0x230 [omapdss]) from [<bf110034>] (gen
eric_dpi_panel_check_timings+0x30/0x7c [panel_generic_dpi])
[ 2267.225311] [<bf110034>] (generic_dpi_panel_check_timings+0x30/0x7c [panel_generic_dpi]) from [<b
f11008c>] (generic_dpi_panel_resume+0xc/0x1c [panel_generic_dpi])
[ 2267.240722] [<bf11008c>] (generic_dpi_panel_resume+0xc/0x1c [panel_generic_dpi]) from [<bf0de654>
] (dss_resume_device+0x28/0x40 [omapdss])
[ 2267.253936] [<bf0de654>] (dss_resume_device+0x28/0x40 [omapdss]) from [<c02bfb94>] (bus_for_each_
dev+0x50/0x7c)
[ 2267.264678] [<c02bfb94>] (bus_for_each_dev+0x50/0x7c) from [<c02c287c>] (platform_pm_resume+0x2c/
0x50)
[ 2267.274566] [<c02c287c>] (platform_pm_resume+0x2c/0x50) from [<c02c6da8>] (dpm_run_callback.clone
.7+0x30/0xb0)
[ 2267.285186] [<c02c6da8>] (dpm_run_callback.clone.7+0x30/0xb0) from [<c02c7b2c>] (device_resume+0x
c8/0x188)
[ 2267.295471] [<c02c7b2c>] (device_resume+0xc8/0x188) from [<c02c7f54>] (dpm_resume+0xfc/0x21c)
[ 2267.304534] [<c02c7f54>] (dpm_resume+0xfc/0x21c) from [<c02c8208>] (dpm_resume_end+0xc/0x18)
[ 2267.313507] [<c02c8208>] (dpm_resume_end+0xc/0x18) from [<c007fbcc>] (suspend_devices_and_enter+0
x15c/0x2d0)
[ 2267.323913] [<c007fbcc>] (suspend_devices_and_enter+0x15c/0x2d0) from [<c007fecc>] (pm_suspend+0x
18c/0x208)
[ 2267.334259] [<c007fecc>] (pm_suspend+0x18c/0x208) from [<c007f170>] (state_store+0x120/0x134)
[ 2267.343292] [<c007f170>] (state_store+0x120/0x134) from [<c0262850>] (kobj_attr_store+0x14/0x20)
[ 2267.352661] [<c0262850>] (kobj_attr_store+0x14/0x20) from [<c0169b6c>] (sysfs_write_file+0x100/0x
184)
[ 2267.362457] [<c0169b6c>] (sysfs_write_file+0x100/0x184) from [<c0109008>] (vfs_write+0xb4/0x148)
[ 2267.371795] [<c0109008>] (vfs_write+0xb4/0x148) from [<c0109290>] (sys_write+0x40/0x70)
[ 2267.380310] [<c0109290>] (sys_write+0x40/0x70) from [<c0013d60>] (ret_fast_syscall+0x0/0x3c)
[ 2267.389282] ---[ end trace 54fe7eea726ac84d ]---
[ 2267.394592] dpm_run_callback(): platform_pm_resume+0x0/0x50 returns -13
[ 2267.401641] PM: Device omapdss failed to resume: error -13
I don't remember seeing that with earlier kernel versions, but I'm not
100% sure.
Looking at the log, I can see that both DSS and DISPC runtime_resume
callbacks are called early, and successfully. Later the system resume
callback tries to enable the displays that were enabled when the system
went to suspend, which fails because dispc_runtime_get() returns -EACCES
(and pm_runtime_enabled() returns false).
Interestingly, during suspend dispc_runtime_put() is called, and at that
point pm_runtime_enabled() also returns false, but pm_runtime_put_sync()
still returns 0 instead of -EACCES.
I'll need to study this more, but I don't think this is a problem
related to omapdss's handling of runtime PM, but rather handling system
suspend. omapdss's handling of system suspend is in a rather bad state.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-26 9:07 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-23 8:18 [PATCH] OMAPDSS: Check if RPM enabled before trying to change state jaswinder.singh
2012-06-25 6:20 ` Tomi Valkeinen
2012-06-25 8:53 ` Jassi Brar
2012-06-25 9:30 ` Tomi Valkeinen
2012-06-25 12:39 ` Jassi Brar
2012-06-25 12:41 ` Tomi Valkeinen
2012-06-25 13:43 ` Jassi Brar
2012-06-25 13:49 ` Tomi Valkeinen
2012-06-25 17:18 ` Jassi Brar
2012-06-26 7:19 ` Tomi Valkeinen
2012-06-26 8:44 ` Jassi Brar
2012-06-26 8:40 ` Andy Green
2012-06-26 9:07 ` Tomi Valkeinen [this message]
2012-06-26 10:09 ` Jassi Brar
2012-06-26 12:03 ` Tomi Valkeinen
2012-06-26 14:52 ` Jassi Brar
2012-06-26 15:08 ` Tomi Valkeinen
2012-06-26 15:21 ` Jassi Brar
2012-06-26 15:11 ` Tomi Valkeinen
2012-06-26 17:13 ` Jassi Brar
2012-06-26 18:44 ` Tomi Valkeinen
2012-06-27 4:54 ` Jassi Brar
2012-06-27 5:58 ` Tomi Valkeinen
2012-06-27 7:53 ` Jassi Brar
2012-06-27 8:13 ` Tomi Valkeinen
2012-06-27 14:56 ` Jassi Brar
2012-06-28 6:41 ` Tomi Valkeinen
2012-06-28 7:58 ` Jassi Brar
2012-06-28 7:58 ` Tomi Valkeinen
2012-06-25 12:05 ` Grazvydas Ignotas
2012-06-25 12:30 ` Tomi Valkeinen
2012-06-25 12:54 ` Rajendra Nayak
2012-06-25 12:50 ` Tomi Valkeinen
2012-06-26 4:55 ` Rajendra Nayak
2012-06-26 13:02 ` Grazvydas Ignotas
2012-06-26 14:34 ` Alan Stern
2012-06-26 15:01 ` Tomi Valkeinen
2012-06-26 15:11 ` Alan Stern
2012-06-25 12:45 ` Jassi Brar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1340701660.24530.17.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=andy.green@linaro.org \
--cc=jaswinder.singh@linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mythripk@ti.com \
--cc=n-dechesne@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).