Subject: Re: port-evbmips/31992: alchemy ICU is too Au1000 specific
To: None <port-evbmips-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: netbsd-bugs
Date: 11/10/2005 03:18:01
The following reply was made to PR port-evbmips/31992; it has been noted by GNATS.
From: "Garrett D'Amore" <garrett_damore@tadpole.com>
To: Simon Burge <simonb@wasabisystems.com>
Cc: gnats-bugs@netbsd.org, port-evbmips-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-evbmips/31992: alchemy ICU is too Au1000 specific
Date: Wed, 09 Nov 2005 19:17:49 -0800
Simon Burge wrote:
>garrett_damore@tadpole.com wrote:
>
>
>
>>>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
>cross-referencing elsewhere.
>
>
I've not looked at this too closely, but can any of the interrupt lines
other than those associated with specific busses (PCI, PCMCIA) be pulled
off the processor? (In other words, is this mapping specific to a
board, or to a processor? If it is processor specific, then this is
good enough, but if it can vary from board to board, then I'd prefer to
just leave it general.)
My assumption as far as vmstat -e related stuff was that (for this port
at least) most embedded developers will more or less "know" the
interrupt routing for their board, and frankly might not be too bothered
by having to go back and forth. (Granted, for someone like you with a
lot of different ports that you maintain, this isn't such a big deal.)
My other consideration is that with more and more parts coming out, it
becomes somewhat onerous to write up a new table for each new part, and
that folks will be tempted not to make it correct. The current evidence
with the table being horribly wrong sort of serves as evidence of this.
I also don't have details on IRQ mappings for each of the
boards/processors. (Granted, I could probably go search the CD-ROM I
got for specs for the other parts...)
>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.
>
>
Yes, I am strongly in favor of this, and actually *need* it not just
per-processor but per *board*. This is because there are some details,
like PCI interrupt routing, that are *board* specific and cannot be
determined programmatically.
I already have some of this separated out in my Au1550 workspace, and
I'll be sending you diffs.
Therefore, when the PCI diffs come to you, they will include different
kernel configs (and board-specific .c files) for each of the supported
platforms (which as of right now are DbAu1500 and DbAu1550, because
that's all I have to test with.)
-- Garrett
>Cheers,
>Simon.
>--
>Simon Burge <simonb@wasabisystems.com>
>NetBSD Support and Service: http://www.wasabisystems.com/
>
>