Re: [PATCH 0/2] serial: sh-sci: Use pm_runtime_get_sync()/put()

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

Hey guys,

I stumbled over this one again and want to make sure we have a
conclusion here.

> The way I understand it, the problem this intends to fix is not the
> state the device ends up in, but that it needs to be powered while
> registers are read or written.

I agree.

> It seems to me that that the current "resume" code should work in that
> respect, because it changes the PM state to "on" in uart_resume_port()
> before any access to hardware registers takes place, so there is
> nothing that needs to be fixed.

Ack.

> That may be different for the "suspend" part, though, because it
> assumes that the PM state is "on", and I think that is what the patch
> asserts to not be a valid assumption anymore. It's hard to tell if
> that is true, though, because I cannot reproduce the issue here; it
> just works either way...

So, do we agree then that *if* there needs to be a fix for that, it
should be in uart_suspend_port() by adding some 'uart_change_pm' shortly
before accessing the ops-callbacks? I am not super-fit with the uart
layer, but can't we assume because of the "Nothing to do if the console
is not suspending"-if-block that (for SCIF at least) it means the port
is on because it _is_ the console?

(I wonder, though, if the OMAPs won't need such a fix because they seem
to use runtime_autosuspend, so their state might be off actually?)

Regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]