Re: AM5749: tty serial 8250 omap driver crash

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux