Commit graph

2 commits

Author SHA1 Message Date
Ronald G. Minnich
cedf16ca69 Marc reviewed the v3 device tree code and we developed the set of
cleanups/fixes.

Fixup device tree code. Add/change methods as needed. 
This should help serengeti.
Signed-off-by: Ronald G. Minnich<rminnich@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Corey Osgood <corey.osgood@gmail.com>
Acked-by: Marc Jones <marc.jones@amd.com>


git-svn-id: svn://coreboot.org/repository/coreboot-v3@954 f3766cd6-281f-0410-b1cd-43a5c92072e9
2008-10-27 20:05:38 +00:00
Ronald G. Minnich
cadd0126aa First cut at moving from v2 to v3.
There are some interesting issues here. The enables for the various 
devices are a global bitmask: 
Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)

But v3 would allow us to not have the bit mask. OTOH, we would end up 
with 3 .dts files for the pcie ports for this enable; good or bad? 
GOOD --> highly custom configuration possible for each port
BAD --> 3 .dts files

Part of the issue is that the link from the dts to the device operations 
structure is done as follows: 
struct device_operations sb600_usb2 = {
	.id = {.type = DEVICE_ID_PCI,
		{.pci = {.vendor = PCI_VENDOR_ID_ATI,
			      .device = PCI_DEVICE_ID_ATI_SB600_USB2}}},

And this structure is named in the .dts for that device_operations:
{
	device_operations = "sb600_usb2";
};

requiring a different dts node for each set of device_operations. 

The device tree compiler generates the code to create these connections 
and puts that code into the the static_tree.c file. 

Having a .dts file for each port gives us a lot of flexibility; but is 
it too inconvenient? This is an unresolved problem; unhandled at present 
for the *6* USB ports for the sb600. 

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>



git-svn-id: svn://coreboot.org/repository/coreboot-v3@886 f3766cd6-281f-0410-b1cd-43a5c92072e9
2008-10-03 15:47:10 +00:00