>>>> + reg = <e0000 1000>;
>>>> + fsl,has-rstcr;
>>>> + };
>>>> +
>>>> + mpic: [EMAIL PROTECTED] {
>>>> + clock-frequency = <0>;
>>>> + interrupt-controller;
>>>> + #address-cells = <0>;
>>>> + #interrupt-cells = <2>;
>>>> + reg = <40000 40000>;
>>>> + compatible = "chrp,open-pic";
>>>> + device_type = "open-pic";
>>>> + big-endian;
>>>> + };
>>>> + };
>>>> +
>>>> + [EMAIL PROTECTED] {
>>>> + compatible = "fsl,mpc8548-pcie";
>>>
>>> And again, "fsl,mpc8572-pcie", "fsl,mpc8548-pcie".
>>
>> But why? there is no difference between the PCIe controller in
>> mpc8548 and mpc8572?
>
> As far as you've yet discovered...
Its the same actual block from design. I'll think some on this. If
I had some macro support in the dtc I wouldn't feel so bad about
doing this. Its the edit/modify/fix cycle that's a pain.
>>>> + [EMAIL PROTECTED] {
>>>> + reg = <0 0 0 0 0>;
>>>
>>> This looks kind of bogus...
>>
>> Its a PCIe to PCI bridge that is transparent.
>
> Right.... if it has no control registers, I think it should just lack
> 'reg', not define a zero-length register block.
>
>>>> + #size-cells = <2>;
>>>> + #address-cells = <3>;
>>>> + ranges = <02000000 0 80000000
>>>> + 02000000 0 80000000
>>>> + 0 20000000
>>>> + 01000000 0 00000000
>>>> + 01000000 0 00000000
>>>> + 0 00100000>;
>
> And if truly transparent, it should perhaps have just ranges;
> indicating that child addresses are identity mapped to parent
> addresses.
>
>>>> +
>>>> + [EMAIL PROTECTED] {
>>>
>>> Ok.. why is pci_bridge nested within uli1575 - with the matching reg
>>> and ranges, it looks like they ought to be one device. Also if this
>>> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
>>
>> We've been using this as it stands for a while. If there are some
>> changes here that make sense I'm willing to make them.
>
> Right, at present I don't see why you couldn't just ditch the
> pci_bridge node, and drop its contents straight into the uli1575 node.
upon further review and discussion you are right about dropping the
[EMAIL PROTECTED] node from the ULI. However we do need to add a [EMAIL
PROTECTED]
node to cover the virtual P2P bridge in the PHB. So we have something
like:
[EMAIL PROTECTED] {
[EMAIL PROTECTED] {
[EMAIL PROTECTED] {
}
}
}
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
