[COMMIT] Infrastructure Updates 4

[Eric W. Biederman]

Stefan Reinauer <stepan at suse.de> writes:

> > The way to look at the code is that:
> > - device.c has the logic to enumerate and assign resources to devices and
> busses.
> 
> > - pci_device.c has the methods for doing that on pci devices.
> > - hypertransport.c has the methods for doing that with hypertranport devices.
> > - northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific
> >   northbridge.
> > 
> > In short dynamic resource assignment should now be pretty simple and should
> > remove the need for most of the hard codes. 
>  
> Ok, thanks for the clarification. 
> 
> The config file for the hdama looks like follows:
> northbridge amd/amdk8 "mc0"
>         pci 0:18.0
>         pci 0:18.0
>         pci 0:18.0
>         pci 0:18.1
>         pci 0:18.2
>         pci 0:18.3
>         southbridge amd/amd8131 "amd8131"
>                 pci 0:0.0
>                 pci 0:0.1
>                 pci 0:1.0
>                 pci 0:1.1
>         end
>         southbridge amd/amd8111 "amd8111"
>                 pci 0:0.0
>                 pci 0:1.0
>                 pci 0:1.1
>                 pci 0:1.2
>                 pci 0:1.3
>                 pci 0:1.5
>                 pci 0:1.6
>                 superio NSC/pc87360
>                   [..]
>                 end
>         end
> end
> 
> northbridge amd/amdk8 "mc1"
>         pci 0:19.0
>         pci 0:19.0
>         pci 0:19.0
>         pci 0:19.1
>         pci 0:19.2
>         pci 0:19.3
> end
> 
> cpu k8 "cpu0"
>         register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }"
> end
> 
> cpu k8 "cpu1" 
> end
> 
> What's the meaning of the "pci" command? why are some mentioned
> multiple times? (0:18.0, 0:19.0)

First the most basic result I have is that I need to know what all of the
logical devices that come out of a chip are.

So off of each logical device I have one or more channels.  The only
way I could think of to describe multiple channels is to repeat
the logical device in the configuration file. 

All of the logical device paths are relative to the device they are hanging
off of (it just looks like the bus number).  So to say the amd/amd8131 was
hanging off of the second hypertransport link I would change it's logical
devices to:

         southbridge amd/amd8131 "amd8131"
                 pci 1:0.0
                 pci 1:0.1
                 pci 1:1.0
                 pci 1:1.1
         end

I am not saying that is the best way to go, but it currently works.

> I started digging through the code, but I am not completely there yet.
> It seems to me it would make sense to move the register "up" information
> from cpu k8 "cpu0" to the northbridge amd/amdk8 "mc0" definition since
> its information associated with the used southbridges.

The register "up" is something that has not been used at all yet.  Personally
I am not comfortable with the fact that we have both cpu and northbridge
instances for the cpus..

> There is currently no information on how the amd8131 and 8151 are
> actually linked. 

Yes there is, but it is mostly implicit.

> Does it look like this? :
> 
>    8111
>      | 
>    8131
>      | 
>    CPU0 -- CPU1

Yes.  The order of the device structures is significant.

> In this case it could be needed to describe to which link of the 8131
> the 8111 is connected?! Would the link speed between 8131 and 8111 be
> set correctly with the current code?

Yes.  Except I don't yet have a way to automatically down clock it from 800Mhz
which it claims it can do but cannot.

> Same thing applies for the 8151 that is used in the tyan and solo
> boards. The link speed is currently written by
> src/southbridge/amd/amd8151/amd8151_agp3.c
> 
> If the code is already covered by the new ht code it could be removed
> from the 8151 code. 

Sounds good.

> If this constellation is not possible,
> amd8151_agp3.c should read the link values from static.c - What is the
> better solution?

Since it is already covered and it can be done automatically I would go there.

Eric