[PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port

Kumar Gala galak at kernel.crashing.org
Thu Sep 13 01:13:35 EST 2007


>>>> +			reg = <e0000 1000>;
>>>> +			fsl,has-rstcr;
>>>> +		};
>>>> +
>>>> +		mpic: pic at 40000 {
>>>> +			clock-frequency = <0>;
>>>> +			interrupt-controller;
>>>> +			#address-cells = <0>;
>>>> +			#interrupt-cells = <2>;
>>>> +			reg = <40000 40000>;
>>>> +			compatible = "chrp,open-pic";
>>>> +			device_type = "open-pic";
>>>> +			big-endian;
>>>> +		};
>>>> +	};
>>>> +
>>>> +	pcie at ffe08000 {
>>>> +		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.

>>>> +		uli1575 at 0 {
>>>> +			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.
>
>>>> +
>>>> +			pci_bridge at 0 {
>>>
>>> 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  
pci_bridge at 0 node from the ULI.  However we do need to add a pcie at 0  
node to cover the virtual P2P bridge in the PHB. So we have something  
like:

pcie at ff808000 {
   pcie at 0 {
     uli at 0 {
     }
   }
}

- k





More information about the Linuxppc-dev mailing list