* Marc Murphy <marcmltd@xxxxxxxxxxx> [140205 15:20]:
> I have now stepped through most of the system as it goes into the sleep state. It will transition into omap34xx_cpu_suspend and eventually work itself into an endless loop.
>
> I have then taken a step back to see the config of the system and all kernel options seem to be correct with power management.
>
> I then looked at the boot line, I am running tftp which should be a problem for the suspend to ram, and there is an option of nohlt :
> setenv bootargs console=${console},115200n8 ${mem_size} mpurate=${mpurate} ${video_mode} ${extra_options} root=${nfsroot} rootfstype=nfs ip=dhcp nohlt rw
>
> I was informed I needed to do this quite some time ago when I was having issue with the system booting. Upon reading the kernel-paramters doc I see that the description is what I am experiencing;
> nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
> wfi(ARM) instruction doesn't work correctly and not to
> use it. This is also useful when using JTAG debugger.
>
> OK so WFI doesn't work correctly, I have no WFI operating. If I remove the nohlt from the boot line the system freezes;
> [ 2.833587] voltdm_scale: No voltage scale API registered for vdd_core
> [ 2.840454] PM: no software I/O chain control; some wakeups may be lost
> [ 2.856536] davinci_emac davinci_emac.0: using random MAC addr: 86:2d:4d:a4:87:3e
It seems that this is a 3517 based issue, maybe the davinci_emac driver
won't work properly with runtime PM?
Tony
--
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
