Re: AM5749: tty serial 8250 omap driver crash

[Tony Lindgren <tony@atomide.com>]

* Romain Naour <romain.naour@smile.fr> [220216 15:51]:
> Le 16/02/2022 à 12:46, Tony Lindgren a écrit :
> > Not really but if you can please test again with the ti-sysc patch,
> > 8250_omap patch and with your serdev uart dma disabled with
> > delete-property?
> 
> I had a crash but on close path:
> 
> [<c06af3b0>] (omap8250_set_mctrl) from [<c069fd38>] (uart_update_mctrl+0x3c/0x48)
> [<c069fd38>] (uart_update_mctrl) from [<c06a2ac8>] (uart_dtr_rts+0x54/0x9c)
> [<c06a2ac8>] (uart_dtr_rts) from [<c068b0d0>] (tty_port_shutdown+0x78/0x9c)
> [<c068b0d0>] (tty_port_shutdown) from [<c068b8ec>] (tty_port_close+0x3c/0x74)
> [<c068b8ec>] (tty_port_close) from [<c06b3b4c>] (ttyport_close+0x40/0x58)
> [<c06b3b4c>] (ttyport_close) from [<c092aca4>] (gnss_serial_close+0x14/0x24)
> [<c092aca4>] (gnss_serial_close) from [<c092a4a0>] (gnss_release+0x44/0x64)
> [<c092a4a0>] (gnss_release) from [<c036b7f4>] (__fput+0x78/0x23c)
> [<c036b7f4>] (__fput) from [<c0246308>] (task_work_run+0x90/0xbc)
> [<c0246308>] (task_work_run) from [<c0209c0c>] (do_work_pending+0x558/0x560)
> [<c0209c0c>] (do_work_pending) from [<c02000cc>] (slow_work_pending+0xc/0x20)
> 
> My test is starting gpsmon /dev/gnss0 several time.

OK sounds like a good test.

We can have two kind of issues, either runtime PM is not enabled, or
runtime PM is enabled but the uart registers have not been yet inialized.

On probe, omap8250_set_mctrl() can get called with runtime PM enabled, but
without omap8250_restore_regs() having been called yet. It seems we rely
on a bootloader initialized uart register state here currently.

We don't have omap8250_restore_regs() called on probe until at
omap_8250_set_termios(). But before we alread have this:

uart_add_one_port()
  uart_configure_port()
    omap8250_set_mctrl()

So that explains at least some issues. I'll take a look at what's the best
way to fix this.

I'm not quite sure why enabling dma on dra7 causes the clk disable errors,
maybe it's related to priv->delayed_restore set in some cases. Or some
different uart register init for dma.

For your issue with close, I wonder if it's related to autoidling the uarts?
The test script I posted does that for all the uarts, probably best not
to do that until the other issues are sorted out :) If so, maybe the issue
on close is that the uart has already autoidled.

Regards,

Tony