lkml.org 
[lkml]   [2013]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH-v2] Set irq thread to RT priority on creation
From
Hi Thomas,

2013/6/3 Thomas Gleixner <tglx@linutronix.de>:
>
> The question is why there is data present in the UART when the UART
> driver has not initialized the UART. Up to the point where the UART is
> opened and the interrupt handler is installed the receiver should be
> disabled. Also there is the question why a flush does not kill
> everything including the pending data in the UART itself.
>
> And I don't think, that your issue is solved completely. Assume the
> following:
>
> Open UART
> Flush Buffers (including UART fifo)
>
> ---> UART receives data
> ---> Interrupt
> Data is available in tty buffer
>
> Write data to UART
>
> Receive data from UART
>
> You still get data which got into the buffer before you sent stuff
> out. So your application should not be surpriced at all by random data
> on the receive line when it starts up.
>
> Thanks,
>
> tglx

You are absolutely right, the real issue was that my UART device still
received data while the device was closed. And yes, the protocol that
we use should be robust to unexpected data. I solved & will solve
these problems now. So you indeed the uart explanation in my commit
log should be removed.

The point is that we while we were debugging & tracing this problem,
we didn't expect this behavior: in the trace we saw a threaded handler
scheduled in on 'normal' priority which surprised us. Also I think
there are situations thinkable (altough I cannot come up with a proper
example) where it is normal behavior that a IRQ directly kicks in
after enabling the interrupts.

Regards,
Ivo Sieben


\
 
 \ /
  Last update: 2013-06-05 09:01    [W:0.092 / U:1.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site