Re: [patch] HWUART instead of BTUART on the h5550 (workaround for Bluetooth UART overruns)

On Fri, Mar 11, 2005 at 10:28:18AM +0100, Catalin Drula wrote:
>
>
> On Thu, 10 Mar 2005, Erik Hovland wrote:
>
> > On Wed, Mar 09, 2005 at 04:12:32PM +0100, Catalin Drula wrote:
> > > In addition to the changes strictly related to the HWUART, I have also
> > > backported some of the changes made in 2.14.19-rmk7-pxa2 to the irq code
> > > and the entry code in arch/arm/kernel/entry-*.S. These were necessary to
> > > remove some bugs (for example, some irq numbers were hardcoded instead of
> > > being relative to PXA_IRQ_SKIP as they should have been).
> >
> > I have a question about a change the patch makes to
> > include/asm-arm/arch-pxa/irqs.h. There is a little config magic there
> > and a line that says:
> > #define PXA_IRQ_SKIP 6 /* Only the first 7 IRQs are reserved, but stupid drivers don't like irq 0 so */
> >
> > Think you could expound on what stupid drivers don't like irq 0. I
> > noticed that rmk7-pxa2 has a PXA_IRQ_SKIP of 7 (but they obviously could
> > give a flip about h5400 and bluetooth). It would be nice to get the
> > stupid drivers fixed instead so it is closer to mainline.
>
> Well, PXA_IRQ_SKIP is the number of irqs that are "reserved" (that is bits
> in the beginning of the interrupt register, I forgot what it's called, on
> the PXA). On the PXA 250 this number was 8. On the PXA 255 they put the
> HWUART irq on bit 7 (previously reserved) so normally we would change
> PXA_IRQ_SKIP to 7. That would mean the irq for the HWUART would be 0. The
> serial driver (drivers/char/serial.c) uses irq 0 as a reserved value (I
> think it means "no irq" or something like that), so intead of changing the
> whole driver I opted for the simpler solution (yet a bit hackish, but with
> no side effects) of offseting by yet another unit.
>
> The serial driver in 2.4.19 is a real mess in itself since it supports so
> many different UARTs. In further kernels (like 2.6) a lot of this stuff
> has been broken into smaller pieces and moved under drivers/serial, I
> think. The PXA UART also gets its own driver: drivers/serial/pxa.c

Thanks for the background. You said as much in your previous post. But I
was too dense to understand it.

So, those in the know. Will you acquiesce to the different irq skip hack
or would you rather see serial.c fixed before this gets resolved? What
about the possibility of commenting out BTUART irq at 21 and putting
HWUART there instead (not sure if there are h/w limitations)? But it
seems like an obvious way to go since we won't be using BTUART with this
arrangement.

E

-- 
Erik Hovland
mail: erik AT hovland DOT org
web: http://hovland.org/
PGP/GPG public key available on request