[COMMIT] Infrastructure Updates 4

[Eric W. Biederman]

Stefan Reinauer <stepan at suse.de> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [030903 17:47]:
> > 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.
>  
> Ah. this is fine and allows porting linuxbios easily to new opteron
> mainboards.
> I see some drawbacks:
> 
> * the logical devices of the amd8131 pci-x bridge has to be described in 
>   the mainboard configuration file. This means a lot of duplicate config
>   "code" spread over the mainboard directory. Can this somehow go to the
>   Config.lb file in southbridge/amd/amd8131/ ?

Yes.  But at the same time everything there is explicit and up front.
Which is not necessarily a bad thing.  It is very hard to see what is going
on if you introduce a level of indirection here to be more sparse.

I have tried for the most part to ensure that if you don't mention a logical
device it still turns up.  It is just that you can not feed it any static configuration
if it is not mentioned.

> * The device description itself and the link (channel?) information is
>   intermixed (preventing above config change from happening)

I introduced channel because that is a concept that is purely in the
configuration.  How that maps to hardware capabilities can vary.
Think a pci bridge chip with 8 pci busses hanging off of it, for
the kinds of problem I was trying to solve.

> * link information is duplicate. This might be a feature though when
>   devices happen that connect to more than one link. (Is this
>   theoretically possible, i.e. to raise bandwidth?)

A little.

> > 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..
> 
> This looks weird for the opteron case, true. But most architectures
> still don't come with an on-cpu northbridge, so keeping that seperated
> might be a good idea (in case a certain northbridge can cope with
> several cpu types)

Right.  Which is why I have not messed with it yet.

I have just stared with a rough draft that works.  I don't have
problems with changing it, so long as all of the requirements are met.

> > > Does it look like this? :
> > > 
> > >    8111
> > >      | 
> > >    8131
> > >      | 
> > >    CPU0 -- CPU1
> > 
> > Yes.  The order of the device structures is significant.
> 
> should this:
>  
>         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
>                 [..]
>         end
> 
> not rather look like this then: ?
> 
>         southbridge amd/amd8131 "amd8131"
>                 pci 0:0.0
>                 pci 0:0.1
>                 pci 0:1.0
>                 pci 0:1.1
>                 southbridge amd/amd8111 "amd8111"
>                         pci 1:0.0
>                         pci 1:1.0
>                         [..]
>                 end
>         end


Quite possibly.  A hypertransport chain is a weird case.  For the
moment I am treating it like a weird pci bus, and that seems to
work...  But further nesting might not be bad with the right set of
changes.

> > Yes.  Except I don't yet have a way to automatically down clock it from 800Mhz
> > which it claims it can do but cannot.
>  
> this seems only like a matter of the information not being parsed from
> an appropriate place in the config file yet.

Yep, pretty much.  Although for bug fixes I would like it if the
configuration file didn't have to be involved.  Just the driver for
the 8131 saying that it can't do 800Mhz which is a slightly different
thing.

Eric