On 28.10.2008 01:39, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> On 28.10.2008 00:40, ron minnich wrote:
>>> On Mon, Oct 27, 2008 at 4:25 PM, Carl-Daniel Hailfinger
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>> The explanations by Tom and Marc made a few things clear for me:
>>>> - The physical HT structure is not what we want to model.
>>>> - The appearance of HT and topology in PCI config space is what
>>>> matters.
>>>> - 18.0 is not a PCI bridge, don't pretend it is one
>>>>
>>>> With that in mind, I'd like to propose another dts.
>>>> I know that it has its own quirks, but it can serve as a discussion
>>>> point.
>>>>
>>> I'm beginning to feel like we're thinking too much.
>>>
>>
>> We were trying to coax physical connections into the dts, but then we
>> had to ignore them in the code because the logical connections and their
>> placements were different.
>>
>
> This is the right track. Addressing is what is important for resource
> allocation. Later we can add a physical connection for ht that can be
> auto-generated runtime if we decide we want to know that as well.
My biggest problem with all this stuff was that I thought we'd model the
device tree after the logical PCI topology. That would make scanning
easier and resource allocation more difficult.
However, your suggestion to model the device tree after resource
allocation topology is probably more promising. It does complicate
scanning, though.
>>> The fact is that whether or not the three HT links are a bridge, there
>>> is routing in there that makes each link logically the parent of a
>>> different set of devices. do we call that a bridge?
>>>
>>
>> Do we ever walk the HT links explicitly in the code?
>
> Not in device code. All that is done in Stage1 early init.
Hm. Since stage1 doesn't care about the device tree (yet), this allows
us to use either approach.
>>> I don't know what to do with [EMAIL PROTECTED]
>>
>> I fully agree. That's the weakest point of my dts. We can place all
>> those devices at bus 1, but for legacy reasons we may want to have them
>> at bus 0. Our choice.
>
> With the assumption that [EMAIL PROTECTED] should be any number found that
> matches
> the device. Maybe remove the @X. I don't think it does anything. I
> think that this is more correct:
My original idea was that we'd be able to specify bus numbers if we
wanted and some sort of placeholder if we didn't care.
> bus{
> [EMAIL PROTECTED],0 {
> /config/("southbridge/amd/amd8111/pci.dts");
> bus{
> [EMAIL PROTECTED],0{
> /config/("southbridge/amd/amd8111/usb.dts");
>
> Does the bus indicate anything? Would this work?
The bus element itself is needed IMO. It allows us to group devices
together which can be discovered/scanned in one go.
Instead of
[EMAIL PROTECTED],0{
[EMAIL PROTECTED],0{};
};
[EMAIL PROTECTED],0{
//some stuff behind the second link
};
[EMAIL PROTECTED],0{
//some stuff behind the third link
};
[EMAIL PROTECTED],1{};
[EMAIL PROTECTED],2{};
we'd have
[EMAIL PROTECTED],0{
[EMAIL PROTECTED]
[EMAIL PROTECTED],0{};
};
[EMAIL PROTECTED]
//some stuff behind the second link
};
[EMAIL PROTECTED]
//some stuff behind the third link
};
};
[EMAIL PROTECTED],1{};
[EMAIL PROTECTED],2{};
and that would remove the need for special magic notation in the dts.
However, it is also an interesting question on which "layer" we want to
keep the bus devices.
> [EMAIL PROTECTED],0 {
> /config/("southbridge/amd/amd8111/pci.dts");
> [EMAIL PROTECTED],0{
> /config/("southbridge/amd/amd8111/usb.dts");
>
>
>>> ah well it's been a long day, will look at this later. For now let's
>>> get myles patch in and try to see where that goes. I think I'm not
>>> ready for this dts. But if myles wants to try it that's fine too.
>>>
>>
>> Sure, as long as the dts is not set in stone, I retract my NACK and
>> encourage Myles to commit.
>
> This isn't even set in jello, never mind stone! :)
>
> Attached lspci from Serengeti (FAM10 CPU but buses should be the same).
Thanks!
>From that lspci it becomes clear that the resource tree is mostly
congruent with the logical PCI tree, but they differ significantly in a
few places. It is desirable to have both trees available: One for
resource allocation, one for device discovery. Killing either is calling
for problems down the road. Besides that, in reality we're neither
dealing with a real tree nor a completely acyclic graph.
There are easy ways out which either make the dts completely unreadable
or beget some unholy device tree code. Neither is acceptable if we
consider maintainability to be important.
The good thing is that my diploma thesis provides solutions for exactly
that class of problems. It's not about coreboot, but the problems we
face right now are so strikingly similar that I regret not writing the
whole thing in English. Anyway, I'll try to create a short writeup which
captures the essential results, and how to apply them without losing
mental sanity (or maintainability, for that matter).
The trick is to declare a preferred and readable form for storing device
relations (the existing dts structure works quite well in that regard)
and to handle different requirements for that representation like
database views. With a nice set of node properties and the right amount
of abstraction, we can keep both the code and the dts human readable and
have them provide easily understood views of their respective purposes
(resource allocation vs. device discovery). If we do it right, even such
horrors as wandering PATA/SATA PCI devices (after disabling PATA, SATA
will change its PCI devfn) are easily expressed and handled.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
