ron minnich rminnich@lanl.gov writes:
So after the final tweaks the relevant bits look like:
southbridge amd/amd8111 "amd8111" link 0 pci 0:0.0 pci 0:1.0 on pci 0:1.1 on pci 0:1.2 on pci 0:1.3 on pci 0:1.5 off pci 0:1.6 off pci 1:0.0 on pci 1:0.1 on pci 1:0.2 on pci 1:1.0 off end
I have added a link option to chips specified in the static configuration file so I can remove it from the path of every device on the chip.
I have added a bus field to the pci configuration path. If it is 0 then it is an ordinary device on the same bus as the chip. If bus is > 0 then it specifies a previous device on the chip it is hanging off of. Bus 1 hangs off the first device bus 2 hangs off of the second device etc.
That allows me to fully handle the amd8111.
I have added an enable_dev method to the chip_control structure. This is in addition to the enable method for an individual device. Having two methods cleans up a lot of weird cases and it means you don't have to assign a device some operations just to disable it :)
I have also added a chip field to struct device so the original chip structure for a device can easily be found. Which should make getting at chip_info a snap.
The working example is now checked in under src/southbridge/amd8111/amd8111.c
.............
Skimming through your VIA example there is also the case of IDE and compatibility mode. As well as enabling/disabling individual IDE channels.
IDE compatibility mode pretty much should be handled by an appropriate read_resources routine.
As for enabling/disabling individual IDE channels I'm not quite sure yet. My gut feel says I need to put a bus/parent parameter back on all paths to devices inside a chip, and then have IDE path type so I can use the existing mechanisms. Alternatively I can just use the register mechanism, and have some special fields. Enabling/disabling IDE channels with the register mechanism looks like the easiest route at moment, so it should be tried first.
......
There is remaining work to be done for irq and other resource assignment. That code could really benefit from some generic code, as it is a general problem that affects all devices.
There is also remaining work to be done to export these things with the LinuxBIOS table.
At least everything else is working well enough that these are the big problems.
.....
Romcc now knows about switches and enums, and it's optimizers are no longer buggy. There are several constant cases, and data size cases it doesn't always get right. But the big thing for romcc is to teach it not to inline, which should get the code size down quite a bit. The infrastructure is in place for that, but that will have interesting effects on code when it is enabled so it needs to be introduced carefully.
Eric