On Sat, 2023-10-14 at 10:41 +0100, Richard Purdie wrote:
> Brief summary:
>
> We're seeing an issue on x86_64 with 6.5.X where data appears to be
> left in the transmission buffer and not sent to the port on the second
> serial port (ttyS1) until we trigger it with intervention.
>
> Paul Gortmaker did some painful bisection over a few days down to:
>
> serial: core: Start managing serial controllers to enable runtime PM
> https://lore.kernel.org/linux-serial/[email protected]/T/#t
Having poked around a bit and knowing nothing about any of this, should
this bit of new code added in the above commit to __uart_start() in
serial_core.c:
/*
* Start TX if enabled, and kick runtime PM. If the device is not
* enabled, serial_port_runtime_resume() calls start_tx()
again
* after enabling the device.
*/
if (pm_runtime_active(&port_dev->dev))
port->ops->start_tx(port);
actually be something like:
if (pm_runtime_active(&port_dev->dev) ||
!pm_runtime_enabled(&port_dev->dev))
port->ops->start_tx(port);
since there are uarts that don't enable runtime PM?
I notice that 16550A I'm using doesn't set UART_CAP_RPM and since we
have data left in the xmit buffer (I managed to confirm that), it is as
if during init, there is a race between the serial probing and the
getty putting data in the buffer? If it weren't statrted, that would
explain things...
Keep in mind I know nothing about pm_runtime or serial/uarts so this is
guesswork on my part.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189113):
https://lists.openembedded.org/g/openembedded-core/message/189113
Mute This Topic: https://lists.openembedded.org/mt/101849211/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
