Unified setup...

[Stefan Reinauer]

Hi LYH, Ron and others,

I've been looking at the recent changes that went into the tree, and I
don't like the fact that a lot of code is duplicated. Is there some way
to unify this?

--- raminit.c   2003-08-28 14:43:39.000000000 +0200
+++ raminit.1.c 2003-08-28 06:42:50.000000000 +0200
[..]
-       PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff00,
+       PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20,

This changes the link id where the southbridge is connected.
We can get this information out of the configuration file since we
are able to describe a map of all CHT components.
On most machines the southbridge is probably connected to LDT0, but
having two files for this one setting seems inappropriate.
Ron, what is the easiest way of getting this information from the
config file?

LYH: To get this unified again, I added a resourcemap.c file to the
s2885 directory that contains the resource map of the 2885. In auto.c
this is used instead of the default.

-       PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff000,
+       PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020,

same as above.

-       PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0xff000003,
-       PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000000,
+       PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000203,
+       PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x05040003,

These change the bus numbers and read/write enables. How can we write
these more general?

+/*
 //BY LYH  add IOMMU 64M APERTURE
        PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
        PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
        PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,

//BY LYH END
+*/

I added a configuration variable ENABLE_IOMMU and set it to 1 for all
existing boards except the s2885. It would be nice to have the size of
the aperture also selectable via the configuration file, or even better 
during firmware run time.

I am scared that changes for special motherboards will contaminate the
source tree and make it hard for anyone to see what is actually going
on. If this happens in a source tree for a special motherboard, it does
not really matter, but I think it is a good goal to keep the generic
code clean and generic and make it even more generic in the places where
it's not sufficient.

I'll look into coherent_ht.1.c and see if this can be done more general
as well.

I commited the attached patch. Please comment.

Stefan