On Sat, 07 Mar 2009 13:20:08 -0600
Kevin Hickey <khickey@xxxxxxxxxxx> wrote:
> > > +asmlinkage void plat_irq_dispatch(void)
> > > +{
> > > + unsigned int intr;
> > > + u32 bank;
> > > + u32 reg_msk;
> > > + unsigned int pending = read_c0_status() & read_c0_cause();
> > > + /*
> > > + * C0 timer tick
> > > + */
> > > + if (pending & CAUSEF_IP7)
> > > + do_IRQ(MIPS_CPU_IRQ_BASE + 7);
> > > + else if (pending & (CAUSEF_IP2 | CAUSEF_IP3)) {
> > > + intr = au_ioread32(&gpio_int->pri_enc);
> > > + bank = GPINT_BANK_FROM_INT(intr);
> > > + reg_msk = GPINT_BIT_FROM_INT(bank, intr);
> > > +
> > > + if (intr != 127) {
> > > + if (pending & CAUSEF_IP3)
> > > + board_irq_dispatch(intr);
> >
> > What is this supposed to do? (missed debug code?)
> board_irq_dispatch (which as I said above should be in a non-devboard
> include) is used to display the IRQ number on the hex LEDs on the DB1300
> board. I tried to keep it generic so that other boards could do what
> they want or leave it unimplemented and have it optimized out. The
> CAUSEF_IP3 part is there to not display the timer tick (since it pretty
> much floods out the other IRQ displays). I should really do that
> segregation in the board_irq_dispatch call; I was pretty focused on my
> board when I wrote this code.
Oh okay. I was wondering about the IP3.
We should probably make a list of all (possible) hooks available into
the alchemy core code (and give them nice prefixed names ;-) )
> > (FWIW, I'm working on getting rid of the explicit CPU-type config
> > options and instead do runtime detection and configuration of
> > dma/dbdma/irq/ and so on).
>
> Why? Won't that just lead to a larger kernel binary since it will have
> all of the tables in it? I would prefer to only compile in the data
> that I need. Unless I'm missing what you're doing...
All Alchemy chips are more or less identical. Some have different
sd/ddr controller, some have different dma, and some lack peripherals
others do have; most periperhals have identical mmio addresses across
chip types.
Interestingly even the devboard designers assigned a unique 4bit value
to each board type; with a bit of work you could in theory build one
kernel binary which runs on all of them.
That's what I'm aiming at.
Best regards,
Manuel Lauss
