LKML Archive on
help / color / mirror / Atom feed
From: "Remy Bohmer" <>
To: "Haavard Skinnemoen" <>
Cc: michael <>,, "Andrew Victor" <>,
	"Chip Coldwell" <>,
	"Marc Pignat" <>,
	"David Brownell" <>,,
	"Alan Cox" <>
Subject: Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler
Date: Wed, 30 Jan 2008 12:05:40 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 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
> > latest... ;-)
> They are in -mm. You were Cc'ed I think...

Yes, I saw them, but I did not know if there were any updates in the
mean time, because I had seen some discussions, which confused me a
bit about the current status of the complete set.

> - with full preemption  it runs but the serial line can't be used for
> receiving at high bit rate (using lrz)

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?

Notice that the DBGU has no flow control, and just a 1 byte FIFO (thus
no fifo at all).
At high speeds (e.g. >=115200) it is _likely_ that you will miss
characters, nothing can prevent that. DBGU should only be used at
lower speeds, or just as text console. 115200 is running fine here as
I would not expect that the behaviour is worse than without the
patchset, because without it it does not work at all on Preempt-RT,
but also: there was done much more in interrupt context previously, so
the chance of buffer overruns was much more likely in the old
The real interrupt handler (doing the reading from the fifo) must be
as short as possible, to be able to keep up with the data flow.

A simple calculation: 115200bps results in approx. 11520 bytes per second.
This means that the interrupt handler must be capable of handling each
byte on DBGU within 87us. With a worst case interrupt latency of about
85us, and average between 2us and 54us (on Preempt-RT and AT91RM9200),
you can simply understand that this will not match, how good/fast the
interrupt handling will ever be.

So, I suggest to either use flow-control, or DMA for bulkdata... (thus not DBGU)

Kind Regards,


  reply	other threads:[~2008-01-30 11:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2008-01-29 23:12 ` michael
2008-01-30  9:41   ` Haavard Skinnemoen
2008-01-30 10:21     ` Remy Bohmer
2008-01-30 10:34       ` Haavard Skinnemoen
2008-01-30 11:05         ` Remy Bohmer [this message]
2008-01-30 12:43           ` Haavard Skinnemoen
2008-01-30 15:25           ` michael
2008-01-30 10:29     ` michael
2008-01-30 12:36       ` Haavard Skinnemoen
2008-01-30 15:26         ` michael
2008-01-30 15:46           ` Haavard Skinnemoen
2008-01-31  1:53             ` michael
2008-01-31 15:07               ` Haavard Skinnemoen
2008-01-31 19:36                 ` Remy Bohmer
2008-02-04 12:39                   ` Haavard Skinnemoen
2008-02-04 19:44                     ` Remy Bohmer
2008-02-06 12:19                       ` michael
2008-02-06 19:41                         ` Remy Bohmer
2008-02-13 11:07                           ` michael
2008-02-13 20:13                             ` Remy Bohmer
2008-02-14  7:30                               ` michael
2008-02-04 19:01                 ` michael
2008-02-04 20:25                   ` Haavard Skinnemoen
2008-02-05 12:29                     ` michael
2008-02-06 12:30                       ` Haavard Skinnemoen
2008-02-06 13:41                         ` michael
2008-02-06 15:22                           ` Haavard Skinnemoen
2008-01-24 12:41 [PATCH -mm v4 0/9] atmel_serial cleanups and improvements Haavard Skinnemoen
2008-01-24 12:41 ` [PATCH -mm v4 1/9] MAINTAINERS: Add myself as maintainer of the atmel_serial driver Haavard Skinnemoen
2008-01-24 12:41   ` [PATCH -mm v4 2/9] atmel_serial: Clean up the code Haavard Skinnemoen
2008-01-24 12:41     ` [PATCH -mm v4 3/9] atmel_serial: Use cpu_relax() when busy-waiting Haavard Skinnemoen
2008-01-24 12:41       ` [PATCH -mm v4 4/9] atmel_serial: Use existing console options only if BRG is running Haavard Skinnemoen
2008-01-24 12:41         ` [PATCH -mm v4 5/9] atmel_serial: Fix bugs in probe() error path and remove() Haavard Skinnemoen
2008-01-24 12:41           ` [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler Haavard Skinnemoen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).