Hi,
here's a copy of a message I sent to the general linux kernel mailing list.
As this happens with a StrongARM (though I don't believe it's StrongARM
specific), maybe someone on this mailing list may have an insight as
to why the serial driver runs with irqs off.
Thanks,
- Godmar
Forwarded message:
> From gback Wed Jul 14 10:56:07 1999
> From: Godmar Back <gback>
> Message-Id: <[EMAIL PROTECTED]>
> Subject: serial driver irq takes too long
> To: [EMAIL PROTECTED]
> Date: Wed, 14 Jul 1999 10:56:07 -0700 (PDT)
> Cc: gback
> X-Mailer: ELM [version 2.4 PL24]
> Content-Type: text
>
>
> Hi,
>
> I have a question/problem with the serial driver.
>
> This is with a 2.0.30 kernel, but a quick look at 2.2.5 tells
> me that this version would most likely exhibit the same problem.
>
> The problem I'm seeing is that the serial driver takes too long to
> handle a receive interrupt because it runs while interrupts are disabled.
>
> As a result, other, higher-prioritized interrupts cannot be handled in time.
> This has bad effects on the systems in that it causes my sound driver
> to not refill its codec's fifo in run, which in turn results in underruns
> and interruptions of the audio play.
>
> My questions:
>
> + why does the serial driver run with interrupts disabled for so long?
> + has anybody seen that problem?
> + how could one fix it?
>
> Here's what I tried. I added a pair of sti(); cli(); in the
> receive_chars() do { } while() loop right before the serial_inp().
> Like so:
>
> receive_chars()
> {
> do {
> sti();
> cli();
> ... serial_inp()
> ...
> } while ( ... )
> }
>
> This appears to more or less work for a single serial port, but is it safe
> (methinks it's not, especially if there's more than one serial port on the
> machine.) That's on a 200MHz StrongARM, btw.
>
>
> Thanks,
>
> - Godmar
>
> ps: it would be nice to cc me if someone replied to this.
>
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
