> + PowerPC,[EMAIL PROTECTED] {
Maybe it would be good to use "PowerPC,e500" instead -- it would
make it easier to probe for the actual CPU type, that way. Not
that Linux uses the name/compatible here at all ;-)
>>>
>>> I thought about this, not sure what the best s
On Sep 13, 2007, at 12:06 PM, Segher Boessenkool wrote:
+ PowerPC,[EMAIL PROTECTED] {
>>>
>>> Maybe it would be good to use "PowerPC,e500" instead -- it would
>>> make it easier to probe for the actual CPU type, that way. Not
>>> that Linux uses the name/compatible here at all ;-)
>>> + PowerPC,[EMAIL PROTECTED] {
>>
>> Maybe it would be good to use "PowerPC,e500" instead -- it would
>> make it easier to probe for the actual CPU type, that way. Not
>> that Linux uses the name/compatible here at all ;-)
>
> I thought about this, not sure what the best solution is.
On Wed, Sep 12, 2007 at 10:28:24PM -0500, Kumar Gala wrote:
[snip]
> >> + [EMAIL PROTECTED] {
> >
> > You should put an interrupt-parent in here, so you can get rid of
> > it in all the children.
>
> Are interrupt-parent's inherited by child nodes?
Strictly speaking, a node's default interrupt-p
On Sep 12, 2007, at 8:36 AM, Segher Boessenkool wrote:
> Looks a lot better, thanks!
>
> Some minor nits and suggestions...
>
>> +/ {
>> +model = "fsl,MPC8572DS";
>> +compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
>
> We don't want "xx" compatible entries; especially here it makes
> no se
On Sep 12, 2007, at 9:10 AM, Segher Boessenkool wrote:
+ i8259: [EMAIL PROTECTED] {
+ reg = <1 20 2
+ 1 a0 2
+
>>> + i8259: [EMAIL PROTECTED] {
>>> + reg = <1 20 2
>>> + 1 a0 2
>>> + 1 4d0 2>;
>>> +
+ [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.
"reg" f
Looks a lot better, thanks!
Some minor nits and suggestions...
> +/ {
> + model = "fsl,MPC8572DS";
> + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
We don't want "xx" compatible entries; especially here it makes
no sense at all. If the board is compatible to some other (older)
board,
+ reg = ;
+ fsl,has-rstcr;
+ };
+
+ mpic: [EMAIL PROTECTED] {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+
David,
I'm splitting this up since the mdio & phy comments are more general
that the 8572.dts
>>> [snip]
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
>>>
>>> I don't thi
On Tue, Sep 11, 2007 at 10:33:20PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 10:11 PM, David Gibson wrote:
>
> > On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
> >> Added basic board port for MPC8572 DS reference platform that is
> >> similiar to the MPC8544/33 DS reference pl
On Sep 11, 2007, at 10:11 PM, David Gibson wrote:
> On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
>> Added basic board port for MPC8572 DS reference platform that is
>> similiar to the MPC8544/33 DS reference platform in uniprocessor
>> mode.
>>
>> ---
>>
>> Rev 3 -- updates to th
On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
> Added basic board port for MPC8572 DS reference platform that is
> similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
>
> ---
>
> Rev 3 -- updates to the device tree based on discussion on how we want
> to handle me
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Rev 3 -- updates to the device tree based on discussion on how we want
to handle memory busses going forward.
arch/powerpc/boot/dts/mpc8572ds.dts |
15 matches
Mail list logo
