coherent hypertransport hardcodes.

[Stefan Reinauer]

* YhLu  [030719 02:59]:
> I have tested Stefan's the code about coherent_ht.c, and add some hardcode
> to it.
> coherent_ht.o.c is the original one. Coherent_ht.1.c is total hardcode one.
> coherent_ht.c and coherent_ht.2.c are modified with some hardcode ones.

I am not happy with these hardcodes at all, they will make all
motherboards fail that have a different link setup than the tyan S2880
(It should be ok for hdama, but will definitely make the AMD quartet
fail)

Link speed and width setup should be done "dynamically" based on the link
capabilities of the devices connected to each other.

I wrote two functions to do this for every pair of hypertransport
devices, they should probably be enhanced to take a configurable
(per nvram or config option) maximum in addition to relying on what the
devices say.

This needs support from the motherboard specific Config.lb files,
because we need to know for every cpu which bridge/cpu is connected to 
which link on the hypertransport bus.

Tom from LNXI has also written some code that fills the speed registers
it seems. But this is executed in C-Payload when doing PCI. As we need
to assert LDTSTOP_L I am not sure whether it can be kept there. Tom?

I checked in cpu and southbridge dependent parts of LDTSTOP_L assertion,
they should be operational as soon as we know the link configuration
from the config file .

The static tree generated at the moment seems not right to me:
for the one cpu that is actually configured, several nodes are
generated:

struct chip static_dev9 = {
/* cpu /home/stepan/LinuxBIOS/freebios2/src/cpu/k8 */
  .next = &static_dev8,
};
struct chip static_dev8 = {
/* cpu /home/stepan/LinuxBIOS/freebios2/src/cpu/k7 */
  .next = &static_dev7,
};
struct chip static_dev7 = {
/* cpu /home/stepan/LinuxBIOS/freebios2/src/cpu/p6 */
  .next = &static_dev6,
};
struct chip static_dev6 = {
/* cpu /home/stepan/LinuxBIOS/freebios2/src/cpu/p5 */
  .next = &static_dev5,
};

I assume this is to allow callbacks for each cpu type the k8
"implements" at the right place. but it looks really nasty. And
it seems that there are no callbacks anyways here. Or am I wrong?

Is this really needed? It looks like this should be one entry for every
cpu that can be plugged into the system, plus for every bridge on the
system.

In the config file this shows up as:

option i686=1
 option i586=1
 option INTEL_PPRO_MTRR=1
 option k7=1
 option k8=1

Ron, is it already possible to add information on links between the
cht and ncht devices?

The chain i want to describe looks pretty much like:

K8-CPU[2] ------- K8-CPU[3]
          |                 |
          |                 |
       K8-CPU[0] ------- K8-CPU[1]
          |                 |
          |                 |
       8111-SB[0]        8131-SB[0]

with possibly multiple bridges of the same type.

Stefan