nested description of chains

[Stefan Reinauer]

Hi,

looking at the big picture again and again, I don't think that
nesting hypertransport devices when doing the chain description is a
very good idea as it gives us some limitations.

* CPUs (North bridges) don't fit in the scenario, since they 
  might be arranged in a circular chain:

  CPU-3 --- CPU-2
    |         |
    |         |
  CPU-0 --- CPU-1

  If trying to pack this into the nested description manner as it
  is now, we can't describe the fact that it's a circular organization:

  northbridge amd/amdk8 "mc0"
    pci 0:18.0
    [..]
    northbridge amd/amdk8 "mc1"
      pci 0:19.0
      northbridge amd/amdk8 "mc2"
        pci 0:1a.0
        northbridge amd/amdk8 "mc3"
          [..] (nesting ad nauseum)
        end
      end
    end
    northbridge amd/amdk8 "mc3"
      [..] (nesting ad nauseum)
    end
  end
  
* Non-CPU components can be described as long as they are not ring
  organized, but for Hypertransport devices the description tries 
  to hide the fact that the organization form is a chain.

  Adding a nested description for components like a superio chip makes
  perfect sense, since it's unlikely that superio chips are ever
  cascaded or put into a circular chain. Also, the connection between
  the I/O hub (southbridge) and the superio can be seen as a
  peer-to-peer connection rather than a bus that allows arbitrary links
  between all components.


The reason why I am writing this is that currently we have a hardcoded
assumption in in LinuxBIOS' coherent hypertransport setup that looks
like this:

     |                 |
    [2]               [2]
   CPU-3 [1] --- [1] CPU-2
    [0]               [0]
     |                 |
    [2]               [2]
   CPU-0 [1] --- [1] CPU-1
    [0]               [0] 
     |                 |

[x] means that HT link no x is used for a certain link.

But this is not the only available organization method for a
hypertransport setup. Assumed a CPU HT device looks like this:
     
      | [LDT2] 
   ___|__
  |      |
  | CPU0 |-- [LDT1]
  |______|
      |
      | [LDT0]

A hypertransport setup like this is a little more complex, but
still perfectly valid:
   _______________         
   |    ______   |
   |   | 8111 |  |
   |   |______|  |
   |    ___|__   |
   |   |      |  |
   |   | CPU0 |__|
   |   |______|
   | ______|
   | |     ________________
   | |  ___|__    ______  |
   | | |      |  | 8131 | |
   | | | CPU1 |--|______| |
   | | |______|           |
   | |_____|              |
   |_______               |
        ___|__            |
       |      |           |
       | CPU2 |--[term]   |
       |______|           |
   ________|              |
  |                       |
  |     [term]            |
  |    ___|__             |
  |   |      |            |
  |   | CPU3 |-------------
  |   |______|
  |______|
          
I'll look at getting this scenario supported in the coherent_ht setup.
But it would be nice to see configurations like this happen without
actually touching the code when working a new opteron based port
somewhen in future.

Comments? Flames?

    Stefan

  
-- 
Architecture Team
    SuSE Linux AG