Ilya Yanok <yanok@xxxxxxxxxxx> writes:
> Current OMAP3 PM code seems to be incompatible with AM35{05,17} and
> leads to system hang during boot.
> Disable PM init on AM35{05,17} until working implementation will be
> merged.
Were you able to find out where exactly things got hung up?
We're trying hard to avoid adding more cpu_is_* checks so would like to
better understand the problem before merging such a fix.
Thanks,
Kevin
> Signed-off-by: Ilya Yanok <yanok@xxxxxxxxxxx>
> ---
> This patch solves the problem for me but I'm curious why simple
> CONFIG_PM disabling doesn't work? I'm getting
> Unhandled fault: external abort on non-linefetch
> while trying to access absolutely valid register from omapdss/venc
> driver. I've tried to disable VENC but then I got the same error
> from omap_wdt driver. Is it supposed to be so? Are !CONFIG_PM
> configurations supported? How comes that disabling CONFIG_PM
> makes some registers inaccessible?
>
> Regards, Ilya.
>
> arch/arm/mach-omap2/pm34xx.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index fc69875..0f30742 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -790,7 +790,7 @@ static int __init omap3_pm_init(void)
> struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
> int ret;
>
> - if (!cpu_is_omap34xx())
> + if (!cpu_is_omap34xx() || cpu_is_omap3505() || cpu_is_omap3517())
> return -ENODEV;
>
> if (!omap3_has_io_chain_ctrl())
--
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
