[PATCH 10/11] Add MPC8360EMDS board support
Kumar Gala
galak at kernel.crashing.org
Wed Sep 27 23:33:33 EST 2006
>>>> +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?
- kumar
More information about the Linuxppc-dev
mailing list