Re: [PATCH] atmel_serial: Fix break handling

[Russell King]

On Tue, Jun 19, 2007 at 01:36:05PM +0300, Ivan Kuten wrote:
> On Mon, 18 Jun 2007 11:33:54 +0100
> Russell King wrote:
> 
> > On Mon, Jun 18, 2007 at 01:21:21PM +0300, Ivan Kuten wrote:
> > > Hi Haavard,
> > > 
> > > I tried /dev/ttyAT3, break appeared but not the way I expected, after:
> > > stty -F /dev/ttyAT3 brkint I get:
> > > 
> > > cat /proc/tty/driver/atmel_serial 
> > > serinfo:1.0 driver revision:
> > > 0: uart:ATMEL_SERIAL mmio:0xFEFFF200 irq:1 tx:0 rx:0 CTS|DSR|CD|RI
> > > 1: uart:ATMEL_SERIAL mmio:0xFFFC0000 irq:6 tx:0 rx:0 CTS|DSR|CD|RI             
> > > 2: uart:ATMEL_SERIAL mmio:0xFFFC4000 irq:7 tx:0 rx:0 RI                        
> > > 3: uart:ATMEL_SERIAL mmio:0xFFFC8000 irq:8 tx:1530 rx:115 brk:1 RTS|DTR|DSR|CD|RI
> > > 4: uart:ATMEL_SERIAL mmio:0xFFFCC000 irq:9 tx:0 rx:0 DSR|CD|RI  
> > > 
> > > brk is 1 not depending on how many breaks was sent. May be I missunderstood
> > > "break" meaning?
> > > I use from minicom: Main Functions : send break.........F . 
> > 
> > Note that if you want to use magic sysrq on ttyAT3, you need the kernel
> > console on ttyAT3.  Since you successfully received one break event on
> > ttyAT3, the next character should have caused a sysrq event.
> > 
> 
> Yes, I added to kernel command line "console=ttyAT3,115200" . 
> 
> I do not receive brk event via minicom, break counter sets to 1 only if
> I issue this command: stty -F /dev/ttyAT3 brkint 

You won't *receive* a break event via minicom - minicom will probably
ignore the "interrupt" signal generated by the break interrupt.  But
aren't you _transmitting_ breaks using minicom?  Are you running
minicom on both ends?

Anyway, the fact that the break counter incremented to '1' _and_ you've
set ttyAT3 to be a console means that the next character received should
be interpreted as a magic sysrq character.

Also, I note that the code in atmel_serial.c couldn't care less about
the setting of BRKINT as far as incrementing the break counter (and
that's how it should be) so I'm not really sure what's going on with
your setup.  BRKINT just sets ATMEL_US_RXBRK in read_status_mask, which
is only applied to the value read from the status register _after_ we
check the status register for a break and increment the break counter.
So I think that the incrementing of the break counter after you set
BRKINT is just co-incidence.

In any case, I think you need to take more care when composing your
emails.  I'm getting really confused as to what you're running at
each end of your serial link and what the configuration actually is.

Please take the time to re-describe from the start what your problem
really is, taking care to clearly identify which end is doing what,
what hardware is at each end, how each end is configured, what it's
running and so forth.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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/