[PATCH 10/11] Add MPC8360EMDS board support

[Li Yang-r58472]

> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> Sent: Wednesday, September 27, 2006 9:34 PM
> To: Li Yang-r58472
> Cc: Vitaly Bordug; linuxppc-dev at ozlabs.org; Paul Mackerras
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
> 
> >>>> +memory {
> >>>> +               device_type = "memory";
> >>>> +               linux,phandle = <300>;
> >>>> +               reg = <00000000 4000000 f4500000 00000020>;
> >>>> +       };
> >>>> the second pair is about bcsr and its size.
> >>>>
> >>>> Just in case this may help (and wondering if I'm not violating
> >>> something :) )
> >>>
> >>> Well, this can make it work.  But I would prefer to use a new node
> >>> because the BCSR is by no means a memory type of device.  I have
> > made my
> >>> change to use node like this:
> >>>
> >>>         bcsr at f8000000 {
> >>>                 device_type = "board-control";
> >>>                 reg = <f8000000 8000>;
> >>>         };
> >>>
> >>
> >> I though about that approach, but saw somewhere a reference that we
> > should not summon
> >> new node types without utter necessity, and utilized memory because
> > bcsr is
> >> memory-mapped stuff. I can hardly imagine bcsr as a device (which
> > would require
> >> respective spec inclusion btw).
> >
> > Well I didn't see such a guideline.  However BCSR is truly a device
> > like
> > any other peripherals on board.  Usually it is an FPGA on local bus
to
> > control the board.
> 
> Agree that a new node is better, calling it memory isn't right.
> However, I'm not sure this really needs a node in the device tree.
> The BCSR isn't really the same from board to board last time I
> checked.  I'd be interested in Paul's thinking about why it should be
> in the tree.
> 
> >> hence let's open a discussion what others think about that. The
> > problem seems common
> >> (and for some boards
> >> is called somewhat else apparently), but at this point we should
come
> > to some
> >> conclusion, document it, and use it.
> >
> > Agreed.  As we are adding more devices to the device tree, we should
> > also have a guideline clearly stated for adding new nodes.
> >
> > I'm adding MURAM as a new node under QE bus.  Please comment.
> >                 muram at 10000 {
> >                         device_type = "memory";
> >                         ranges = <0 00010000 0000c000>;
> >
> >                         data-only at 0{
> >                                 reg = <0 c000>;
> >                         };
> >                 };
> 
> What was the need for this?


Data-only defines MURAM area which can be allocated for data and
parameter ram.  Some MURAM space can be occupied by microcode or
microcode patch, and should be excluded from allocation.

- Leo