Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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 as

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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)

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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)

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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 trigger

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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)

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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 a

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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)

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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(>lock,

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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(>lock, flags); >

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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,

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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(>lock); > > > */ > > > tty_flip_buffer_push(port->info->tty); > > > /* > > >

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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) > -

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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) -

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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_lock(port-lock); */

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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, there is

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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 the

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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,

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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_tx_chars(port);

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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-lock,

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

[PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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

[PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

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