* Re: [PATCH] [POWERPC] FSL: enet device tree cleanups
From: David Gibson @ 2007-12-16 6:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0712120151590.25255@blarg.am.freescale.net>
On Wed, Dec 12, 2007 at 01:52:05AM -0600, Kumar Gala wrote:
> * Removed address fields in ethernet nodes
> * Removed #address-cells, #size-cells from gianfar nodes
> * Added cell-index to gianfar and ucc ethernet nodes
> * Added enet[0..3] labels
> * Renamed compatible node for gianfar mdio to "fsl,gianfar-mdio"
> * Removed device_type = "mdio"
Hurrah! Finally.
> The matching for gianfar mdio still supports the old "mdio"/"gianfar" combo
> but it is now considered deprecated.
That's fine. It's acceptable to keep match list entries for broken
trees around pretty much indefinitely.
--
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 2/3] mpc82xx: Embedded Planet EP8248E support
From: David Gibson @ 2007-12-16 6:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071211212247.GB3620@loki.buserror.net>
On Tue, Dec 11, 2007 at 03:22:47PM -0600, Scott Wood wrote:
[snip]
> + bcsr@1,0 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <1 0 10>;
> + compatible = "fsl,ep8248e-bcsr";
> + ranges;
> +
> + mdio {
> + 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";
> + };
> + };
> + };
This mdio-under-bcsr arrangement is a bit strange. Can you explain
what's going on here?
--
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/5] PowerPC 74xx: Katana Qp device tree
From: David Gibson @ 2007-12-16 6:40 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071210211816.4657.qmail@farnsworth.org>
On Mon, Dec 10, 2007 at 02:18:16PM -0700, Dale Farnsworth wrote:
> David Gibson wrote:
> > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
> > > Device tree source file for the Emerson Katana Qp board
>
> [snip]
>
> > > + mv64x60@f8100000 { /* Marvell Discovery */
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + model = "mv64460"; /* Default */
> > > + compatible = "marvell,mv64x60";
>
> [snip]
>
> > > + mdio {
> >
> > There must be some way of actuall accessing the mdio bus, so this node
> > ought to have a 'reg' property and unit address.
>
> There is no way for the cpu to directly access the mdio bus. The
> mdio bus is internally accessed by the ethernet MAC. That being the
> case, maybe it makes more sense to move the mdio node inside of the
> multiethernet node, as follows, but I don't see how we can give it
> a reg property or a unit address.
Ah, I see. If the mdio interface isn't distinct from the other
pieces, then it probably shouldn't get a device node at all. Having
an explicit mdio bus with the phys hanging off it is convenient for
hardware which actually works that way, but it doesn't have to be done
like that.
Of course, then the question is where to hang the phy nodes, which
look like they have information you need. Since you already have a
local addressing scheme for the MACs under the multiethernet, what
probably makes sense would be to hang the phys directly under the
multiethernet, using an encoding scheme for the reg properties so that
the MACs and PHYs aren't confused (say, MACs are 0x0, 0x1, 0x2, PHYs
are 0x80000000, 0x80000001, 0x80000002).
Incidentally, although I suggested it, I'm not all that fond of the
"multiethernet" name, it was just the first thing that occurred to me.
>
> multiethernet@2000 {
> reg = <0x2000 0x2000>;
> ethernet@0 {
> device_type = "network";
> compatible = "marvell,mv64360-eth";
> reg = <0>;
> interrupts = <32>;
> interrupt-parent = <&PIC>;
> phy = <&PHY0>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> };
> ethernet@1 {
> device_type = "network";
> compatible = "marvell,mv64360-eth";
> reg = <1>;
> interrupts = <33>;
> interrupt-parent = <&PIC>;
> phy = <&PHY1>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> };
> mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "mdio";
> compatible = "marvell,mv64360-mdio";
> PHY0: ethernet-phy@1 {
> device_type = "ethernet-phy";
> compatible = "broadcom,bcm5421";
> interrupts = <76>; /* GPP 12 */
> interrupt-parent = <&PIC>;
> reg = <1>;
> };
> PHY1: ethernet-phy@3 {
> device_type = "ethernet-phy";
> compatible = "broadcom,bcm5421";
> interrupts = <76>; /* GPP 12 */
> interrupt-parent = <&PIC>;
> reg = <3>;
> };
> };
> };
--
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 RFC 0/7] "NAND on UPM" and related patches
From: David Gibson @ 2007-12-16 6:44 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071212124732.GA3904@localhost.localdomain>
On Wed, Dec 12, 2007 at 03:47:32PM +0300, Anton Vorontsov wrote:
> On Tue, Dec 11, 2007 at 11:36:47AM +1100, David Gibson wrote:
> [...]
> > > > > OF device tree GPIOs bindings are similar to IRQs:
> > > > >
> > > > > node {
> > > > > gpios = <bank pin bank pin bank pin>;
> > > > > gpio-parent = <&par_io_controller>;
> > > > > };
> > > > >
> > > > > "bank pin" scheme is controller specific, so controllers that want
> > > > > to implement flat mappings or any other could do so.
> > > >
> > > > It might be safest to do as is done for interrupts, and not define the
> > > > internal format at all.
> > >
> > > This is how it is done already. Take a look into second and third patches:
> > >
> > > +static int par_io_xlate(struct device_node *np, int index)
> > > +{
> > > + return __of_parse_gpio_bank_pin(np, index, 32, num_par_io_ports);
> > > +}
> > > +
> > > +static struct of_gpio_chip of_gpio_chip = {
> > > + .xlate = par_io_xlate,
> > > +};
> > >
> > > __of_parse_gpio_bank_pin() is helper function, I just factored
> > > it out, because both QE and CPM2 using same format.
> > >
> > > But generally, controllers are encouraged to do their own xlates.
> > >
> > > Or am I missing the point?
> >
> > Right, but you are assuming a fixed size (2 cells?)
>
> Nope, of_get_gpio() doesn't assume that, but per-controller's .xlate()
> is free to assume (and check) that, right.
Ah, ok, I see. I think doing this without an explicit '#gpio-cells'
is not a great idea, though. It would be nice to be able to sanity
check the "gpio descriptors" without having to deduce the correct
format from the controller's "compatible" property.
--
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: 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
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