[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] why intr->ack() is null?
At Wed, 02 Jun 2004 16:30:02 +0900,
やすし wrote:
>
> At Wed, 02 Jun 2004 16:30:21 +1000,
> John Williams wrote:
> >
> > John Williams wrote:
> > >
> > > I looked at the V2Pro/PPC source as well, and their driver for the
> > > XINTC, and it shows the same uncertainty about the behaviour of the
> > > XINTC. Their source is available (via bitkeeper) from penguinppc.org. I
> > > can send you the specific source file if you want to look into it.
> > >
> >
> > I just checked again, they've updated the source. Grab the PPC
> > xilinx_intc driver into your current working dir with this command:
> >
> > rsync -avz --delete
> > source.mvista.com::linuxppc_2_4_devel/arch/ppc/kernel/xilinx_pic.c .
> >
> > and see what they've done. Basically if it's a level sensitive
> > interrupt they ack after, else they ack immediately. Smells like a hack
> > to me.
>
[...]
>
> as you said, this smells like a hack. I'll pound my head a bit more
> about this ;)
I've poked around 2.4 and 2.6 code and it seems like every arch with
complex interrupts have some hack to work around this problem.
ARM arch even has deferent type for irq_desc array; from arch/arm/kernel/irq.c:
struct irqdesc irq_desc[NR_IRQS];
What RMK says about this is in include/linux/irq.h
/*
* Please do not include this file in generic code. There is currently
* no requirement for any architecture to implement anything held
* within this file.
*
* Thanks. --rmk
*/
so, if we really want to support edge and level interrupts in a clean
way, should we follow the arm way?
regards,
--
yashi
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/