* Andy Shevchenko <andy.shevchenko@xxxxxxxxx> [210930 07:11]: > On Thu, Sep 30, 2021 at 9:30 AM Tony Lindgren <tony@xxxxxxxxxxx> 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@xxxxxxxxxx>. > > ... > > > + 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
