All about the duplicate code are for the multilink etc. I think after Eric
and the code to enumerate the HT belongs to the CPU0. and make the static
links to work in chip.h and ... it will be eliminated. (auto.c and
pci_device.c and cpufixup.c may all need the static config processing code)
发件人: Stefan Reinauer [mailto:firstname.lastname@example.org]
发送时间: 2003年8月28日 6:34
主题: Unified setup...
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
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
I commited the attached patch. Please comment.
SuSE Linux AG