lkml.org 
[lkml]   [2020]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] serial: 8250_port: Fix imprecise external abort for mctrl if inactive
    * Andy Shevchenko <andy.shevchenko@gmail.com> [200602 08:33]:
    > On Tue, Jun 2, 2020 at 11:09 AM Johan Hovold <johan@kernel.org> wrote:
    > > On Mon, Jun 01, 2020 at 05:18:13PM -0700, Tony Lindgren wrote:
    >
    > ...
    >
    > > There's shouldn't be anything fundamental preventing you from adding the
    > > missing resume calls to the mctrl paths even if it may require reworking
    > > (and fixing) the whole RPM implementation (which would be a good thing
    > > of course).
    >
    > Yes, for serial core I have long standing patch series to implement
    > RPM (more or less?) properly.

    Yeah let's try after the merge window.

    Not sure what else to do with the fix though. We currently have
    8250_port.c not really aware of the hardare state for PM runtime at
    least for the hang-up path.

    > However, OMAP is a beast which prevents us to go due to a big hack
    > called pm_runtime_irq_safe().
    > Tony is aware of this and I think the above is somehow related to removal of it.

    Now that we can detach and reattach the kernel serial console,
    there should not be any need for pm_runtime_irq_safe() anymore :)

    And the UART wake-up from deeper idle states can only happen with
    help of external hardware like GPIO controller or pinctrl controller.

    And for the always-on wake-up interrupt controllers we have the
    Linux generic wakeirqs to wake-up serial device on events.

    So I think the way to procedd with pm_runtime_irq_safe() removal
    for serial drivers is to block serial PM runtime unless we have a
    wakeirq configured for omaps in devicetree. In the worst case the
    regression is that PM runtime for serial won't work unless properly
    configured.

    And the UART wakeup latency will be a bit longer compared to
    pm_runtime_irq_safe() naturally.

    > But I completely agree that the goal is to get better runtime PM
    > implementation over all.

    Yes agreed.

    Regards,

    Tony

    \
     
     \ /
      Last update: 2020-06-02 15:37    [W:3.692 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site