Subject: Re: [PATCH, RFC] wake up from a serial port - msg#00047

Previous Message by Date: click to view message preview

Re: [PATCH, RFC] wake up from a serial port

Guennadi Liakhovetski wrote: Well, sort of. One of them is more "natural" - it has a button on the front panel, to use the other one you have to modify the hardware. However, I like the idea - generally it does seem to be a better approach to have it run-time configurable over sysfs... Only - how? The only differentitaion ATM between the two ports are these two links: # ls -l /sys/devices/platform/serial8250.0/tty* lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0 lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1 And placing some wakeup file under the class/tty/ directory doesn't seem very consistent with the current policy - until now they only live under devices/... (Greg added to cc:). Hmm... I'd assumed each port would have its own device directory. Would anything break horribly if it were changed so that each tty:ttySx is a directory, which contains both a wakeup file and the symlink? Actually, it is good you replied, Scott:-) I wanted to ask you about the following: I've switched to your generic suspend/resume routines using the _TLF_NAPPING bit, the arch_suspend_{dis,en}able_irqs() hooks... On wakeup your _TLF_NAPPING trick should bypass calling the ISR and jump directly to the resume code. However, on wakeup, it looks like I do get the wakeup interrupt too. You should get the interrupt, but not until after the PM code enables IRQs. Are you saying that the interrupt handler runs before then? Is it the correct behaviour and is this the (approximately) correct explanation why: 1. the AVR connected to ttyS0 sends 1 byte on button press and 1 byte on button release. So, normally you would get 2 bytes and 2 interupts for one such button down-up. 2. Interrupt is configured as edge (is it correct - haven't found in mpc8245um, UARTs are usually edge), so, --- button down -> byte #1 -> IRQ line active -> IC interrupts --- on resume interrupts are disabled, an EOI is performed (the line is still active) --- interrupts are re-enabled 3. a second interrupt for the same byte is delivered. No EOI is performed -- the idea is to defer the interrupt, not swallow it. All that is done to defer the interrupt is clearing MSR[EE]. -Scott - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Date: click to view message preview

Re: Serial ports rearranged in 2.6.22?

On Saturday 11 August 2007 09:49:25 am Michael Mauch wrote: > Yinghai Lu wrote: > > > On 8/10/07, Michael Mauch <michael.mauch@xxxxxx> wrote: > > > until 2.6.21, I had the normal assignments for ttyS0 and ttyS1: > > > > > > 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A > > > 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > > > > > > With 2.6.22 I get the names <-> ports/irqs the other way around: > > > > > > 00:08: ttyS0 at I/O 0x2f8 (irq = 3) is a 16550A > > > 00:09: ttyS1 at I/O 0x3f8 (irq = 4) is a 16550A > > > ... > > http://lkml.org/lkml/2007/7/25/455 > > Thanks - I applied that patch and the names are back to normal again: > > 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Just FYI, the patch Yinghai mentioned above was experimental, and we decided it was the wrong solution. For 2.6.22, the easiest workaround is to boot with the "legacy_serial.force" option. For 2.6.23, we reverted my patch that caused the names to be swapped: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=57d4810ea0d9ca58a7bcc1336607f0cede0a2abf Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Previous Message by Thread: click to view message preview

Re: [PATCH, RFC] wake up from a serial port

Guennadi Liakhovetski wrote: Well, sort of. One of them is more "natural" - it has a button on the front panel, to use the other one you have to modify the hardware. However, I like the idea - generally it does seem to be a better approach to have it run-time configurable over sysfs... Only - how? The only differentitaion ATM between the two ports are these two links: # ls -l /sys/devices/platform/serial8250.0/tty* lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0 lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1 And placing some wakeup file under the class/tty/ directory doesn't seem very consistent with the current policy - until now they only live under devices/... (Greg added to cc:). Hmm... I'd assumed each port would have its own device directory. Would anything break horribly if it were changed so that each tty:ttySx is a directory, which contains both a wakeup file and the symlink? Actually, it is good you replied, Scott:-) I wanted to ask you about the following: I've switched to your generic suspend/resume routines using the _TLF_NAPPING bit, the arch_suspend_{dis,en}able_irqs() hooks... On wakeup your _TLF_NAPPING trick should bypass calling the ISR and jump directly to the resume code. However, on wakeup, it looks like I do get the wakeup interrupt too. You should get the interrupt, but not until after the PM code enables IRQs. Are you saying that the interrupt handler runs before then? Is it the correct behaviour and is this the (approximately) correct explanation why: 1. the AVR connected to ttyS0 sends 1 byte on button press and 1 byte on button release. So, normally you would get 2 bytes and 2 interupts for one such button down-up. 2. Interrupt is configured as edge (is it correct - haven't found in mpc8245um, UARTs are usually edge), so, --- button down -> byte #1 -> IRQ line active -> IC interrupts --- on resume interrupts are disabled, an EOI is performed (the line is still active) --- interrupts are re-enabled 3. a second interrupt for the same byte is delivered. No EOI is performed -- the idea is to defer the interrupt, not swallow it. All that is done to defer the interrupt is clearing MSR[EE]. -Scott - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Thread: click to view message preview

Re: [PATCH, RFC] wake up from a serial port

On Mon, Aug 13, 2007 at 11:14:22PM +0200, Guennadi Liakhovetski wrote: > On Mon, 13 Aug 2007, Scott Wood wrote: > > > Guennadi Liakhovetski wrote: > > > > > > # ls -l /sys/devices/platform/serial8250.0/tty* > > > lrwxrwxrwx 1 root root 0 Aug 13 22:05 > > > /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0 > > > lrwxrwxrwx 1 root root 0 Aug 13 22:05 > > > /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1 > > > > > > And placing some wakeup file under the class/tty/ directory doesn't seem > > > very consistent with the current policy - until now they only live under > > > devices/... (Greg added to cc:). > > > > Hmm... I'd assumed each port would have its own device directory. Would > > anything break horribly if it were changed so that each tty:ttySx is a > > directory, which contains both a wakeup file and the symlink? No, you are already in the tty device directory in the first place, the tty:ttyS1 is just a symlink to the class in case you need the thing. Let's follow things around: ~ $ cd /sys/class/tty /sys/class/tty $ ls -l | grep ttyS lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS0 -> ../../devices/platform/serial8250/tty/ttyS0 lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS1 -> ../../devices/platform/serial8250/tty/ttyS1 lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS2 -> ../../devices/platform/serial8250/tty/ttyS2 lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS3 -> ../../devices/platform/serial8250/tty/ttyS3 /sys/class/tty $ cd ../../devices/platform/serial8250/tty/ttyS0 /sys/devices/platform/serial8250/tty/ttyS0 $ ls dev device power subsystem uevent /sys/devices/platform/serial8250/tty/ttyS0 $ cd .. /sys/devices/platform/serial8250/tty $ $ ls -l total 0 drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS0 drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS1 drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS2 drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS3 /sys/devices/platform/serial8250/tty $ cd .. gregkh@mini /sys/devices/platform/serial8250 $ ls -l total 0 lrwxrwxrwx 1 root root 0 Aug 12 20:13 driver -> ../../../bus/platform/drivers/serial8250 -r--r--r-- 1 root root 4096 Aug 13 15:24 modalias drwxr-xr-x 2 root root 0 Aug 13 15:24 power lrwxrwxrwx 1 root root 0 Aug 12 20:13 subsystem -> ../../../bus/platform drwxr-xr-x 6 root root 0 Aug 12 20:12 tty -rw-r--r-- 1 root root 4096 Aug 12 20:12 uevent So, the serial8250 device is the "bridge" for the 4 different serial ports in my machine. You have the tty:ttyS? symlinks in that directory as you have CONFIG_SYSFS_DEPRECATED still enabled, but the directory structure should all still be the same for you. So, if you want to put things into the tty device's directory, you can, they will just show up in the proper place, under /sys/devices/platform/serial8250/tty/ttyS0 for the first serial port. Does that make sense? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html