EPIC Vs OpenPIC (RFC)

[Sarnath Kannan]

> I dont agree,
> we would end up duplicating 90% of the open_pic
> code, and this is also an excellent opportunity to
> move out the cascade-handling from the open_pic stuff.
>
  Moving the cascading part away from open_pic is
a good one. I dont know, why on earth it assumes
that only IRQ0 would be cascaded. Its really
very innocent.

> Just stay tuned, I already did the rewriting of the
> open_pic.c, just need to get to work on Monday,
> testing the result.
> I will then submit this as a suggestion.
> It actually looks more clean that the original code,
> at last to my eyes ;-)

             Good Work !

> And it really makes for an even more simple
> xxx_setup.c for the different ports.
>
> At the same time I would like to suggest an inclusion
> of the registration of the i8259 interrupts to
> i8259_init().
> At the momenty everyone of the drivers are doing exactly
> the same thing:
> for ( vec = 0 ; vec < NUM_8259_INTERRUPTS  ; vec++ )
>         irq_desc[vec].handler = &i8259_pic;
>
  Why should all drivers populate irq_desc ??
I dont get this. It is done once in life time,
right ? That too, even before driver's init
routine come into picture.

Do the ISA drivers assume the
vector number starts from 0 and register IRQs ?
Even if it is so, its fine. See below.


> Moving this to i8259_init() and giving the routine a
> parameter startvec (even if everyone is starting from 0
> at the moment) would get rid of even more code from
> the machine-specific stuff.
>
   The best thing is allow the 8259 to retain
its vector space from 0-15. Program EPIC
to generate interrupts from 16-40. ( By
passing "offset" value of 16 to openpic_init)
That should clear things up and seperate the
vector spaces of EPIC and PIC.

   May I know whats the semantics of the
"regOffset" ?


Good Luck

Sarnath


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/