Hi,
Remy Bohmer wrote:
Hello All,
All works now for me with preempt-rt. The problem is using hrtimer.
I think that hrtimer are executed with interrupts disabled so, if
this happen when I must receive a char, i have an overrun.
No, they share the same interrupt line...
I think that
Hello All,
> All works now for me with preempt-rt. The problem is using hrtimer.
> I think that hrtimer are executed with interrupts disabled so, if
> this happen when I must receive a char, i have an overrun.
No, they share the same interrupt line...
So, while the timer interrupt handler is runn
Hi,
All works now for me with preempt-rt. The problem is using hrtimer.
I think that hrtimer are executed with interrupts disabled so, if
this happen when I must receive a char, i have an overrun. The only
solution was the dma support to serial device.
Regards Michael
--
To unsubscribe from th
Hello Michael,
> the serial driver works fine. The problem seems to be related to the
> tclib, when I use it as a clocksource.
tclib as a clocksource should be no problem on Preempt-RT, do not use
it as clockevent device, it will not work properly on preempt-rt on
at91* yet, especially with the N
On Wed, 06 Feb 2008 14:41:09 +0100
michael <[EMAIL PROTECTED]> wrote:
> I refer to this part of documentation:
>
> "The USART behavior when hardware handshaking is enabled is the same as
> the behavior in
> standard synchronous or asynchronous mode, except that the receiver
> drives the RTS pin
Hi,
Haavard Skinnemoen wrote:
On Tue, 05 Feb 2008 13:29:35 +0100
michael <[EMAIL PROTECTED]> wrote:
Just one question:
Receiving with hardware handshake works without PDC?
I don't know...I haven't tried. These patches shouldn't change anything
though.
Haavard
--
To unsubscribe from
On Tue, 05 Feb 2008 13:29:35 +0100
michael <[EMAIL PROTECTED]> wrote:
> Just one question:
> Receiving with hardware handshake works without PDC?
I don't know...I haven't tried. These patches shouldn't change anything
though.
Haavard
--
To unsubscribe from this list: send the line "unsubscribe l
Hi,
the serial driver works fine. The problem seems to be related to the
tclib, when I use
it as a clocksource. The numbers of overruns depends on the type of
files too.
It is possible?
Regards
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
hi,
diff --git a/drivers/serial/atmel_serial.c b/drivers/serial/atmel_serial.c
index cb70cc5..f310a80 100644
--- a/drivers/serial/atmel_serial.c
+++ b/drivers/serial/atmel_serial.c
@@ -552,7 +552,7 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
atmel_handle_transmit
On Mon, 04 Feb 2008 20:01:26 +0100
michael <[EMAIL PROTECTED]> wrote:
> I think the the atmel_interrupt handler
> must check the
> pass_counter before return IRQ_HANDLED.
I'm not sure if it helps in this particular case but yeah, since the
interrupt may be shared, it's definitely wrong to always
Hello Haavard,
> That's what I was thinking too. If this is indeed the cause, the
> dev_err() added by the debug patch I posted should trigger and we may
> consider boosting the priority of the tasklet (using
> tasklet_hi_schedule.)
Notice that we are talking about Preempt-RT here. Everything is
Hi
Haavard
diff --git a/drivers/serial/atmel_serial.c b/drivers/serial/atmel_serial.c
index 477950f..c61fcc3 100644
--- a/drivers/serial/atmel_serial.c
+++ b/drivers/serial/atmel_serial.c
@@ -337,9 +337,12 @@ atmel_buffer_rx_char(struct uart_port *port, unsigned int
status,
struct circ_
On Thu, 31 Jan 2008 20:36:25 +0100
"Remy Bohmer" <[EMAIL PROTECTED]> wrote:
> A long shot, but can it be that the ringbuffer overflows, and that
> therefor characters are lost?
That's what I was thinking too. If this is indeed the cause, the
dev_err() added by the debug patch I posted should trig
Hello Haavard,
> It seems to be very sensitive to network traffic though...could it have
> something to do with softirq scheduling? Could you try the patch below
> and see if you can trigger the error message?
Funny that you mention this.
The largest latencies I currently have on RT (and rm9200)
On Thu, 31 Jan 2008 02:53:50 +0100
michael <[EMAIL PROTECTED]> wrote:
> The overrun still remain. An lrz receive session is impossible using
> full preemption. I will try the dma patch too and test in iso mode for
> smart card.
Hmm. Seems to work reasonably well on a non-rt kernel -- I get quite
Hi,
Haavard Skinnemoen wrote:
On Wed, 30 Jan 2008 16:26:27 +0100
michael <[EMAIL PROTECTED]> wrote:
I have no idea. Could you post some more specifics about what you
modified, for example a diff?
...
/* The interrupt handler does not take the lock */
spin_lock_irqsave(&port->lo
On Wed, 30 Jan 2008 16:26:27 +0100
michael <[EMAIL PROTECTED]> wrote:
> > I have no idea. Could you post some more specifics about what you
> > modified, for example a diff?
> >
> >
>
> ...
> /* The interrupt handler does not take the lock */
> spin_lock_irqsave(&port->lock, flags);
> atmel_
Hi,
A few questions arise here to me:
* What serial port is used here? (DBGU, or something else)
* No DMA was used, was flow-control enabled? (cannot with DBGU)
* If some other UART, why not using DMA?
DBGU, so no flow control
Notice that the DBGU has no flow control, and just a 1 byte FIFO
Hi,
On Wed, 30 Jan 2008 11:29:59 +0100
michael <[EMAIL PROTECTED]> wrote:
Now, _that_ is strange. I can't see anything that needs protection
across that call; in fact, I think we can lock a lot less than what we
currently do.
I explain it bad:
- with spin_lock the system seems, th
On Wed, 30 Jan 2008 12:05:40 +0100
"Remy Bohmer" <[EMAIL PROTECTED]> wrote:
> > > I believe I have to look at the latest set of patches, and try to find
> > > any regressions. Do you have a location somewhere where I can download
> > > the latest versions? Or do I need to dig through LKML to find
On Wed, 30 Jan 2008 11:29:59 +0100
michael <[EMAIL PROTECTED]> wrote:
> > Now, _that_ is strange. I can't see anything that needs protection
> > across that call; in fact, I think we can lock a lot less than what we
> > currently do.
> >
> >
> I explain it bad:
> - with spin_lock the system seem
Hello Haavard,
> The code above is from the tasklet, so I don't think that's the problem.
> The interrupt handler doesn't take any locks.
> Or are spinlocks not allowed in softirq context either?
They are allowed there...
So, it has to be something different.
> > I believe I have to look at the
On Wed, 30 Jan 2008 11:21:49 +0100
"Remy Bohmer" <[EMAIL PROTECTED]> wrote:
> > > * Drop the lock here since it might end up calling
> > > * uart_start(), which takes the lock.
> > >spin_unlock(&port->lock);
> > > */
> > > tty_flip_buffer_push(port->info->tty);
> > > /*
> > > spin_l
Hi
On Wed, 30 Jan 2008 00:12:23 +0100
michael <[EMAIL PROTECTED]> wrote:
- Voluntary Kernel Preemption the system (crash)
- Preemptible Kernel (crash)
Ouch. I'm assuming this is with DMA disabled?
Yes, is with DMA disabled
/*
* Drop the lock here since it might end up calling
Hello Haavard (and Michael),
First I want to mention that I did not found the time yet to test your
latest integration of these atmel_serial patches, and I only know that
your set of the end of December works fine. I do not know the changes
you made since posting that set and your latest patch-set
On Wed, 30 Jan 2008 00:12:23 +0100
michael <[EMAIL PROTECTED]> wrote:
> I'm testing this patch on an at91sam9260 on 2.6.24-rt. I'm using this
> patch with the tclib support for hrtimer and the clocksource pit_clk.
> These are the results:
>
> - Voluntary Kernel Preemption the system (crash)
> - P
Hi,
From: Remy Bohmer <[EMAIL PROTECTED]>
This patch splits up the interrupt handler of the serial port
into a interrupt top-half and a tasklet.
The goal is to get the interrupt top-half as short as possible to
minimize latencies on interrupts. But the old code also does some
calls in the inte
From: Remy Bohmer <[EMAIL PROTECTED]>
This patch splits up the interrupt handler of the serial port
into a interrupt top-half and a tasklet.
The goal is to get the interrupt top-half as short as possible to
minimize latencies on interrupts. But the old code also does some
calls in the interrupt h
28 matches
Mail list logo
