Re: fixing serial console over suspend [was Re: Bisects that are neither good nor bad]
- From: Russell King <rmk+lkml@xxxxxxxxxxxxxxxx>
- Date: Fri, 9 Jun 2006 09:51:34 +0100
On Fri, Jun 09, 2006 at 10:46:00AM +0200, Pavel Machek wrote:
On P? 09-06-06 09:42:34, Russell King wrote:
On Fri, Jun 09, 2006 at 10:38:33AM +0200, Pavel Machek wrote:
The serial layer does _not_ have access to the "current" termios
settings due to the layering by the tty subsystem. If the serial
port being used by serial console has been opened once by the user,
but is closed at the moment when a suspend/resume cycle occurs,
the serial layer and lower level drivers do not have access to the
baud rate.
Could serial layer just cache "last baud rate" in some kind of
software shadow register? Yes, it is slightly ugly, but should do the trick.
That's not a new suggestion. How do you deal with the case where
you have console on two or more different serial ports? That's
the problem with this approach.
Well, each of serial ports has hardware baud_rate register. I'll need
software baud_rate_shadow for every serial port, setting
baud_rate_shadow each time baud_rate is set. During resume, I restore
baud_rate from baud_rate_shadow for each serial port.
What am I missing?
What about the other parameters like the bit size, number of stop bits,
etc?
The only sane solution is for the tty layer to be adjusted to allow
suspend/resume support for consoles.
Well, solution above is likely to be ugly, but even ugly patch would
help people debug s-to-RAM.
Why not investigate doing the proper solution? Since you're obviously
one of the ones who is able to reproduce the situation (I'm not), you're
perfectly placed to develop and test such a solution, and I think it's
well within your capability.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: Bisects that are neither good nor bad
- From: Pavel Machek
- Re: Bisects that are neither good nor bad
- From: Russell King
- Re: Bisects that are neither good nor bad
- From: Pavel Machek
- Re: Bisects that are neither good nor bad
- From: Russell King
- fixing serial console over suspend [was Re: Bisects that are neither good nor bad]
- From: Pavel Machek
- Re: Bisects that are neither good nor bad
- Prev by Date: Re: Idea about a disc backed ram filesystem
- Next by Date: [patch, -rc6-mm1] irqflags tracing: fix x86_64 entry/exit
- Previous by thread: fixing serial console over suspend [was Re: Bisects that are neither good nor bad]
- Next by thread: Re: Bisects that are neither good nor bad
- Index(es):
Relevant Pages
|
Loading