Hello, Le 17/02/2022 à 09:08, Tony Lindgren a écrit : > * Romain Naour <romain.naour@xxxxxxxx> [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. I'm using ARCH_OMAP2PLUS_TYPICAL, so at least CONFIG_PM is selected. > > 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. On u-boot devicetree the uart4 node is missing, but we don't plan to use the gps from uboot :) Should I add the uart4 node? > > 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? Since removing the uart quirk had some other side effect, I did a shameless hack in 8250_omap.c to disable autosuspend. - pm_runtime_put_autosuspend(port->dev); + pm_runtime_dont_use_autosuspend(port->dev); With that the uart is always up and running. > 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. Indeed. But I'm not sure why the autosuspend is enabled by default? Best regards, Romain > > Regards, > > Tony
