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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux