RE: [PATCH 10/11] Add MPC8360EMDS board support
flat view
From: Li Yang-r58472 <hidden>
Date: 2006-09-27 13:20:01
-----Original Message----- From: Vitaly Bordug [mailto:vbordug@ru.mvista.com] Sent: Wednesday, September 27, 2006 8:56 PM To: Li Yang-r58472 Cc: Paul Mackerras; linuxppc-dev@ozlabs.org Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support =20 On Wed, 27 Sep 2006 20:02:56 +0800 "Li Yang-r58472" [off-list ref] wrote: =20quoted
quoted
-----Original Message----- From: Vitaly Bordug [mailto:vbordug@ru.mvista.com] Sent: Wednesday, September 27, 2006 7:56 PM To: Paul Mackerras Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support On Wed, 27 Sep 2006 16:39:11 +1000 Paul Mackerras [off-list ref] wrote:quoted
Li Yang writes:quoted
+#define BCSR_PHYS_ADDR ((uint)0xf8000000) +#define BCSR_SIZE ((uint)(32 * 1024))This sort of thing should really be in the device tree.Just a suggestion, but for the similar aim in pq2 I have those
stuff
quoted
in memory node :quoted
+memory { + device_type =3D "memory"; + linux,phandle =3D <300>; + reg =3D <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 violatingsomething :) ) 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
quoted
change to use node like this: bcsr@f8000000 { device_type =3D "board-control"; reg =3D <f8000000 8000>; };=20 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.
=20 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. =20
I'm adding MURAM as a new node under QE bus. Please comment.
muram@10000 {
device_type =3D "memory";
ranges =3D <0 00010000 0000c000>;
data-only@0{
reg =3D <0 c000>;
};
};
- Leo