On 27 June 2012 20:04, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > The current way how omapdss handles system suspend and resume is that > omapdss device (a platform device, which is not part of the device > hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses > the suspend and resume callbacks from platform_driver to handle system > suspend. It does this by disabling all enabled panels on suspend, and > resuming the previously disabled panels on resume. > > This presents a few problems. > > One is that as omapdss device is not related to the panel devices or the > DSS HW devices, there's no ordering in the suspend process. This means > that suspend could be first ran for DSS HW devices and panels, and only > then for omapdss device. Currently this is not a problem, as DSS HW > devices and panels do not handle suspend. > > Another, more pressing problem, is that when suspending or resuming, the > runtime PM functions return -EACCES as runtime PM is disabled during > system suspend. This causes the driver to print warnings, and operations > to fail as they think that they failed to bring up the HW. > > This patch changes the omapdss suspend handling to use PM notifiers, > which are called before suspend and after resume. This way we have a > normally functioning system when we are suspending and resuming the > panels. > > This patch, I believe, creates a problem that somebody could enable or > disable a panel between PM_SUSPEND_PREPARE and the system suspend, and > similarly the other way around in resume. I choose to ignore the problem > for now, as it sounds rather unlikely, and if it happens, it's not > fatal. > > In the long run the system suspend handling of omapdss and panels should > be thought out properly. The current approach feels rather hacky. > Perhaps the panel drivers should handle system suspend, or the users of > omapdss (omapfb, omapdrm) should handle system suspend. > > Note that after this patch we could probably revert > 0eaf9f52e94f756147dbfe1faf1f77a02378dbf9 (OMAPDSS: use sync versions of > pm_runtime_put). > I would think only DISPC should need the sync version. > But as I said, this patch may be temporary, so let's > leave the sync version still in place. > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx> > Reported-by: Jassi Brar <jaswinder.singh@xxxxxxxxxx> > Please feel free to add Tested-by: Jassi Brar <jaswinder.singh@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
