* Re: Device Tree updates for xilinx.
From: David Gibson @ 2007-12-16 7:04 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071213233945.E8FFAA6007C@mail180-sin.bigfish.com>
On Thu, Dec 13, 2007 at 03:41:16PM -0800, Stephen Neuendorffer wrote:
> These patches synchronize all the in-kernel drivers to use the
> compatible names generated by the UBoot BSP generator.
> (at git://git.xilinx.com/gen-mhs-devtree.git)
>
> The patches to make this work are coming shortly:
>
> patches 1-2 are provided for context only... They're not ready for
> mainline. They provide 'raw' boot support and port some initialization
> code from ARCH=ppc.
> patches 3-7 are the interesting patches, which I think could be taken
> for 2.6.25.
>
> I've also pushed the working tree up to git.xilinx.com containing these
> patches. This tree also includes updates for ps2, gpio, etc.
> The ll_temac currently doesn't work because I haven't gone back and
> fixed the mechanism by which it finds out about the DMA that it is
> connected to.
>
> If you want output from the boot loader, you'll need something like:
> linux,stdout-path = "/plb_v34/opb_v20/serial@40400000";
> This seems to work with uartlite, but I wasn't able to get it working
> with a UART design.
>
> Currently, you'll need to add, by hand the following labels:
>
> mem_size_cells, on the toplevel #address-cells attribue, e,g. :
> mem_size_cells: #address-cells = <1>;
Having a label called *_size_cells which is attached to
#address-cells, rather than #size-cells seems like a bad idea. Plus,
if I understood correctly, this is used to interpret the 'memsize'
value, which means it should be #size-cells anyway.
Also, if I understood the code in your later patches correctly, this
label is used as a direct pointer to the value you want. That means
it needs to be on the property value, not on the property, i.e.
#size-cells = <mem_size_cells: 1>;
instead of
mem_size_cells: #size-cells = <1>;
(the latter form will put the label on the tag which introduces the
property instead).
> timebase, on the processors timebase-frequency attribute, e.g. :
> timebase: timebase-frequency = <11e1a300>;
>
> memsize, on the memory's size, e.g.:
> DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> device_type = "memory";
> reg = < 0 memsize:10000000 >;
> } ;
>
> In addition, if you're using uartlite, you'll have to specify
> 'console=ttyUL0' as boot args.
>
> 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
^ permalink raw reply
* Re: [PATCH 1/7] bootwrapper: Add a firmware-independent "raw" target.
From: David Gibson @ 2007-12-16 11:35 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <f7eb0ae3da29213720e6b0049deca335@bga.com>
On Fri, Dec 14, 2007 at 02:05:56AM -0600, Milton Miller wrote:
> On Fri Dec 14 10:43:27 EST 2007, Stephen Neuendorffer wrote:
>
> > From: Grant Likely <grant.likely at secretlab.ca>
> >
> > This target produces a flat binary rather than an ELF file,
> > fixes the entry point at the beginning of the image, and takes
> > a complete device tree with no fixups needed.
> >
> > The device tree must have labels on /#address-cells, the timebase
> > frequency, and the memory size.
> >
> > Signed-off-by: Grant Likely <grant.likely at secretlab.ca>
> > ---
>
>
> You indicated in the intro in 0/ that this was not ready, and you
> didn't include your own s-o-b, but you did not put any statements to
> that effect in the header. The intro is not copied into patchwork,
> which maintainers often use when deciding what to push.
>
> Now on to why this should not be merged:
>
> In addition to the above, it changes the build rules. It tries to
> change wrapper to assemble the .dtb into a .o from a .S file, but
> doesn't set any flags to force the assembler into the right mode. In
> contrast the linker is controlled by the .lds linker script.
>
> In addition, the requirement for assembly labels can easily be
> eliminated. As mentioned above, they are used for 3 properties. With
> the existing library (in 2.6.24 and earlier), call simple_malloc_init
> with a small bss array (like BSS_STACK does to allocate stack), and
> then read the properties out of the device tree. At that point, call
> simple_malloc_init a second time using the found memory size. As I
> said the last time this was posted, my patches to boot from kexec
> implemented this strategy.
>
> However, with the new libfdt, which is already in for-2.6.25, we should
> no longer need malloc() to simple read the tree. At least that is
> what was advertised.
That's correct. No malloc() is necessary for read-only access.
--
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/3] [libata] pata_platform: make probe and remove functions device type neutral
From: Paul Mundt @ 2007-12-16 12:46 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Jeff Garzik, Arnd Bergmann, linux-ide, linuxppc-dev,
Olof Johansson
In-Reply-To: <20071214182429.GA1017@localhost.localdomain>
On Fri, Dec 14, 2007 at 09:24:29PM +0300, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Acked-by: Olof Johansson <olof@lixom.net>
Looks fine to me now, thanks for cleaning it up Anton.
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* [MPC5200] problem running FEC and ATA
From: Arnon Kaufman @ 2007-12-16 13:24 UTC (permalink / raw)
To: linuxppc-dev
does any one succeed running a functional FEC and ATA (pata) running
together ?
If so which version (2.6.x...) and with which architecture (powerpc or
ppc)?.
The machine I'm working on based on v2.6.21-rc6 and another one based on
v2.6.24-rc1, both configured with ARCH=powerpc.
my FEC introduce itself as: "PHY: f0003000:01", and not as f0003000:00,
I've fix it by adjusting the dts file, is that ok?
I'm getting the following, when pinging the machine:
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4401 ttl=64 time=0.249 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4402 ttl=64 time=0.285 ms
wrong data byte #52 should be 0x34 but was 0xa
#8 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27
#40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 a 35 36 37
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4403 ttl=64 time=0.233 ms
wrong data byte #20 should be 0x14 but was 0x0
#8 8 9 a b c d e f 10 11 12 13 0 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27
#40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4404 ttl=64 time=0.232 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4405 ttl=64 time=0.237 ms
-----
The offsets and values of the corrupted data are constant (can it be the
microcode?)
when enabling the PATA driver and doing some Compact flash access
operation the amount of packets corruption is getting worse.
does the pata driver needs to wait on the TIP indicator? cause it
doesn't seems to do it.
^ 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
* 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: [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 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: 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: [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: [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
* [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: 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
* 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: 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: 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-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
* [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 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
* 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
* 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
* 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
* 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
* 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 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
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