Re: [PATCH, RFC] wake up from a serial port
From: Scott Wood <hidden>
Date: 2007-08-13 20:50:47
Also in:
linuxppc-dev
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?
quoted hunk ↗ jump to hunk
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 isstill active)--- interrupts are re-enabled3. 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