PCI device enabling/FreeBIOS2 status (was: Re: V2 Epia report)

[Eric W. Biederman]

ron minnich <rminnich at 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