All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andy Shevchenko <andriy.shevchenko@intel.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	Johan Hovold <johan@kernel.org>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-serial@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] serial: core: Add wakeup() and start_pending_tx() for power management
Date: Thu, 30 Sep 2021 10:26:07 +0300	[thread overview]
Message-ID: <YVVmj9kJg9Mb5OR+@atomide.com> (raw)
In-Reply-To: <CAHp75Ve4RTSdbQYA_u8vs=U75KsNdrm9EqFASAGf4rFKSqVWvQ@mail.gmail.com>

* Andy Shevchenko <andy.shevchenko@gmail.com> [210930 07:11]:
> On Thu, Sep 30, 2021 at 9:30 AM Tony Lindgren <tony@atomide.com> wrote:
> >
> > If the serial driver implements PM runtime with autosuspend, the port may
> > be powered down on TX. To wake up the port, let's add new wakeup() call
> > for serial drivers to implement as needed. We can call wakeup() from
> > __uart_start() and flow control related functions before attempting to
> > write to the serial port registers.
> >
> > Let's keep track of the serial port with a new runtime_suspended flag
> > that the device driver runtime PM suspend and resume can manage with
> > atomic_set(). This is because only the device driver knows what the
> > device runtime PM state as in Documentation/power/runtime_pm.rst
> > under "9. Autosuspend, or automatically-delayed suspend" for locking.
> >
> > To allow the serial port drivers to send out pending tx on runtime PM
> > resume, let's add start_pending_tx() as suggested by Johan Hovold
> > <johan@kernel.org>.
> 
> ...
> 
> > +  wakeup(port)
> > +       Wake up port if it has been runtime PM suspended.
> > +
> > +       Locking: port->lock taken.
> > +
> > +       Interrupts: locally disabled.
> 
> > +       This call must not sleep
> 
> If it's suspended via ACPI methods, it can't be resumed here, right?

It should work for that too assuming the runtime PM resume function is
implemented.

> Only what we can do is to schedule a resume, but it means we may not
> access registers immediately after and we have to be sure that the
> device is resumed.

Yeah the only thing we do in the 8250_port wakeup() is schedule a
resume if needed. Then the 8250 port device driver can call
start_pending_tx() at the end of it's runtime PM resume function.

> Dead end?

I don't think so :) In serial_core we bail out on uart_port_wakeup()
errors before register access. But maybe I missed some more moles to
whack there :)

Regards,

Tony

  reply	other threads:[~2021-09-30  7:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  6:29 [PATCHv2 0/4] Get rid of pm_runtime_irq_safe() for 8250_omap Tony Lindgren
2021-09-30  6:29 ` [PATCH 1/4] serial: core: Add wakeup() and start_pending_tx() for power management Tony Lindgren
2021-09-30  7:10   ` Andy Shevchenko
2021-09-30  7:26     ` Tony Lindgren [this message]
2021-10-13 12:33   ` Greg Kroah-Hartman
2021-10-15  9:13     ` Tony Lindgren
2021-09-30  6:29 ` [PATCH 2/4] serial: 8250: Implement wakeup for TX and use it for 8250_omap Tony Lindgren
2021-09-30  7:17   ` Andy Shevchenko
2021-09-30  7:29     ` Tony Lindgren
2021-09-30  6:29 ` [PATCH 3/4] serial: 8250_omap: Require a valid wakeirq for deeper idle states Tony Lindgren
2021-09-30  6:29 ` [PATCH 4/4] serial: 8250_omap: Drop the use of pm_runtime_irq_safe() Tony Lindgren
  -- strict thread matches above, loose matches on Subject: below --
2021-10-15 11:26 [PATCHv3 0/4] Get rid of pm_runtime_irq_safe() for 8250_omap Tony Lindgren
2021-10-15 11:26 ` [PATCH 1/4] serial: core: Add wakeup() and start_pending_tx() for power management Tony Lindgren
2021-10-18  7:09   ` Johan Hovold
2021-10-21  6:32     ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YVVmj9kJg9Mb5OR+@atomide.com \
    --to=tony@atomide.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.