Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
On Wed, Jul 09, 2014 at 07:49:37PM +0200, Sebastian Andrzej Siewior wrote:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index bf06a4c..1cbfc8c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -263,6 +263,12 @@ static const struct serial8250_config uart_config[] = {
.fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO | UART_CAP_AFE,
},
+ [PORT_OMAP_16750] = {
+ .name = OMAP,
+ .fifo_size = 64,
+ .tx_loadsz = 64,
+ .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
+ },
[PORT_TEGRA] = {
.name = Tegra,
.fifo_size = 32,
@@ -1340,6 +1346,8 @@ static void serial8250_stop_rx(struct uart_port *port)
pm_runtime_get_sync(port-dev);
up-ier = ~UART_IER_RLSI;
+ if (port-type == PORT_OMAP_16750)
+ up-ier = ~UART_IER_RDI;
up-port.read_status_mask = ~UART_LSR_DR;
serial_port_out(port, UART_IER, up-ier);
Alan couldn't UART_IER_RDI be always cleared here with all port types?
Actually, shouldn't it be?
Then the custom port type PORT_OMAP_16750 would not be needed.
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
On 07/11/2014 08:41 AM, Tony Lindgren wrote: I tried this with am335x-evm, dra7-evm and beaglebone (omap5-uevm and am335x-evmsk didn't want to boot a kernel and omap4-blaze didn't even want to show MLO/U-boot) with the same result. None of these SoCs support off-idle with mainline kernel so testing with those is not enough :) Best to use some omap3 based device for testing this. So far I have verified that beagleboard xm, n900, and omap3730-evm all hit off-idle with v3.16-rc4. Unfortunately I don't have access to any of those devices. I had network up and configured. Was that okay? I also tried ifconfig eth0 down; sleep 10; ifconfig eth0 up to see if it works. That's fine for GPMC connected devices, devices with Ethernet on EHCI won't idle properly AFAIK. am33xx has proper ethernet (cpsw IP core on SoC and not something behind USB). That core_pwrdm shows only up on dra7. However with both drivers (mine and the current omap serial) the UART went down after three secs (as expected) and didn't accept any characters while writing on the console. If I wrote something on it via network (like echo a /dev/ttyO0) it came back and was working as long as I kept it busy. The thing is that RX does not wake it up. Any idea? If the RX pin does not wake it up, you need to configure the pinctrl-single entry for it, and configure that pin as a wake-up interrupt. See the interrupts-extended entry in omap3-beagle-xm.dts. This does not help. Checking the manual, there is not something like PIN_OFF_WAKEUPENABLE for am33xx. There is just INPUT/OUTPUT, pull up/down + enabled/disabled and the mux_mode. For the interrupt, the HW referenced as omap3_pmx_core touches some bits in the pinmux register which do not exists on am33xx. So I have nothing on HW around that could test wakeup scenario. Also, while it was I checked the core_pwrdm and I had ON:1 and OFF:0. So something is not right. Since Dra7 has some things missing I tried it on am335x with the same behavior. Should it work here? Yes only omap3 currently has the pieces needed for off-idle in the mainline kernel. Good to know. puh. So after staring a while at your backtrace I realized that shutdown startup callbacks are not overwritten properly. Well, thanks for that. Anyway, even serial8250_do_startup() has pm_runtime_get_sync() before first register access so I have no idea where this is coming from. Maybe because the console is enabled for that port? Maybe. But I would expect to explode around the console code. Anyway I fixed it up and prepare next batch. Regards, Tony Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140716 05:14]: On 07/11/2014 08:41 AM, Tony Lindgren wrote: If the RX pin does not wake it up, you need to configure the pinctrl-single entry for it, and configure that pin as a wake-up interrupt. See the interrupts-extended entry in omap3-beagle-xm.dts. This does not help. Checking the manual, there is not something like PIN_OFF_WAKEUPENABLE for am33xx. There is just INPUT/OUTPUT, pull up/down + enabled/disabled and the mux_mode. For the interrupt, the HW referenced as omap3_pmx_core touches some bits in the pinmux register which do not exists on am33xx. Right, on am33xx there's no IO chain wake-up path. AFAIK the only way to provide wake events on am33xx would be to mux the RX pin temporarily to a GPIO input. And sounds like that may work only if the GPIO is in the first GPIO bank that's always on. I don't know if the other GPIO banks on am33xx can provide wake up events. So I have nothing on HW around that could test wakeup scenario. Bummer :( I'll give it a try again for the next revision. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
On Wednesday 16 July 2014 06:02 PM, Tony Lindgren wrote: * Sebastian Andrzej Siewior bige...@linutronix.de [140716 05:14]: On 07/11/2014 08:41 AM, Tony Lindgren wrote: If the RX pin does not wake it up, you need to configure the pinctrl-single entry for it, and configure that pin as a wake-up interrupt. See the interrupts-extended entry in omap3-beagle-xm.dts. This does not help. Checking the manual, there is not something like PIN_OFF_WAKEUPENABLE for am33xx. There is just INPUT/OUTPUT, pull up/down + enabled/disabled and the mux_mode. For the interrupt, the HW referenced as omap3_pmx_core touches some bits in the pinmux register which do not exists on am33xx. Right, on am33xx there's no IO chain wake-up path. AFAIK the only way to provide wake events on am33xx would be to mux the RX pin temporarily to a GPIO input. And sounds like that may work only if the GPIO is in the first GPIO bank that's always on. I don't know if the other GPIO banks on am33xx can provide wake up events. No, they cannot. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140710 08:50]: On 07/10/2014 09:09 AM, Tony Lindgren wrote: You can test this pretty easily on beagleboard xm for example using v3.16-r4: I tried this with am335x-evm, dra7-evm and beaglebone (omap5-uevm and am335x-evmsk didn't want to boot a kernel and omap4-blaze didn't even want to show MLO/U-boot) with the same result. None of these SoCs support off-idle with mainline kernel so testing with those is not enough :) Best to use some omap3 based device for testing this. So far I have verified that beagleboard xm, n900, and omap3730-evm all hit off-idle with v3.16-rc4. 1. Compile the kernel using omap2plus_defconfig and enable your driver. USB EHCI needs to be disabled and OTG port should not have a USB cable connected. EHCI was already disabled in the config. OTG was not connected. OK 2. Boot with init=/bin/sh to keep user space timers to minimum at least until you have verified to hit off-idle I had network up and configured. Was that okay? I also tried ifconfig eth0 down; sleep 10; ifconfig eth0 up to see if it works. That's fine for GPMC connected devices, devices with Ethernet on EHCI won't idle properly AFAIK. 3. Enable UART timeouts with something like this. You may need to update it for ttyS, I just changed ttyO to ttyS here: #!/bin/bash uarts=$(find /sys/class/tty/ttyS*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyS*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode 4. Wait for UART to time out and verify you hit off-idle by looking at the debugfs entry: # cat /sys/kernel/debug/pm_debug/count ... core_pwrdm (ON),OFF:6,RET:0,INA:0,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 That core_pwrdm shows only up on dra7. However with both drivers (mine and the current omap serial) the UART went down after three secs (as expected) and didn't accept any characters while writing on the console. If I wrote something on it via network (like echo a /dev/ttyO0) it came back and was working as long as I kept it busy. The thing is that RX does not wake it up. Any idea? If the RX pin does not wake it up, you need to configure the pinctrl-single entry for it, and configure that pin as a wake-up interrupt. See the interrupts-extended entry in omap3-beagle-xm.dts. Also, while it was I checked the core_pwrdm and I had ON:1 and OFF:0. So something is not right. Since Dra7 has some things missing I tried it on am335x with the same behavior. Should it work here? Yes only omap3 currently has the pieces needed for off-idle in the mainline kernel. I just tried testing this, but did not get far on my omap3 evm: [5.445953] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 [5.453674] Internal error: : 1028 [#1] SMP ARM [5.458221] Modules linked in: [5.461334] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc4-6-gaab2c6a #98 [5.469024] task: ce058b00 ti: ce05a000 task.ti: ce05a000 [5.474456] PC is at mem32_serial_in+0xc/0x1c [5.478851] LR is at serial8250_do_startup+0xc8/0x89c [5.483917] pc : [c0346f90]lr : [c034ab2c]psr: 6113 [5.483917] sp : ce05bd10 ip : c0a0aba8 fp : ce275400 [5.495452] r10: r9 : cda7a680 r8 : ce27568c [5.500701] r7 : ce275400 r6 : r5 : ce280408 r4 : c10b6234 [5.507263] r3 : fb02 r2 : 0002 r1 : fb02 r0 : c10b6234 [5.513854] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [5.521179] Control: 10c5387d Table: 80004019 DAC: 0015 [5.526977] Process swapper/0 (pid: 1, stack limit = 0xce05a248) [5.532989] Stack: (0xce05bd10 to 0xce05c000) ... [5.734771] [c0346f90] (mem32_serial_in) from [c034ab2c] (serial8250_do_startup+0xc8/0x89c) [5.743530] [c034ab2c] (serial8250_do_startup) from [c03461f8] (uart_startup.part.3+0x7c/0x1dc) [5.752624] [c03461f8] (uart_startup.part.3) from [c0346d68] (uart_open+0xe4/0x124) [5.760681] [c0346d68] (uart_open) from [c032c19c] (tty_open+0x130/0x58c) [5.767852] [c032c19c] (tty_open) from [c01216f4] (chrdev_open+0x9c/0x174) [5.775115] [c01216f4] (chrdev_open) from [c011b8d4] (do_dentry_open+0x1d0/0x310) [5.783020] [c011b8d4] (do_dentry_open) from [c011bd98] (finish_open+0x34/0x4c) [5.790710] [c011bd98] (finish_open) from [c012a8f8] (do_last.isra.27+0x5a4/0xb98) [5.798675] [c012a8f8] (do_last.isra.27) from [c012afa0] (path_openat+0xb4/0x5e4) [5.806549] [c012afa0] (path_openat) from [c012b7dc] (do_filp_open+0x2c/0x80) [5.814086] [c012b7dc] (do_filp_open) from [c011cd14]
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140709 10:52]: v1…v2: - added runtime PM. Could somebody could plese double check this? I seems to be enabled and nothing explodes. However serial_omap_get_context_loss_count() enable_wakeup() are NULL pointer (in the omap-serial driver). So I am not sure how this supposed to work :) - added omap_8250_set_termios() You can test this pretty easily on beagleboard xm for example using v3.16-r4: 1. Compile the kernel using omap2plus_defconfig and enable your driver. USB EHCI needs to be disabled and OTG port should not have a USB cable connected. 2. Boot with init=/bin/sh to keep user space timers to minimum at least until you have verified to hit off-idle 3. Enable UART timeouts with something like this. You may need to update it for ttyS, I just changed ttyO to ttyS here: #!/bin/bash uarts=$(find /sys/class/tty/ttyS*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyS*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode 4. Wait for UART to time out and verify you hit off-idle by looking at the debugfs entry: # cat /sys/kernel/debug/pm_debug/count ... core_pwrdm (ON),OFF:6,RET:0,INA:0,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 ... I just tried testing this, but did not get far on my omap3 evm: [5.445953] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 [5.453674] Internal error: : 1028 [#1] SMP ARM [5.458221] Modules linked in: [5.461334] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc4-6-gaab2c6a #98 [5.469024] task: ce058b00 ti: ce05a000 task.ti: ce05a000 [5.474456] PC is at mem32_serial_in+0xc/0x1c [5.478851] LR is at serial8250_do_startup+0xc8/0x89c [5.483917] pc : [c0346f90]lr : [c034ab2c]psr: 6113 [5.483917] sp : ce05bd10 ip : c0a0aba8 fp : ce275400 [5.495452] r10: r9 : cda7a680 r8 : ce27568c [5.500701] r7 : ce275400 r6 : r5 : ce280408 r4 : c10b6234 [5.507263] r3 : fb02 r2 : 0002 r1 : fb02 r0 : c10b6234 [5.513854] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [5.521179] Control: 10c5387d Table: 80004019 DAC: 0015 [5.526977] Process swapper/0 (pid: 1, stack limit = 0xce05a248) [5.532989] Stack: (0xce05bd10 to 0xce05c000) ... [5.734771] [c0346f90] (mem32_serial_in) from [c034ab2c] (serial8250_do_startup+0xc8/0x89c) [5.743530] [c034ab2c] (serial8250_do_startup) from [c03461f8] (uart_startup.part.3+0x7c/0x1dc) [5.752624] [c03461f8] (uart_startup.part.3) from [c0346d68] (uart_open+0xe4/0x124) [5.760681] [c0346d68] (uart_open) from [c032c19c] (tty_open+0x130/0x58c) [5.767852] [c032c19c] (tty_open) from [c01216f4] (chrdev_open+0x9c/0x174) [5.775115] [c01216f4] (chrdev_open) from [c011b8d4] (do_dentry_open+0x1d0/0x310) [5.783020] [c011b8d4] (do_dentry_open) from [c011bd98] (finish_open+0x34/0x4c) [5.790710] [c011bd98] (finish_open) from [c012a8f8] (do_last.isra.27+0x5a4/0xb98) [5.798675] [c012a8f8] (do_last.isra.27) from [c012afa0] (path_openat+0xb4/0x5e4) [5.806549] [c012afa0] (path_openat) from [c012b7dc] (do_filp_open+0x2c/0x80) [5.814086] [c012b7dc] (do_filp_open) from [c011cd14] (do_sys_open+0x100/0x1d0) [5.821777] [c011cd14] (do_sys_open) from [c07b7ce0] (kernel_init_freeable+0x124/0x1c8) [5.830200] [c07b7ce0] (kernel_init_freeable) from [c054eb90] (kernel_init+0x8/0xe4) [5.838348] [c054eb90] (kernel_init) from [c000e868] (ret_from_fork+0x14/0x2c) Sounds like the clocks are not enabled properly? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
On 07/10/2014 09:09 AM, Tony Lindgren wrote: You can test this pretty easily on beagleboard xm for example using v3.16-r4: I tried this with am335x-evm, dra7-evm and beaglebone (omap5-uevm and am335x-evmsk didn't want to boot a kernel and omap4-blaze didn't even want to show MLO/U-boot) with the same result. 1. Compile the kernel using omap2plus_defconfig and enable your driver. USB EHCI needs to be disabled and OTG port should not have a USB cable connected. EHCI was already disabled in the config. OTG was not connected. 2. Boot with init=/bin/sh to keep user space timers to minimum at least until you have verified to hit off-idle I had network up and configured. Was that okay? I also tried ifconfig eth0 down; sleep 10; ifconfig eth0 up to see if it works. 3. Enable UART timeouts with something like this. You may need to update it for ttyS, I just changed ttyO to ttyS here: #!/bin/bash uarts=$(find /sys/class/tty/ttyS*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyS*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode 4. Wait for UART to time out and verify you hit off-idle by looking at the debugfs entry: # cat /sys/kernel/debug/pm_debug/count ... core_pwrdm (ON),OFF:6,RET:0,INA:0,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 That core_pwrdm shows only up on dra7. However with both drivers (mine and the current omap serial) the UART went down after three secs (as expected) and didn't accept any characters while writing on the console. If I wrote something on it via network (like echo a /dev/ttyO0) it came back and was working as long as I kept it busy. The thing is that RX does not wake it up. Any idea? Also, while it was I checked the core_pwrdm and I had ON:1 and OFF:0. So something is not right. Since Dra7 has some things missing I tried it on am335x with the same behavior. Should it work here? ... I just tried testing this, but did not get far on my omap3 evm: [5.445953] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 [5.453674] Internal error: : 1028 [#1] SMP ARM [5.458221] Modules linked in: [5.461334] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc4-6-gaab2c6a #98 [5.469024] task: ce058b00 ti: ce05a000 task.ti: ce05a000 [5.474456] PC is at mem32_serial_in+0xc/0x1c [5.478851] LR is at serial8250_do_startup+0xc8/0x89c [5.483917] pc : [c0346f90]lr : [c034ab2c]psr: 6113 [5.483917] sp : ce05bd10 ip : c0a0aba8 fp : ce275400 [5.495452] r10: r9 : cda7a680 r8 : ce27568c [5.500701] r7 : ce275400 r6 : r5 : ce280408 r4 : c10b6234 [5.507263] r3 : fb02 r2 : 0002 r1 : fb02 r0 : c10b6234 [5.513854] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [5.521179] Control: 10c5387d Table: 80004019 DAC: 0015 [5.526977] Process swapper/0 (pid: 1, stack limit = 0xce05a248) [5.532989] Stack: (0xce05bd10 to 0xce05c000) ... [5.734771] [c0346f90] (mem32_serial_in) from [c034ab2c] (serial8250_do_startup+0xc8/0x89c) [5.743530] [c034ab2c] (serial8250_do_startup) from [c03461f8] (uart_startup.part.3+0x7c/0x1dc) [5.752624] [c03461f8] (uart_startup.part.3) from [c0346d68] (uart_open+0xe4/0x124) [5.760681] [c0346d68] (uart_open) from [c032c19c] (tty_open+0x130/0x58c) [5.767852] [c032c19c] (tty_open) from [c01216f4] (chrdev_open+0x9c/0x174) [5.775115] [c01216f4] (chrdev_open) from [c011b8d4] (do_dentry_open+0x1d0/0x310) [5.783020] [c011b8d4] (do_dentry_open) from [c011bd98] (finish_open+0x34/0x4c) [5.790710] [c011bd98] (finish_open) from [c012a8f8] (do_last.isra.27+0x5a4/0xb98) [5.798675] [c012a8f8] (do_last.isra.27) from [c012afa0] (path_openat+0xb4/0x5e4) [5.806549] [c012afa0] (path_openat) from [c012b7dc] (do_filp_open+0x2c/0x80) [5.814086] [c012b7dc] (do_filp_open) from [c011cd14] (do_sys_open+0x100/0x1d0) [5.821777] [c011cd14] (do_sys_open) from [c07b7ce0] (kernel_init_freeable+0x124/0x1c8) [5.830200] [c07b7ce0] (kernel_init_freeable) from [c054eb90] (kernel_init+0x8/0xe4) [5.838348] [c054eb90] (kernel_init) from [c000e868] (ret_from_fork+0x14/0x2c) Sounds like the clocks are not enabled properly? puh. So after staring a while at your backtrace I realized that shutdown startup callbacks are not overwritten properly. Well, thanks for that. Anyway, even serial8250_do_startup() has pm_runtime_get_sync() before first register access so I have no idea where this is coming from. Regards, Tony Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
On 07/10/2014 11:47 AM, Sebastian Andrzej Siewior wrote: That core_pwrdm shows only up on dra7. However with both drivers (mine and the current omap serial) the UART went down after three secs (as expected) and didn't accept any characters while writing on the console. If I wrote something on it via network (like echo a /dev/ttyO0) it came back and was working as long as I kept it busy. The thing is that RX does not wake it up. Any idea? To wakeup from UART you need: 1) Append no_console_suspend to bootargs 2) echo enabled /sys/devices/ocp.3/4806a000.serial/tty/ttyO0/power/wakeup -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
On Thu, Jul 10, 2014 at 11:03 AM, Carlos Hernandez c...@ti.com wrote: 1) Append no_console_suspend to bootargs Not needed. ideally with pinctrl wakeup capability, this should work. if you do no_console_suspend, the module is not powered down. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
