Re: sh: intc - convert board specific r2d code

[Magnus D. <mag...@gm...>]

On 8/3/07, Paul Mundt <le...@li...> wrote:
> On Fri, Aug 03, 2007 at 01:32:58PM +0900, Magnus Damm wrote:
> > sh: intc - convert board specific r2d code
> >
> > This patch converts the board specific interrupt code for r2d to make use of
> > intc. While at it we remove CONFIG_RTS7751R2D_REV11 to avoid confusion and
> > to support both R2D-1 and R2D-PLUS boards using the same binary.
> >
> > - Two sets of interrupt tables exist - one for R2D-1 and one for R2D-PLUS.
> > - R2D-1 and R2D-PLUS use the same irq constants.
> > - R2D-1 has AX88796 support, R2D-PLUS does not hook up that IRQ.
> > - R2D-PLUS has KEY support, R2D-1 does not hook up that IRQ.
> > - The number and order of IRQ values are disconnected from register bits.
> > - Interrupt sources now start from IRQ 100.
> > - The machvec demux function converts from irlm IRQ 0-14 to IRQ 100++.
> >
> > Tested on R2D-1 and R2D-PLUS boards.
> >
> Hmm.. While it's an interesting approach, not having these as initdata is
> worrying. We only require one set of IRL<->IRQ mappings, vector/mask
> information, etc. and as these are quite weighty to begin with, we do not
> want to be making this an exponential thing when there are board
> revisions. I can live with having the tables present and discarding the
> unused ones, but not having all of the unused tables resident (you'll
> just have to flag them all as initdata and copy out the tables you care
> about, as per the version register). The kernel is bloated enough without
> adding to it.

One side of me agrees with you that this approach doesn't scale and we
should be concerned about the memory footprint. Another side thinks
that this a development platform and if we use a few kilobytes more
memory it's not the end of the world. Especially if it is makes
maintaining these boards an easier task. And regarding the scalability
- that we can fix that when it becomes a problem.

OTOH, I do think you are right that having the tables as initdata
would make sense. Maybe converting the intc code to copy out the
needed tables would be nice... That way we can mark all intc tables as
initdata.

Regarding R2D-1 and R2D-PLUS support - after thinking a bit I must say
that this is most likely exactly what we should use multiple machvecs
for. If we could combine multiple machvecs with a probe() or something
that can detect boards, then we could just have two separate boards -
one for R2D-1 and one for R2D-PLUS. That would make sense for
highlander as well...

/ magnus