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

[Grazvydas Ignotas]

On Tue, Sep 18, 2012 at 5:02 PM, Felipe Balbi <balbi at ti.com> 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 at pwsan.com>
>> Signed-off-by: Sourav Poddar <sourav.poddar at ti.com>
>
> FWIW:
>
> Reviewed-by: Felipe Balbi <balbi at ti.com>
>
> 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