Stephan,
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)
Regards
Yinghai Lu
-----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年8月28日 6:34 收件人: linuxbios@clustermatic.org 主题: 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 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