On Monday 25 June 2012 06:00 PM, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote:
quoted
On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen[off-list ref] wrote:
quoted
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.singh@linaro.org wrote:
quoted
Currenlty HDMI fails to come up in the suspend-resume path.
This patch helps that real-world scenario.
What is the problem there? It'd be good to explain the problem in the
patch description. Does the pm_runtime_get return -EACCES?
On slightly different but related issue, currently OMAPDSS always
spits lots of backtraces when it's compiled without CONFIG_PM_RUNTIME,
because pm_runtime_put* always return -ENOSYS without
CONFIG_PM_RUNTIME. So something like this patch proposes is needed, or
maybe WARN_ON should check for -ENOSYS, I don't know..
Hmm. I guess I'm missing some understanding about runtime PM. omapdss
uses runtime PM to enable the underlying DSS hardware. If there's no
runtime PM, how does the driver work? Or is it the job of
hwmod/omap_device to keep all the hardware always enabled if runtime PM
is not compiled in?
Yes, the below trick keeps all hwmods always enabled post the initial
setup if runtime PM is disabled.
from arch/arm/mach-omap2/io.c
static void __init omap_hwmod_init_postsetup(void)
{
u8 postsetup_state;
/* Set the default postsetup state for all hwmods */
#ifdef CONFIG_PM_RUNTIME
postsetup_state = _HWMOD_STATE_IDLE;
#else
postsetup_state = _HWMOD_STATE_ENABLED;
#endif
omap_hwmod_for_each(_set_hwmod_postsetup_state, &postsetup_state);
omap_pm_if_early_init();
}
Tomi