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/
>  
>