Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 18, 2012 at 5:02 PM, Felipe Balbi [off-list ref] wrote:

On Tue, Sep 18, 2012 at 06:10:50PM +0530, Sourav Poddar wrote:

quoted

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@pwsan.com>
Signed-off-by: Sourav Poddar <redacted>

FWIW:

Reviewed-by: Felipe Balbi <redacted>

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html