Subject: Re: port-evbmips/31992: alchemy ICU is too Au1000 specific
To: None <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 11/10/2005 14:02:05
> >Number: 31992
> >Category: port-evbmips
> >Synopsis: alchemy ICU is too Au1000 specific
> The interrupt strings for the au_icu.c (and some of the identifiers,
> etc.) are really indicative of the specific Au1000 port, and do not
> reflect the general Alchemy family.
> This can actually lead to confusing output, e.g. from vmstat -e,
> because the interrupts are not wired the same on all parts.
> A better solution, IMO, is to generalize the strings to "irq XX".
> This provides less information than the current port does, but at
> least the information is not incorrect! (And someone familiar with a
> given board can easily lookup up the IRQ mappings if needed. And the
> actual drivers print out the IRQ they are on at attach time, so it
> should all be good. :-)
The way I'd previously worked around this was to have a table per
supported CPU type, similar to the way that aubus.c does things. While
you can refer back to dmesg for interrupt number assignments, I think
I prefer to see the irq names in vmstat -e/-i without having to do the
I've also been thinking of stripping out tables for each CPU in to their
own files, and having a way of just configuring support for a single CPU
type, instead of always being able to support CPUs (and devices) for all
Alchemy CPU types that exist. While it's sometimes convenient (eg, I
don't have to use a different kernel when I turn a different board on
here and boot with tftp kernel), I think it makes more sense from an
embededed POV to just support the CPU and features you need.
Simon Burge <email@example.com>
NetBSD Support and Service: http://www.wasabisystems.com/