* Andy Shevchenko <andy.shevchenko@xxxxxxxxx> [210930 07:18]: > On Thu, Sep 30, 2021 at 9:30 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > We can use the wakeup() and uart_start_pending_tx() calls to wake up an > > idle serial port and send out the pending TX buffer on runtime PM resume. > > > This allows us to remove the depedency to pm_runtime_irq_safe() for > > dependency > > > 8250_omap driver in the following patches. > > > > We manage the port runtime_suspended flag in the serial port driver as > > only the driver knows when the hardware is runtime PM suspended. Note that > > The current flag for rpm_tx_active cannot be used as it is TX specific > > for 8250_port. > > > > We already have serial8250_start_tx() call serial8250_rpm_get_tx(), and > > serial8250_stop_tx() call serial8250_rpm_put_tx() to take care of the > > runtime PM usage count for TX. To have the serial port driver call > > uart_start_pending_tx() on runtime resume, we must now use just > > pm_runtime_get() for serial8250_start_tx() instead of the sync version. > > > > With these changes we must now also flip 8250_omap driver over to call > > uart_start_pending_tx(). That's currently the only user of UART_CAP_RPM. > > Do I understand the flow correctly: > 1) if we suspended, we request resume > 2) until resume is not fulfilled we return error code to user space > to try again > ? Correct. I think the only thing we can currently do is return -EAGAIN when the serial port registers are not accessible. > In this case we have no register access to the powered off device and > ACPI, for example, may have a chance to resume the device in a > non-atomic way. Is this the correct interpretation? Yes that's correct. That works as long as the serial port device driver implements PM runtime resume function, and then at the end of it calls uart_start_pending_tx(). Regards, Tony
