* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: David Gibson @ 2007-12-17 5:14 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071215162331.GA24999@localhost.localdomain>
On Sat, Dec 15, 2007 at 07:23:31PM +0300, Anton Vorontsov wrote:
> On Tue, Dec 11, 2007 at 12:42:18PM -0600, Kumar Gala wrote:
[snip]
> + soc8360@e0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 0xe0000000 0x00100000>;
> + reg = <0xe0000000 0x00000200>;
> + /* filled by u-boot */
> + bus-frequency = <0>;
> +
> + wdt@200 {
> + device_type = "watchdog";
Drop this device_type.
> + compatible = "mpc83xx_wdt";
> + reg = <0x200 0x100>;
> + };
> +
> + i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
And this one.
[snip]
> + crypto@30000 {
> + device_type = "crypto";
> + model = "SEC2";
> + compatible = "talitos";
This device_type/compatible/model stuff is also crap, although I
suspect it needs to be fixed in the driver, as gianfar (finally) was.
[snip]
> + ipic: pic@700 {
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + reg = <0x700 0x100>;
> + device_type = "ipic";
And drop this device_type.
[snip]
> + qe@e0100000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "qe";
And this one.
This node needs a "compatible" too.
> + model = "QE";
> + ranges = <0 0xe0100000 0x00100000>;
> + reg = <0xe0100000 0x480>;
> + /* filled by u-boot */
> + brg-frequency = <0>;
> + bus-frequency = <0>;
This should probably be clock-frequency, not bus-frequency. After
all, it's a bus node, what other sort of frequency would it be.
> + muram@10000 {
> + device_type = "muram";
And this device_type needs to go, too.
> + ranges = <0 0x00010000 0x0000c000>;
> +
> + data-only@0 {
> + reg = <0 0xc000>;
> + };
> + };
> +
> + spi@4c0 {
> + device_type = "spi";
And this one.
[snip]
> + usb@6c0 {
> + device_type = "usb";
And this one.
> + compatible = "qe_udc";
> + reg = <0x6c0 0x40 0x8b00 0x100>;
> + interrupts = <11>;
> + interrupt-parent = <&qeic>;
> + mode = "slave";
> + };
[snip]
> + mdio@2120 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2120 0x18>;
> + device_type = "mdio";
And this one.
> + compatible = "ucc_geth_phy";
> +
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
These phy nodes have basically no information in them. PHY nodes are
optional - only include them if they actually have something useful to
say (which would mean at least a compatible property).
[snip]
> + qeic: qeic@80 {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + device_type = "qeic";
Drop this device_type, too.
And this node, too, needs a "compatible" property. Oh, and the node
name should be "interrupt-controller@80" by the generic names
convention.
> + reg = <0x80 0x80>;
> + big-endian;
> + interrupts = <32 8 33 8>;
> + interrupt-parent = <&ipic>;
> + };
> + };
> +};
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: Device Tree updates for xilinx.
From: Stephen Neuendorffer @ 2007-12-17 4:58 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071216070404.GK21311@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]
Since there don't seem to be any examples of this in the tree: do you have a format preference? For the rest of the compatible lists, I'm using something like: xlnx,ipname-version. So for the microblaze, I'd prefer something like:
xlnx,microblaze-6.00.b
For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be more in character than PowerPC,405.
Steve
-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]
Sent: Sat 12/15/2007 11:04 PM
To: Stephen Neuendorffer
Cc: Grant Likely; Michal Simek; John Williams; linuxppc-dev@ozlabs.org; git
Subject: Re: Device Tree updates for xilinx.
On Thu, Dec 13, 2007 at 03:41:16PM -0800, Stephen Neuendorffer wrote:
>
> For reference, below is the device tree for a Virtex2Pro design. Except
> for the changes noted above, this is entirely automatically generated.
>
> Steve
>
> / {
> mem_size_cells: #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,virtex";
> model = "testing";
> DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> device_type = "memory";
> reg = < 0 memsize:10000000 >;
> } ;
> chosen {
> bootargs = "root=/dev/nfs
> nfsroot=172.19.221.221:/exports/xup/ydl41 ip=dhcp console=ttyUL0";
> } ;
> cpus {
> #address-cells = <1>;
> #cpus = <1>;
> #size-cells = <0>;
> PowerPC,405@0 {
I'm trying to encourage people to move to naming cpu nodes simply
"cpu@XX", with the type of core in "compatible" instead - in keeping
with the generic names convention used elsewhere. I think this will
make your generator simpler, too.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: text/html, Size: 3744 bytes --]
^ permalink raw reply
* RE: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Stephen Neuendorffer @ 2007-12-17 4:48 UTC (permalink / raw)
To: Grant Likely, simekm2, jwilliams, linuxppc-dev
In-Reply-To: <fa686aa40712162030q6f0e6d87j5e6e5379cbd0d54e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]
Compound devices that actually have their own shared registers should do something different. Likely they'll need some sort of data synchronization anyway. It seems that by far the common case here is to going to be to just have aggregation, and I don't see any reason that can't be handled by a common 'pseudo-bus'.
Steve
-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Sun 12/16/2007 8:30 PM
To: Stephen Neuendorffer; grant.likely@secretlab.ca; simekm2@fel.cvut.cz; jwilliams@itee.uq.edu.au; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
On 12/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> > This now better describes what the UBoot device tree generator actually does. In particular:
> >
> > 1) Nodes have a label derived from the device name, and a node name
> > derived from the device type.
> > 2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
>
> I'm not sure I like this xlnx,compound business, although maybe it's
> the best you can do.
I'd prefer something like "xlnx,<ip-name>-group". "xlnx,compound" is
a very bad idea because it will be reused for very different types of
devices. What happens when a device appears that has both
per-instance properties and 'top level' registers accessed by both
devices?
[-- Attachment #2: Type: text/html, Size: 2286 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Grant Likely @ 2007-12-17 4:30 UTC (permalink / raw)
To: Stephen Neuendorffer, grant.likely, simekm2, jwilliams,
linuxppc-dev
In-Reply-To: <20071217041455.GA3477@localhost.localdomain>
On 12/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> > This now better describes what the UBoot device tree generator actually does. In particular:
> >
> > 1) Nodes have a label derived from the device name, and a node name
> > derived from the device type.
> > 2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
>
> I'm not sure I like this xlnx,compound business, although maybe it's
> the best you can do.
I'd prefer something like "xlnx,<ip-name>-group". "xlnx,compound" is
a very bad idea because it will be reused for very different types of
devices. What happens when a device appears that has both
per-instance properties and 'top level' registers accessed by both
devices?
>
> > 3) Uartlite requires a port-number property for the console to work.
>
> Why? In general we try to avoid magical sequence numbers - cell-index
> should *only* be used when it's needed to index or program some shared
> register.
Aliases is probably the correct construct for this. port-number was a
bad idea and I never should have gone that direction.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: David Gibson @ 2007-12-17 4:14 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, simekm2
In-Reply-To: <20071213234151.D0B3DE80061@mail20-sin.bigfish.com>
On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> This now better describes what the UBoot device tree generator actually does. In particular:
>
> 1) Nodes have a label derived from the device name, and a node name
> derived from the device type.
> 2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
I'm not sure I like this xlnx,compound business, although maybe it's
the best you can do.
> 3) Uartlite requires a port-number property for the console to work.
Why? In general we try to avoid magical sequence numbers - cell-index
should *only* be used when it's needed to index or program some shared
register.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v2 2/3] mpc82xx: Embedded Planet EP8248E support
From: David Gibson @ 2007-12-17 3:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071212225429.GB19027@loki.buserror.net>
On Wed, Dec 12, 2007 at 04:54:29PM -0600, Scott Wood wrote:
> This board is also resold by Freescale under the names
> "QUICCStart MPC8248 Evaluation System" and "CWH-PPC-8248N-VE".
[snip]
> + localbus {
Should be localbus@f0010100.
> + compatible = "fsl,ep8248e-localbus",
> + "fsl,mpc8248-localbus",
> + "fsl,pq2-localbus";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <f0010100 40>;
> +
> + ranges = <0 0 fc000000 04000000
> + 1 0 fa000000 00008000>;
> +
> + flash@0,3800000 {
> + compatible = "cfi-flash";
> + reg = <0 3800000 800000>;
> + bank-width = <4>;
> + device-width = <2>;
> + };
> +
> + bcsr@1,0 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <1 0 10>;
> + compatible = "fsl,ep8248e-bcsr";
> + ranges;
> +
> + mdio {
As I think I said about another tree, this mdio-under-bcsr arrangement
is pretty strange. What's going on here.
> + device_type = "mdio";
> + compatible = "fsl,ep8248e-mdio-bitbang";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1 8 1>;
> +
> + PHY0: ethernet-phy@0 {
> + interrupt-parent = <&PIC>;
> + reg = <0>;
> + device_type = "ethernet-phy";
> + };
> +
> + PHY1: ethernet-phy@1 {
> + interrupt-parent = <&PIC>;
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
> + };
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0>;
> + };
> +
> + soc@f0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
Ditch the device_type.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v2 1/3] 8xx: Analogue & Micro Adder875 board support.
From: David Gibson @ 2007-12-17 3:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071212225427.GA19027@loki.buserror.net>
On Wed, Dec 12, 2007 at 04:54:27PM -0600, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> diff --git a/arch/powerpc/boot/dts/adder875-redboot.dts b/arch/powerpc/boot/dts/adder875-redboot.dts
> new file mode 100644
> index 0000000..4d28220
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/adder875-redboot.dts
[snip]
> diff --git a/arch/powerpc/boot/dts/adder875-uboot.dts b/arch/powerpc/boot/dts/adder875-uboot.dts
> new file mode 100644
> index 0000000..33d198c
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/adder875-uboot.dts
Having two different device trees for the different firmwares is
pretty yucky, and could be a pain in the bum for synchronization of
fixes. Can't you have a common tree, and just poke the places that
are differently configured by the two firmwares from the bootwrapper.
A helper function that adjusts soc, localbus, pci and whatever else is
necessary based on the immrbase could be useful for other fsl
platforms, too.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* libfdt: Add more documentation (patch the seventh)
From: David Gibson @ 2007-12-17 3:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch adds more documenting comments to libfdt.h. Specifically,
these document the read/write functions (not including fdt_open_into()
and fdt_pack(), for now).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-12-12 09:20:48.000000000 +1100
+++ dtc/libfdt/libfdt.h 2007-12-12 23:31:39.000000000 +1100
@@ -797,23 +797,242 @@ int fdt_finish(void *fdt);
int fdt_open_into(const void *fdt, void *buf, int bufsize);
int fdt_pack(void *fdt);
+/**
+ * fdt_add_mem_rsv - add one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @addres, @size: 64-bit values (native endian)
+ *
+ * Adds a reserve map entry to the given blob reserving a region at
+ * address address of length size.
+ *
+ * This function will insert data into the reserve map and will
+ * therfore change the indexes of some entries in the table.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new reservation entry
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
+
+/**
+ * fdt_del_mem_rsv - remove a memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @n: entry to remove
+ *
+ * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
+ * the blob.
+ *
+ * This function will delete data from the reservation table and will
+ * therfore change the indexes of some entries in the table.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
+ * are less than n+1 reserve map entries)
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
int fdt_del_mem_rsv(void *fdt, int n);
+/**
+ * fdt_setprop - create or change a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to set the property value to
+ * @len: length of the property value
+ *
+ * fdt_setprop() sets the value of the named property in the given
+ * node to the given value and length, creeating the property if it
+ * does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new property value
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
int fdt_setprop(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
+
+/**
+ * fdt_setprop_cell - set a property to a single cell value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: 32-bit integer value for the property (native endian)
+ *
+ * fdt_setprop_cell() sets the value of the named property in the
+ * given node to the given cell value (converting to big-endian if
+ * necessary), or creates a new property with that value if it does
+ * not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new property value
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
uint32_t val)
{
val = cpu_to_fdt32(val);
return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
}
+
+/**
+ * fdt_setprop_string - set a property to a string value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @str: string value for the property
+ *
+ * fdt_setprop_string() sets the value of the named property in the
+ * given node to the given string value (using the length of the
+ * string to determine the new length of the property), or creates a
+ * new property with that value if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new property value
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
#define fdt_setprop_string(fdt, nodeoffset, name, str) \
fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
+
+/**
+ * fdt_delprop - delete a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_del_property() will delete the given property.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOTFOUND, node does not have the named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
int fdt_delprop(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_add_subnode_namelen - creates a new node based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_add_subnode(), but use only the first namelen
+ * characters of name as the name of the new node. This is useful for
+ * creating subnodes based on a portion of a larger string, such as a
+ * full path.
+ */
int fdt_add_subnode_namelen(void *fdt, int parentoffset,
const char *name, int namelen);
+
+/**
+ * fdt_add_subnode - creates a new node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_add_subnode() creates a new node as a subnode of the node at
+ * structure block offset parentoffset, with the given name (which
+ * should include the unit address, if any).
+ *
+ * This function will insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+
+ * returns:
+ * structure block offset of the created nodeequested subnode (>=0), on success
+ * -FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ * -FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ * -FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
+ * the given name
+ * -FDT_ERR_NOSPACE, if there is insufficient free space in the
+ * blob to contain the new node
+ * -FDT_ERR_NOSPACE
+ * -FDT_ERR_BADLAYOUT
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings.
+ */
int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_del_node - delete a node (subtree)
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_del_node() will remove the given node, including all its
+ * subnodes if any, from the blob.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
int fdt_del_node(void *fdt, int nodeoffset);
/**********************************************************************/
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* libfdt: Add more documentation (patch the sixth)
From: David Gibson @ 2007-12-17 3:41 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch adds some more documenting comments to libfdt.h.
Specifically this documents all the write-in-place functions.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-12-11 14:23:09.000000000 +1100
+++ dtc/libfdt/libfdt.h 2007-12-11 14:40:11.000000000 +1100
@@ -655,8 +655,65 @@ int fdt_node_offset_by_compatible(const
/* Write-in-place functions */
/**********************************************************************/
+/**
+ * fdt_setprop_inplace - change a property's value, but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * fdt_setprop_inplace() replaces the value of a given property with
+ * the data in val, of length len. This function cannot change the
+ * size of a property, and so will only work if len is equal to the
+ * current length of the property.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, if len is not equal to the property's current length
+ * -FDT_ERR_NOTFOUND, node does not have the named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
+
+/**
+ * fdt_setprop_inplace_cell - change the value of a single-cell property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: cell (32-bit integer) value to replace the property with
+ *
+ * fdt_setprop_inplace_cell() replaces the value of a given property
+ * with the 32-bit integer cell value in val, converting val to
+ * big-endian if necessary. This function cannot change the size of a
+ * property, and so will only work if the property already exists and
+ * has length 4.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, if the property's length is not equal to 4
+ * -FDT_ERR_NOTFOUND, node does not have the named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
const char *name, uint32_t val)
{
@@ -664,7 +721,54 @@ static inline int fdt_setprop_inplace_ce
return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
}
+/**
+ * fdt_nop_property - replace a property with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_nop_property() will replace a given property's representation
+ * in the blob with FDT_NOP tags, effectively removing it from the
+ * tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the property, and will not alter or move any other part of the
+ * tree.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOTFOUND, node does not have the named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_nop_node - replace a node (subtree) with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_nop_node() will replace a given node's representation in the
+ * blob, including all its subnodes, if any, with FDT_NOP tags,
+ * effectively removing it from the tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the node and its properties and subnodes, and will not alter or
+ * move any other part of the tree.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
int fdt_nop_node(void *fdt, int nodeoffset);
/**********************************************************************/
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2] wrapper: rename offset in offset_devp().
From: David Gibson @ 2007-12-17 0:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071212154528.7aaaa829.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
On Wed, Dec 12, 2007 at 03:45:28PM +1100, Stephen Rothwell wrote:
> On Tue, 11 Dec 2007 15:23:04 -0600 Scott Wood <scottwood@freescale.com> wrote:
> >
> > #define offset_devp(off) \
> > ({ \
> > - int offset = (off); \
> > - check_err(offset) ? NULL : (void *)(offset+1); \
> > + int _offset = (off); \
> > + check_err(_offset) ? NULL : (void *)(_offset+1); \
> > })
>
> Just wondering if this could be a static inline function?
Alas, not really. If we did that, then the __FUNCTION__ and __LINE__
we use in the error message inside check_err() would always refer to
the offset_devp() function, which would be substantially less useful
than referring to the function which invoked the offset_devp() macro.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] wrapper: rename offset in offset_devp().
From: David Gibson @ 2007-12-17 0:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071211212303.GA3661@loki.buserror.net>
On Tue, Dec 11, 2007 at 03:23:04PM -0600, Scott Wood wrote:
> fdt_wrapper_create_node passes a variable called offset to offset_devp(),
> which uses said parameter to initialize a local variable called offset.
>
> Due to one of the odder aspects of the C language, the result is an
> undefined variable, with no error or warning.
Ouch, nasty! Good catch.
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] Fix sleep on powerbook 3400
From: Paul Mackerras @ 2007-12-17 0:30 UTC (permalink / raw)
To: linuxppc-dev
Sleep on the powerbook 3400 has been broken since the change that made
powerbook_sleep_3400 call pmac_suspend_devices(), which disables
interrupts. There are a couple of loops in powerbook_sleep_3400 that
depend on interrupts being enabled, and in fact it has to have
interrupts enabled at the point of going to sleep since it is an
interrupt from the PMU that wakes it up.
This fixes it by using pmu_wait_complete() instead of a spinloop, and
by explicitly enabling interrupts before putting the CPU into sleep
mode (which is OK since all interrupts except the PMU interrupt have
been disabled at the interrupt controller by this stage).
This also changes the logic to keep putting the CPU into sleep mode
until the completion of the interrupt transaction from the PMU that
signals the end of sleep. Also, we now call pmu_unlock() before sleep
so that the via_pmu_interrupt() code can process the interrupt event
from the PMU properly.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 35e1f22..6f91723 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2276,7 +2276,7 @@ powerbook_sleep_3400(void)
{
int ret, i, x;
unsigned int hid0;
- unsigned long p;
+ unsigned long p, msr;
struct adb_request sleep_req;
void __iomem *mem_ctrl;
unsigned int __iomem *mem_ctrl_sleep;
@@ -2315,10 +2315,10 @@ powerbook_sleep_3400(void)
/* Ask the PMU to put us to sleep */
pmu_request(&sleep_req, NULL, 5, PMU_SLEEP, 'M', 'A', 'T', 'T');
- while (!sleep_req.complete)
- mb();
+ pmu_wait_complete(&sleep_req);
+ pmu_unlock();
- pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,1);
+ pmac_call_feature(PMAC_FTR_SLEEP_STATE, NULL, 0, 1);
/* displacement-flush the L2 cache - necessary? */
for (p = KERNELBASE; p < KERNELBASE + 0x100000; p += 0x1000)
@@ -2329,18 +2329,19 @@ powerbook_sleep_3400(void)
hid0 = mfspr(SPRN_HID0);
hid0 = (hid0 & ~(HID0_NAP | HID0_DOZE)) | HID0_SLEEP;
mtspr(SPRN_HID0, hid0);
- mtmsr(mfmsr() | MSR_POW | MSR_EE);
- udelay(10);
+ local_irq_enable();
+ msr = mfmsr() | MSR_POW;
+ while (asleep) {
+ mb();
+ mtmsr(msr);
+ isync();
+ }
+ local_irq_disable();
/* OK, we're awake again, start restoring things */
out_be32(mem_ctrl_sleep, 0x3f);
- pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,0);
+ pmac_call_feature(PMAC_FTR_SLEEP_STATE, NULL, 0, 0);
pbook_pci_restore();
- pmu_unlock();
-
- /* wait for the PMU interrupt sequence to complete */
- while (asleep)
- mb();
pmac_wakeup_devices();
pbook_free_pci_save();
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: David Gibson @ 2007-12-17 0:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <9618c94dbc228065db8bd99fbf6b7ba6@kernel.crashing.org>
On Sun, Dec 16, 2007 at 11:44:50PM +0100, Segher Boessenkool wrote:
> >> Hopefully some version that stores path strings in the properties
> >> in /aliases, and not phandles. Or does that current version of DTC
> >> do that correctly already, and just has an inconvenient source
> >> syntax?
> >
> > I don't think anyone's actually gone and generated phandles in
> > /aliases, although it was suggested early on. The syntax is
> > foo = < &bar >;
> > to generate a phandle and
> > foo = &bar;
> > to generate a path.
>
> Ah, I see.
>
> > I was a bit worried about confusion between these forms, but at least
> > Kumar and myself came up with this syntax independently, which
> > suggests it's not too surprising to most people, and no-one had any
> > other suggestions.
>
> I think I suggested it before, but anyway:
>
> how about you write
>
> aliases {
> foo = "/the/path/to/foo";
> };
>
> and then you can use &foo in the rest of the DTS to refer to the
> phandle (or path string, as it turns out :-) ) of the node? I.e.,
> use the aliases node to _generate_ aliases.
>
> Seems simpler than the current thing to me.
No. First, it's much nicer to have the label definition local to the
node it's labelling, rather than having to keep looking over at the
aliases node. Second, this syntax can only generate labels to nodes,
whereas the current syntax can label properties, their contents and
reserve entries as well. Third, we absolutely don't want to ditch the
current well-established and widely used syntax.
What I do want to add is a way of making aliases from labels without
having to explicitly fill in the aliases node. Perhaps something like
EMAC0[ethernet0]: ethernet@... { ... };
which would be equivalent to
EMAC0: ethernet@... { ... };
...
aliases { ethernet0 = &EMAC0; };
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Segher Boessenkool @ 2007-12-16 22:44 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071216223342.GD26307@localhost.localdomain>
>> Hopefully some version that stores path strings in the properties
>> in /aliases, and not phandles. Or does that current version of DTC
>> do that correctly already, and just has an inconvenient source
>> syntax?
>
> I don't think anyone's actually gone and generated phandles in
> /aliases, although it was suggested early on. The syntax is
> foo = < &bar >;
> to generate a phandle and
> foo = &bar;
> to generate a path.
Ah, I see.
> I was a bit worried about confusion between these forms, but at least
> Kumar and myself came up with this syntax independently, which
> suggests it's not too surprising to most people, and no-one had any
> other suggestions.
I think I suggested it before, but anyway:
how about you write
aliases {
foo = "/the/path/to/foo";
};
and then you can use &foo in the rest of the DTS to refer to the
phandle (or path string, as it turns out :-) ) of the node? I.e.,
use the aliases node to _generate_ aliases.
Seems simpler than the current thing to me.
Segher
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: David Gibson @ 2007-12-16 22:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <f3ddb435a7a71cea8362ed73eb154200@kernel.crashing.org>
On Sun, Dec 16, 2007 at 07:10:02PM +0100, Segher Boessenkool wrote:
> > Applied to my candidates tree. Though I'd really like dtc to be merged
> > so that we can figure out what the in-kernel version will support.
>
> Hopefully some version that stores path strings in the properties
> in /aliases, and not phandles. Or does that current version of DTC
> do that correctly already, and just has an inconvenient source
> syntax?
I don't think anyone's actually gone and generated phandles in
/aliases, although it was suggested early on. The syntax is
foo = < &bar >;
to generate a phandle and
foo = &bar;
to generate a path.
I was a bit worried about confusion between these forms, but at least
Kumar and myself came up with this syntax independently, which
suggests it's not too surprising to most people, and no-one had any
other suggestions.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: David Gibson @ 2007-12-16 22:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071216085858.55ffddbe@vader.jdub.homelinux.org>
On Sun, Dec 16, 2007 at 08:58:58AM -0600, Josh Boyer wrote:
> On Sun, 16 Dec 2007 17:19:59 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Sat, Dec 15, 2007 at 08:55:16AM +0100, Stefan Roese wrote:
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > Acked-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied to my candidates tree. Though I'd really like dtc to be merged
> so that we can figure out what the in-kernel version will support.
I know, I know. I've been a little preoccupied lately and need to get
back to working out what to do with the merge patches.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Josh Boyer @ 2007-12-16 18:45 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese, paulus, David Gibson
In-Reply-To: <f3ddb435a7a71cea8362ed73eb154200@kernel.crashing.org>
On Sun, 16 Dec 2007 19:10:02 +0100
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > Applied to my candidates tree. Though I'd really like dtc to be merged
> > so that we can figure out what the in-kernel version will support.
>
> Hopefully some version that stores path strings in the properties
> in /aliases, and not phandles. Or does that current version of DTC
> do that correctly already, and just has an inconvenient source syntax?
I have no idea. I can't even keep track of whether various DTC
features are dts-v1 only or not, and which "version" of DTC supports
which features. That's why I'm sort of waiting for Paul to merge
whatever version of DTC he is going to merge. *HINT*
We should also probably make a clear cut DTC release Real Soon Now.
*HINT*
josh
^ permalink raw reply
* [PATCH 1/2] [RESEND] ps3: vuart: fix error path locking
From: Daniel Walker @ 2007-12-16 8:00 UTC (permalink / raw)
To: akpm
Cc: matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo,
kjwinchester
This stray down would cause a permanent sleep which doesn't seem correct.
The other uses of this semaphore appear fairly mutex like it's even initialized
with init_MUTEX() .. So here a patch for removing this one down().
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Daniel Walker <dwalker@mvista.com>
---
drivers/ps3/ps3-vuart.c | 1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.23/drivers/ps3/ps3-vuart.c
===================================================================
--- linux-2.6.23.orig/drivers/ps3/ps3-vuart.c
+++ linux-2.6.23/drivers/ps3/ps3-vuart.c
@@ -1072,7 +1072,6 @@ static int ps3_vuart_probe(struct ps3_sy
if (result) {
dev_dbg(&dev->core, "%s:%d: drv->probe failed\n",
__func__, __LINE__);
- down(&vuart_bus_priv.probe_mutex);
goto fail_probe;
}
--
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Segher Boessenkool @ 2007-12-16 18:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese, David Gibson
In-Reply-To: <20071216085858.55ffddbe@vader.jdub.homelinux.org>
> Applied to my candidates tree. Though I'd really like dtc to be merged
> so that we can figure out what the in-kernel version will support.
Hopefully some version that stores path strings in the properties
in /aliases, and not phandles. Or does that current version of DTC
do that correctly already, and just has an inconvenient source syntax?
Segher
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Robert Schwebel @ 2007-12-16 17:46 UTC (permalink / raw)
To: Arnon Kaufman; +Cc: linuxppc-dev
In-Reply-To: <47656048.7060809@gmail.com>
On Sun, Dec 16, 2007 at 07:28:40PM +0200, Arnon Kaufman wrote:
> Robert Schwebel wrote:
> >On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote:
> >>does any one succeed running a functional FEC and ATA (pata) running
> >>together?
> >
> >Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here:
> >http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/
>
> thanks, my kernels are already patched and still observing that kind of
> behavior. I'm using Domen's new FEC code and ATA from 2.6.24-rc2.
>
> playing with the XLB Master's enable and priority lead to significant
> changes (good ones) in the rate of corruption appearance. I'm afraid of
> the "new" priority I've set, as that may lead to lockups on the XLB,
> still investigating.
Do you have a reproducable test scenario we can try on our hardware?
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Arnon Kaufman @ 2007-12-16 17:28 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev
In-Reply-To: <20071216154458.GZ3851@pengutronix.de>
Robert Schwebel wrote:
> On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote:
>> does any one succeed running a functional FEC and ATA (pata) running
>> together?
>
> Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here:
> http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/
>
thanks, my kernels are already patched and still observing that kind of
behavior. I'm using Domen's new FEC code and ATA from 2.6.24-rc2.
playing with the XLB Master's enable and priority lead to significant
changes (good ones) in the rate of corruption appearance. I'm afraid of
the "new" priority I've set, as that may lead to lockups on the XLB,
still investigating.
> We've recently made the -6 release which supports ATA; although I'm not
> sure if the tests were done with networking & ATA at the same time I
> assume yes (at least while doing nfsroot). We'll re-check your scenario.
>
> Note that there has been quite some activity wrt. MPC5200, bestcom and
> fec in the mainline recently. You should test the latest 2.6.24-rc
> kernel.
>
> Robert
^ permalink raw reply
* Re: [PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
From: Scott Wood @ 2007-12-16 15:48 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20071216063020.GG21311@localhost.localdomain>
On Sun, Dec 16, 2007 at 05:30:20PM +1100, David Gibson wrote:
> This mdio-under-bcsr arrangement is a bit strange. Can you explain
> what's going on here?
It's pretty much what it looks like; MDIO is connected to a couple pins
that are controlled by some bits in the BCSR.
-Scott
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Robert Schwebel @ 2007-12-16 15:44 UTC (permalink / raw)
To: Arnon Kaufman; +Cc: linuxppc-dev
In-Reply-To: <47652712.60006@gmail.com>
On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote:
> does any one succeed running a functional FEC and ATA (pata) running
> together?
Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here:
http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/
We've recently made the -6 release which supports ATA; although I'm not
sure if the tests were done with networking & ATA at the same time I
assume yes (at least while doing nfsroot). We'll re-check your scenario.
Note that there has been quite some activity wrt. MPC5200, bestcom and
fec in the mainline recently. You should test the latest 2.6.24-rc
kernel.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Josh Boyer @ 2007-12-16 14:58 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071216061959.GD21311@localhost.localdomain>
On Sun, 16 Dec 2007 17:19:59 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sat, Dec 15, 2007 at 08:55:16AM +0100, Stefan Roese wrote:
> > Signed-off-by: Stefan Roese <sr@denx.de>
> Acked-by: David Gibson <david@gibson.dropbear.id.au>
Applied to my candidates tree. Though I'd really like dtc to be merged
so that we can figure out what the in-kernel version will support.
josh
^ permalink raw reply
* Re: Device Tree updates for xilinx.
From: Josh Boyer @ 2007-12-16 13:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071216070404.GK21311@localhost.localdomain>
On Sun, 16 Dec 2007 18:04:04 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> > cpus {
> > #address-cells = <1>;
> > #cpus = <1>;
> > #size-cells = <0>;
> > PowerPC,405@0 {
>
> I'm trying to encourage people to move to naming cpu nodes simply
> "cpu@XX", with the type of core in "compatible" instead - in keeping
> with the generic names convention used elsewhere. I think this will
> make your generator simpler, too.
cpu@XX with the model property of the node set to "PowerPC,405" please.
josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox