On Tue, Sep 18, 2012 at 5:02 PM, Felipe Balbi <balbi@xxxxxx> wrote: > On Tue, Sep 18, 2012 at 06:10:50PM +0530, Sourav Poddar wrote: >> Greg's tty-next is not booting on 2420 based N800. The failure is >> observed at serial init itself. The reason might be that n800 tries to >> resume even though it is not suspended before. >> >> Reported-by: Paul Walmsley <paul@xxxxxxxxx> >> Signed-off-by: Sourav Poddar <sourav.poddar@xxxxxx> > > FWIW: > > Reviewed-by: Felipe Balbi <balbi@xxxxxx> > > Paul does this fix the issue for you ? Note that it depends on a > previous patch Sourav sent [1] > > [1] http://marc.info/?l=linux-omap&m=134796819607889&w=2 > > There's one thing that gets my attention, though, why only n800 would > fail here ? > > I wonder if we should be using: > > pm_runtime_set_active(dev); > pm_runtime_get_enable(dev); > > to prevent our runtime_resume() to be called from probe, but Sourav > tested and it doesn't work on BeagleBoard, but it works on PandaBoard. > > Does it ring any bell ?? Well I guess it's normal resume callback is called during probe as pm_runtime_get_sync() is called there, and according to documentation [1], devices are assumed to be suspended before probe is called. According to [1], pm_runtime_set_active() should be called before pm_runtime_enable() to indicate to the core that device is active during probe if that's the case, I guess this means pm_runtime_get_sync() is not needed in that case, but I'm not sure what's the actual serial state during probe nowadays. [1] chapter 5 of Documentation/power/runtime_pm.txt: The initial runtime PM status of all devices is 'suspended', but it need not reflect the actual physical state of the device. Thus, if the device is initially active (i.e. it is able to process I/O), its runtime PM status must be changed to 'active', with the help of pm_runtime_set_active(), before pm_runtime_enable() is called for the device. -- Gražvydas -- 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
