* RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: Li Yang-r58472 @ 2007-10-23 3:38 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1, David Miller; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2701685446@az33exm24.fsl.freescale.net>
> -----Original Message-----
> From: Medve Emilian-EMMEDVE1=20
> Sent: Monday, October 22, 2007 9:48 PM
> To: David Miller
> Cc: jgarzik@pobox.com; Li Yang-r58472;=20
> netdev@vger.kernel.org; linuxppc-dev@ozlabs.org
> Subject: RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
>=20
> Hello David,
>=20
>=20
> > No piece of code in the kernel should live in a vacuum.
> >=20
> > In order to improve overall code quality, every piece of=20
> driver code=20
> > should avoid assuming things about pointer sizes and things of this=20
> > nature.
>=20
> I'm afraid we might be talking about orthogonal issues here.=20
> I actively agree that all code (not only kernel) should be=20
> written up to the coding/quality standards you mention above,=20
> but I see a difference between fixing a warning and making a=20
> driver portable (to 64-bit PowerPCs, to other platforms,=20
> etc.). If there is a kernel todo list somewhere lets add to=20
> it the task to make the ucc_geth more portable.
>=20
> > Then the driver can get enabled into the build on every=20
> platform, and=20
> > therefore nobody will break the build of this driver again since it=20
> > will get hit by "allmodconfig"
> > et al. builds even on platforms other than the one it is meant for.
> >=20
> > This hack fix is not acceptable, really.
>=20
> Are you suggesting we leave those warnings there until=20
> somebody decides to fix all the portability issues of this=20
> driver? My patch is a small and insignificant improvement and=20
> not the revolution you're asking for, but is an small=20
> improvement today (I dislike warnings) vs. an improbable big=20
> one in the future.
I'd say we can not use our way of doing things while working with the
community. The community has to consider the kernel as a whole and thus
has its own virtue. The warning has been there for some time. It stays
as an indicator that we have something to do to improve the portability.
I will work on a patch to fix this portability issue.
- Leo
^ permalink raw reply
* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-23 3:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710221859q6ea54810nba58907d5ddd966d@mail.gmail.com>
On 10/22/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> Is this what the device tree entries should look like?
>
> First example is ac97 audio:
>
> ac97@2000 { // PSC1
> device_type = "sound";
> compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
This format is so, like. 3 months ago. :-)
dtc now supports a comma separated format: property = "string1",
"string2", "string3"
Embedded nulls no longer needed.
> cell-index = <0>;
> reg = <2000 100>;
> interrupts = <2 1 0>;
> interrupt-parent = <&mpc5200_pic>;
> codec-handle = <&codec0>
> };
Isn't this the ac97 bus node? Can't the ac97 codecs simply be
children of this bus?
>
> pseudo-sound@0 { // use to trigger loading platform specific fabric driver
> device_type = "pseudo-sound"
> };
I don't think this is a good idea. The device tree is for describing
your hardware; so the layout should reflect that. Make the platform
code do the right thing with the real nodes.
>
> codec0:codec@0 {
> device_type = "codec"
> compatible = "stac9766\0ac97"
> };
>
> Second is i2s/i2c connected:
> How do I link this to the i2c bus?
>
> i2s@2000 { // PSC1
> device_type = "sound";
> compatible = "mpc5200b-psc-i2s\0mpc5200-psc-i2s";
> cell-index = <0>;
> reg = <2000 100>;
> interrupts = <2 1 0>;
> interrupt-parent = <&mpc5200_pic>;
> codec-handle = <&codec0>
> };
>
> i2c@3d00 {
> device_type = "i2c";
> compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
> cell-index = <0>;
> reg = <3d00 40>;
> interrupts = <2 f 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
> };
>
> pseudo-sound@0 { // use to trigger loading platform specific fabric driver
> device_type = "pseudo-sound"
> };
>
> codec0:codec@0 {
> device_type = "codec"
> compatible = "tas5508"
> };
I think this is what you want:
ac97@2000 { // PSC1
compatible = "fsl,mpc5200b-psc-ac97","fsl,mpc5200-psc-ac97";
cell-index = <0>;
reg = <2000 100>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = <2 1 0>;
interrupt-parent = <&mpc5200_pic>;
// The following codec stuff could be a little off; It has been
a while since I've looked
// at ac97 codec interfacing, but if I remember correctly you
can have multiple
// codecs on an ac97 bus; an audio codec and a modem codec. The following
// reflects that understanding...
ac97-codec@0 {
// This could be the audio codec
reg = <0>;
compatible = "stac9766","ac97-audio"
};
ac97-codec@1 {
// This could be the modem codec
reg = <1>;
compatible = "super-sexy-modem-codec","ac97-modem"
};
};
// Now here's a big example for i2c.
// I've shown 3 audio interfaces; 2 i2s busses and 1 i2c controller.
// This may not be realistic on a 5200, but it is a possible scenario
and this shows
// that it can be handled elegantly.
i2s@2000 { // PSC1
compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
cell-index = <0>;
reg = <2000 100>;
interrupts = <2 1 0>;
interrupt-parent = <&mpc5200_pic>;
// There are 2 codecs on this i2s bus; either only one at a time
can be used, or
// (if both the i2s controller and codecs support it) both at
the same time if audio
// stream interleaving is supported.
codec-handle = <&codec0 &codec2>;
};
i2s@2200 { // PSC2
compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
cell-index = <0>;
reg = <2200 100>;
interrupts = <2 2 0>;
interrupt-parent = <&mpc5200_pic>;
codec-handle = <&codec1>;
};
i2c@3d00 {
compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
reg = <3d00 40>;
interrupts = <2 f 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
codec0: i2s-codec@0 {
compatible = "<mfg>,tas5508";
reg = <0>;
};
codec1: i2s-codec@1 {
compatible = "<mfg>,tas5508";
reg = <1>;
};
codec2: i2s-codec@2 {
compatible = "<mfg>,tas5508";
reg = <2>;
};
};
So, this scheme describes the hardware, but it does not describe 2 of
your questions:
1. How does the device tree describe the myriad of possible circuits
that an audio codec can get dropped into, and
2. How do the drivers get probed
For question #1, I think the answer is simple... it doesn't try. :-)
As was described in the previous thread, trying to describe the
circuit is very complex and figuring out what software would do with
such a description is even worse. Instead, I propose the following:
- as much as possible, make the board firmware and the platform setup
code configure the GPIOs, port_config, and other 'fixed' configuration
- make the driver code look at either the board model/compatible
properties or add a board-unique value to the codec's compatible list.
Either way the driver can apply board specific tweaks to its
behavious. (I think the better solution is to add a value to the
front of the codec's compatible list because the same circuit can be
used on a different board and it can then claim compatibility with the
older board for just that part of the circuit).
(Segher, what are your thoughts on my above suggestion?)
As for question #2, I think you make the i2s driver probe on the i2s
bus node and the ac97 driver probe on the ac97 bus node. In both
cases, the driver can find the link to the codec; determine what kind
of system it is running on, and instantiate the appropriate ASoC
fabric driver.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Problems with allyesconfig kernel build
From: Stephen Rothwell @ 2007-10-23 4:02 UTC (permalink / raw)
To: ppc-dev; +Cc: Andrew Morton, amodra
[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]
This was first noted with the -mm tree, but has now migrated into Linus'
tree. An allyesconfig build dies in the link stage like this:
/usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern
/usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x8160): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern
/usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x81c4): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern
/usr/bin/ld: final link failed: Bad value
We already compile with -mminimal-toc and adding
-fno-optimize-sibling-call did not help.
Intuiting the obvious, I changed all the _INIT_STATIC and _INIT_GLOBAL
uses in head_64.S back to _STATIC and _GLOBAL (which just moves the code
from .text.init.refok to .text). Now the linker segfaults instead. :-)
/bin/sh: line 1: 5260 Segmentation fault ld -m elf64ppc -Bstatic --emit-relocs --build-id -o .tmp_vmlinux1 -T arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_64.o arch/powerpc/kernel/entry_64.o arch/powerpc/kernel/fpu.o init/built-in.o --start-group usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o arch/powerpc/platforms/built-in.o arch/powerpc/xmon/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o arch/powerpc/oprofile/built-in.o net/built-in.o --end-group
make[1]: *** [.tmp_vmlinux1] Error 139
$ ld --version
GNU ld (GNU Binutils for Debian) 2.18
I take this as an improvement :-)
We link .text.init.refok immediately after .text, but with
allyesconfig, .text ends up very large.
The --emit-relocs is a product of something else I am working on. So I
took that out and now get a whole lot more messages like:
/usr/bin/ld: net/built-in.o(.fixup+0x4): sibling call optimization to `.text' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text' extern
/usr/bin/ld: net/built-in.o(.fixup+0xc): sibling call optimization to `.text' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text' extern
Anyone have any ideas?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* powerpc: Fix fallout from sg_page() changes
From: Olof Johansson @ 2007-10-23 4:09 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev, mingo, torvalds, linux-kernel
In-Reply-To: <1193076664-13652-10-git-send-email-jens.axboe@oracle.com>
Fix fallout from 18dabf473e15850c0dbc8ff13ac1e2806d542c15:
In file included from include/linux/dma-mapping.h:52,
from drivers/base/dma-mapping.c:10:
include/asm/dma-mapping.h: In function 'dma_map_sg':
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
include/asm/dma-mapping.h:289: error: 'struct scatterlist' has no member named 'page'
include/asm/dma-mapping.h:290: error: 'struct scatterlist' has no member named 'page'
include/asm/dma-mapping.h: In function 'dma_sync_sg_for_cpu':
include/asm/dma-mapping.h:331: error: 'struct scatterlist' has no member named 'page'
drivers/scsi/ps3rom.c: In function 'fetch_to_dev_buffer':
drivers/scsi/ps3rom.c:150: error: 'struct scatterlist' has no member named 'page'
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index 65be95d..ff52013 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i) {
- BUG_ON(!sg->page);
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
- sg->dma_address = page_to_bus(sg->page) + sg->offset;
+ BUG_ON(!sg_page(sg));
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
+ sg->dma_address = page_to_bus(sg_page(sg)) + sg->offset;
}
return nents;
@@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(struct device *dev,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
@@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_device(struct device *dev,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline int dma_mapping_error(dma_addr_t dma_addr)
diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c
index 03f19b8..17b4a7c 100644
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -147,7 +147,7 @@ static int fetch_to_dev_buffer(struct scsi_cmnd *cmd, void *buf)
req_len = fin = 0;
scsi_for_each_sg(cmd, sgpnt, scsi_sg_count(cmd), k) {
- kaddr = kmap_atomic(sg_page(sgpnt->page), KM_IRQ0);
+ kaddr = kmap_atomic(sg_page(sgpnt), KM_IRQ0);
len = sgpnt->length;
if ((req_len + len) > buflen) {
len = buflen - req_len;
^ permalink raw reply related
* RE: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Michal Simek @ 2007-10-23 4:07 UTC (permalink / raw)
To: microblaze-uclinux
Cc: Leonid, Wolfgang Reissnegger, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20071022180700.8B3938E0088@mail19-fra.bigfish.com>
>> In my opinion will be better generate only parameters which
>> you want not all.
>> That smells with unusable parameters.
>
>In the long term, this may be true. In the short term:
>1) dtb size is not the key problem
Yes of course
>2) making sure that everything works is a key problem.
>3) The code that generates the dts should be as simple as possible,
>so that we can easily document what it does.
Yes but you must document every parameter which your generate do. The better way is
document only parameters which you want use.
>In the long term, I'm all for optimizing the device tree that gets
>built,
>assuming that it appears to be a problem in real systems.
We can optimize now. I made new version of my generator u-boot_v3_00_a (monstr.eu)
where you can simply add parameter which you want to use.
If you want use any parameter add it.
For microblaze cpu - line 1184.
And for others peripherals lines 926-980. (The last parameter of function call).
Which parameters do you want for PPC405, Grant?
Regards,
Michal Simek
This is example of generator.
/ {
model = "mONStR";
chosen {
linux,platform = <600>;
bootargs = "root=/dev/xsysace/disc0/part2";
} ;
cpus {
#size-cells = <0>;
#cpus = < 0 >;
#address-cells = <1>;
microblaze_0,5.00.c {
32-bit;
linux,boot-cpu;
device_type = "cpu";
reg = <0>;
clock-frequency = <5f5e1000>;
timebase-frequency = <1FCA055>;
i-cache-line-size = <2000>;
i-cache-size = <10>;
d-cache-line-size = <2000>;
d-cache-size = <10>;
xilinx,pvr = <0>;
xilinx,debug-enabled = <1>;
xilinx,fsl-links = <0>;
} ;
} ;
opb_mdm@41400000 {
compatible = "opb_mdm_2.00.a\0opb_mdm";
name = "debug_module";
reg = < 41400000 10000 >;
device_type = "opb_mdm";
xilinx,mb-dbg-ports = <1>;
xilinx,uart-width = <8>;
xilinx,use-uart = <1>;
} ;
opb_uartlite@40600000 {
compatible = "opb_uartlite_1.00.b\0opb_uartlite";
name = "RS232_Uart_1";
interrupts = < 4 0 >;
reg = < 40600000 10000 >;
device_type = "opb_uartlite";
xilinx,baudrate = <2580>;
xilinx,data-bits = <8>;
xilinx,clk-freq = <5f5e100>;
xilinx,odd-parity = <0>;
xilinx,use-parity = <0>;
} ;
opb_ethernet@40c00000 {
compatible = "opb_ethernet_1.04.a\0opb_ethernet";
name = "Ethernet_MAC";
interrupts = < 3 0 >;
reg = < 40c00000 10000 >;
device_type = "opb_ethernet";
xilinx,cam-exist = <0>;
xilinx,dev-blk-id = <1>;
xilinx,dev-mir-enable = <1>;
xilinx,dma-present = <1>;
xilinx,include-dev-pencoder = <1>;
xilinx,ipif-rdfifo-depth = <8000>;
xilinx,ipif-wrfifo-depth = <8000>;
xilinx,mii-exist = <1>;
} ;
opb_sysace@41820000 {
compatible = "opb_sysace_1.00.c\0opb_sysace";
name = "SysACE_CompactFlash";
reg = < 41820000 10000 >;
device_type = "opb_sysace";
xilinx,mem-width = <10>;
} ;
opb_gpio@40000000 {
compatible = "opb_gpio_3.01.b\0opb_gpio";
name = "LEDs_4Bit";
reg = < 40000000 10000 >;
device_type = "opb_gpio";
xilinx,gpio-width = <4>;
xilinx,is-dual = <0>;
} ;
memory@30000000 {
edk_name = "DDR_256MB_32MX64_rank1_row13_col10_cl2_5";
compatible = "opb_ddr";
memreg:reg = < 30000000 10000000 >;
device_type = "memory";
} ;
opb_ps2_dual_ref@7a400000 {
compatible = "opb_ps2_dual_ref_1.00.a\0opb_ps2_dual_ref";
name = "PS2_Ports";
interrupts = < 2 0 >;
interrupts = < 1 0 >;
reg = < 7a400000 10000 >;
device_type = "opb_ps2_dual_ref";
} ;
opb_timer@41c00000 {
compatible = "opb_timer_1.00.b\0opb_timer";
name = "opb_timer_1";
interrupts = < 0 0 >;
reg = < 41c00000 10000 >;
device_type = "opb_timer";
xilinx,count-width = <20>;
xilinx,one-timer-only = <0>;
} ;
opb_intc@41200000 {
compatible = "opb_intc_1.00.c\0opb_intc";
name = "opb_intc_0";
reg = < 41200000 10000 >;
device_type = "opb_intc";
} ;
opb_uart16550@40400000 {
compatible = "opb_uart16550_1.00.d\0opb_uart16550";
name = "opb_uart16550_0";
reg = < 40400000 10000 >;
device_type = "opb_uart16550";
} ;
opb_sysace@41800000 {
compatible = "opb_sysace_1.00.c\0opb_sysace";
name = "opb_sysace_0";
reg = < 41800000 10000 >;
device_type = "opb_sysace";
xilinx,mem-width = <10>;
} ;
} ;
^ permalink raw reply
* Re: Problems with allyesconfig kernel build
From: Stephen Rothwell @ 2007-10-23 4:07 UTC (permalink / raw)
To: ppc-dev; +Cc: Andrew Morton, amodra
In-Reply-To: <20071023140231.12698d1c.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
On Tue, 23 Oct 2007 14:02:31 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> We link .text.init.refok immediately after .text, but with
> allyesconfig, .text ends up very large.
Just to give you some idea of what "very large" means, this is an
allyesconfig built vmlinux from August:
$ ls -l vmlinux
-rwxr-xr-x 1 sfr sfr 378704409 2007-08-21 13:44 vmlinux
$ size vmlinux
text data bss dec hex filename
41368641 9142448 3491272 54002361 33802b9 vmlinux
:-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Difference between ioremap() and phy_to_virt() Kernel function
From: Misbah khan @ 2007-10-23 4:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200710221304.44275.arnd@arndb.de>
Thanks Arnd
But i wish to know that could i use phy_to_virt() function in place io
ioremap() ????? And could you give me an example where we could use
phy_to_virt(). ioremap() implementation i have already done.
---Misbah
Arnd Bergmann wrote:
>
> On Monday 22 October 2007, Misbah khan wrote:
>> Could you Please let me know what is the difference between ioremap() and
>> phy_to_virt() function being provided by the Kernel.
>
> ioremap gives you a new mapping for I/O addresses that you can access
> with functions like in_be32 and the like.
>
> phy_to_virt() is rarely used at all, it only serves to convert a physical
> address for main memory (RAM) into the address used inside of the kernel.
>
> Arnd <><
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Difference-between-ioremap%28%29-and-phy_to_virt%28%29-Kernel-function-tf4669833.html#a13357088
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] Allow sysfs_remove_group() to be called on non-added groups
From: Michael Ellerman @ 2007-10-23 4:18 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20071023032836.GC7486@kroah.com>
It would be nice to be able to do:
for_each_thing(thing) {
error = sysfs_create_group(&thing->kobj, attrs);
if (error) {
for_each_thing(thing)
sysfs_remove_group(&thing->kobj, attrs);
return error;
}
}
But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes
were never added.
As discussed here ...
http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html
.. we should just return in that case instead of BUG'ing.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
fs/sysfs/group.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index f318b73..a256775 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj,
if (grp->name) {
sd = sysfs_get_dirent(dir_sd, grp->name);
- BUG_ON(!sd);
+ if (!sd)
+ return;
} else
sd = sysfs_get(dir_sd);
--
1.5.1.3.g7a33b
^ permalink raw reply related
* Re: Problems with allyesconfig kernel build
From: Andrew Morton @ 2007-10-23 4:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, amodra
In-Reply-To: <20071023140231.12698d1c.sfr@canb.auug.org.au>
On Tue, 23 Oct 2007 14:02:31 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> This was first noted with the -mm tree, but has now migrated into Linus'
> tree.
Yeah, sorry, I didn't know what to do about that. I'm not even sure which
patch caused it.
> An allyesconfig build dies in the link stage like this:
>
> /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern
> /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x8160): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern
> /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x81c4): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern
> /usr/bin/ld: final link failed: Bad value
>
> We already compile with -mminimal-toc and adding
> -fno-optimize-sibling-call did not help.
>
> Intuiting the obvious, I changed all the _INIT_STATIC and _INIT_GLOBAL
> uses in head_64.S back to _STATIC and _GLOBAL (which just moves the code
> from .text.init.refok to .text). Now the linker segfaults instead. :-)
>
> /bin/sh: line 1: 5260 Segmentation fault ld -m elf64ppc -Bstatic --emit-relocs --build-id -o .tmp_vmlinux1 -T arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_64.o arch/powerpc/kernel/entry_64.o arch/powerpc/kernel/fpu.o init/built-in.o --start-group usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o arch/powerpc/platforms/built-in.o arch/powerpc/xmon/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o arch/powerpc/oprofile/built-in.o net/built-in.o --end-group
> make[1]: *** [.tmp_vmlinux1] Error 139
>
> $ ld --version
> GNU ld (GNU Binutils for Debian) 2.18
>
> I take this as an improvement :-)
>
> We link .text.init.refok immediately after .text, but with
> allyesconfig, .text ends up very large.
>
> The --emit-relocs is a product of something else I am working on. So I
> took that out and now get a whole lot more messages like:
>
> /usr/bin/ld: net/built-in.o(.fixup+0x4): sibling call optimization to `.text' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text' extern
> /usr/bin/ld: net/built-in.o(.fixup+0xc): sibling call optimization to `.text' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text' extern
>
> Anyone have any ideas?
I still don't know ;)
What did we do which caused all this to start happening?
^ permalink raw reply
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Michael Ellerman @ 2007-10-23 4:20 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, mcarlson, linuxppc-dev list, mchan, linux-pci,
David Miller
In-Reply-To: <20071022181336.GC4280@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]
On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote:
> On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote:
> >
> > On pseries there's a chance it will work for PCI error recovery, but if
> > so it's just lucky that firmware has left everything configured the same
> > way.
>
> ? The papr is quite clear that i is up to the OS to restore the msi
> state after an eeh error.
Perhaps. I see R1-7.3.10.5.1-10, which says we should restore the config
space after a reset operation, but after an isolate/unisolate we must
recall RTAS. I thought EEH was doing the isolate/unisolate, but if it's
just a reset then just blatting the config space back should work.
> > Yes I think so. That way we can properly reconfigure via the firmware
> > interface. The other option would be to design some new arch hook to do
> > resume, but just doing a disable/enable seems simpler to me.
>
> Err, If you read the code for suspend/resume, it never actually calls
> disable/enable (and thus doesn't go to the firmware); it calls
> restore_msi_state() function!
I know. That was a proposed solution, to explicitly call disable/enable
instead of restore_msi_state().
> If suspend/resume needs to call firmware to restore the state, then,
> at the moment, suspend/resume is broken. As I mentioned earlier,
> I presumed that no powerpc laptops currently use msi-enabled devices,
> as otherwise, this would have been flushed out.
On _pseries_ suspend/resume with MSI is broken. The other powerpc
platforms that implement MSI should be fine, although I don't think
anyone's tested them, because they're not laptops and so suspend/resume
is not that interesting.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-10-23 4:21 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a commit that adds Vitaly Bordug as a maintainer for the
powerpc embedded 8xx processors. This is something that Marcelo asked
me to push ages ago, but it kept falling through the cracks.
Thanks,
Paul.
MAINTAINERS | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Marcelo Tosatti (1):
[POWERPC] Add Vitaly Bordug as PPC8xx maintainer
^ permalink raw reply
* [PATCH] Read back MSI message in rtas_setup_msi_irqs() so restore works
From: Michael Ellerman @ 2007-10-23 4:23 UTC (permalink / raw)
To: Paul Mackerras
Cc: netdev, mcarlson, linuxppc-dev, mchan, linux-pci, David S. Miller
There are plans afoot to use pci_restore_msi_state() to restore MSI
state after a device reset. In order for this to work for the RTAS MSI
backend, we need to read back the MSI message from config space after
it has been setup by firmware.
This should be sufficient for restoring the MSI state after a device
reset, however we will need to revisit this for suspend to disk if that
is ever implemented on pseries.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
Linas, can you test this on your setup with your EEH stuff? I haven't got
any MSI supporting hardware/firmware combination.
arch/powerpc/platforms/pseries/msi.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c
index 2793a1b..f15222b 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -171,6 +171,7 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
struct pci_dn *pdn;
int hwirq, virq, i, rc;
struct msi_desc *entry;
+ struct msi_msg msg;
pdn = get_pdn(pdev);
if (!pdn)
@@ -213,6 +214,11 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
dev_dbg(&pdev->dev, "rtas_msi: allocated virq %d\n", virq);
set_irq_msi(virq, entry);
+
+ /* Read config space back so we can restore after reset */
+ read_msi_msg(virq, &msg);
+ entry->msg = msg;
+
unmask_msi_irq(virq);
}
--
1.5.1.3.g7a33b
^ permalink raw reply related
* IB/ehca: Fix sg_page() fallout
From: Olof Johansson @ 2007-10-23 4:31 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev, Joachim Fenkes, torvalds, linux-kernel
In-Reply-To: <20071023040948.GA19699@lixom.net>
More fallout from sg_page changes, found with powerpc allyesconfig:
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page'
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page'
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page'
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index da88738..a3037f3 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -1776,7 +1776,7 @@ static int ehca_set_pagebuf_user1(struct ehca_mr_pginfo *pginfo,
list_for_each_entry_continue(
chunk, (&(pginfo->u.usr.region->chunk_list)), list) {
for (i = pginfo->u.usr.next_nmap; i < chunk->nmap; ) {
- pgaddr = page_to_pfn(chunk->page_list[i].page)
+ pgaddr = page_to_pfn(sg_page(chunk->page_list[i]))
<< PAGE_SHIFT ;
*kpage = phys_to_abs(pgaddr +
(pginfo->next_hwpage *
@@ -1832,7 +1832,7 @@ static int ehca_check_kpages_per_ate(struct scatterlist *page_list,
{
int t;
for (t = start_idx; t <= end_idx; t++) {
- u64 pgaddr = page_to_pfn(page_list[t].page) << PAGE_SHIFT;
+ u64 pgaddr = page_to_pfn(sg_page(page_list[t])) << PAGE_SHIFT;
ehca_gen_dbg("chunk_page=%lx value=%016lx", pgaddr,
*(u64 *)abs_to_virt(phys_to_abs(pgaddr)));
if (pgaddr - PAGE_SIZE != *prev_pgaddr) {
@@ -1867,7 +1867,7 @@ static int ehca_set_pagebuf_user2(struct ehca_mr_pginfo *pginfo,
chunk, (&(pginfo->u.usr.region->chunk_list)), list) {
for (i = pginfo->u.usr.next_nmap; i < chunk->nmap; ) {
if (nr_kpages == kpages_per_hwpage) {
- pgaddr = ( page_to_pfn(chunk->page_list[i].page)
+ pgaddr = ( page_to_pfn(sg_page(chunk->page_list[i]))
<< PAGE_SHIFT );
*kpage = phys_to_abs(pgaddr);
if ( !(*kpage) ) {
^ permalink raw reply related
* [PATCH 1/4] bootwrapper: Allow wrapper script to execute verbosely
From: Grant Likely @ 2007-10-23 4:27 UTC (permalink / raw)
To: paulus, linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20071023042353.30309.93118.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Allow wrapper script to print verbose progress when the V is set in the
environment.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/boot/wrapper | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 39b27e5..347639c 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -21,6 +21,11 @@
# (default ./arch/powerpc/boot)
# -W dir specify working directory for temporary files (default .)
+# Allow for verbose output
+if [ "$V" = 1 ]; then
+ set -x
+fi
+
# defaults
kernel=
ofile=zImage
^ permalink raw reply related
* [PATCH 3/4] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-23 4:27 UTC (permalink / raw)
To: paulus, linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20071023042353.30309.93118.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
Documentation/powerpc/booting-without-of.txt | 261 ++++++++++++++++++++++++++
1 files changed, 261 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index a96e853..59df69d 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -52,6 +52,7 @@ Table of Contents
i) Freescale QUICC Engine module (QE)
j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
+ l) Xilinx IP cores
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2242,6 +2243,266 @@ platforms are moved over to use the flattened-device-tree model.
available.
For Axon: 0x0000012a
+ l) Xilinx IP cores
+
+ The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
+ in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
+ of standard device types (network, serial, etc.) and miscellanious
+ devices (gpio, LCD, spi, etc). Also, since these devices are
+ implemented within the fpga fabric every instance of the device can be
+ synthesised with different options that change the behaviour.
+
+ Each IP-core has a set of parameters which the FPGA designer can use to
+ control how the core is synthesized. Historically, the EDK tool would
+ extract the device parameters relevant to device drivers and copy them
+ into an 'xparameters.h' in the form of #define symbols. This tells the
+ device drivers how the IP cores are configured, but it requres the kernel
+ to be recompiled every time the FPGA bitstream is resynthesized.
+
+ The new approach is to export the parameters into the device tree and
+ generate a new device tree each time the FPGA bitstream changes. The
+ parameters which used to be exported as #defines will now become
+ properties of the device node. In general, device nodes for IP-cores
+ will take the following form:
+
+ (name)@(base-address) {
+ compatible = "xlnx,(ip-core-name)-(HW_VER)"
+ [, (list of compatible devices), ...];
+ reg = <(baseaddr) (size)>;
+ interrupt-parent = <&interrupt-controller-phandle>;
+ interrupts = < ... >;
+ xlnx,(parameter1) = "(string-value)";
+ xlnx,(parameter2) = <(int-value)>;
+ };
+
+ (ip-core-name): the name of the ip block (given after the BEGIN
+ directive in system.mhs). Should be in lowercase
+ and all underscores '_' converted to dashes '-'.
+ (name): is derived from the "PARAMETER INSTANCE" value.
+ (parameter#): C_* parameters from system.mhs. The C_ prefix is
+ dropped from the parameter name, the name is converted
+ to lowercase and all underscore '_' characters are
+ converted to dashes '-'.
+ (baseaddr): the C_BASEADDR parameter.
+ (HW_VER): from the HW_VER parameter.
+ (size): equals C_HIGHADDR - C_BASEADDR + 1
+
+ Typically, the compatible list will include the exact IP core version
+ followed by an older IP core version which implements the same
+ interface or any other device with the same interface.
+
+ 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
+
+ For example, the following block from system.mhs:
+
+ BEGIN opb_uartlite
+ PARAMETER INSTANCE = opb_uartlite_0
+ PARAMETER HW_VER = 1.00.b
+ PARAMETER C_BAUDRATE = 115200
+ PARAMETER C_DATA_BITS = 8
+ PARAMETER C_ODD_PARITY = 0
+ PARAMETER C_USE_PARITY = 0
+ PARAMETER C_CLK_FREQ = 50000000
+ PARAMETER C_BASEADDR = 0xEC100000
+ PARAMETER C_HIGHADDR = 0xEC10FFFF
+ BUS_INTERFACE SOPB = opb_7
+ PORT OPB_Clk = CLK_50MHz
+ PORT Interrupt = opb_uartlite_0_Interrupt
+ PORT RX = opb_uartlite_0_RX
+ PORT TX = opb_uartlite_0_TX
+ PORT OPB_Rst = sys_bus_reset_0
+ END
+
+ becomes the following device tree node:
+
+ opb-uartlite-0@ec100000 {
+ device_type = "serial";
+ compatible = "xlnx,opb-uartlite-1.00.b";
+ reg = <ec100000 10000>;
+ interrupt-parent = <&opb-intc>;
+ interrupts = <1 0>; // got this from the opb_intc parameters
+ current-speed = <d#115200>; // standard serial device prop
+ clock-frequency = <d#50000000>; // standard serial device prop
+ xlnx,data-bits = <8>;
+ xlnx,odd-parity = <0>;
+ xlnx,use-parity = <0>;
+ };
+
+ Some IP cores actually implement 2 or more logical devices. In this case,
+ the device should still describe the whole IP core with a single node
+ and add a child node for each logical device. The ranges property can
+ be used to translate from parent IP-core to the registers of each device.
+ (Note: this makes the assumption that both logical devices have the same
+ bus binding. If this is not true, then separate nodes should be used for
+ each logical device). The 'cell-index' property can be used to enumerate
+ logical devices within an IP core. For example, the following is the
+ system.mhs entry for the dual ps2 controller found on the ml403 reference
+ design.
+
+ BEGIN opb_ps2_dual_ref
+ PARAMETER INSTANCE = opb_ps2_dual_ref_0
+ PARAMETER HW_VER = 1.00.a
+ PARAMETER C_BASEADDR = 0xA9000000
+ PARAMETER C_HIGHADDR = 0xA9001FFF
+ BUS_INTERFACE SOPB = opb_v20_0
+ PORT Sys_Intr1 = ps2_1_intr
+ PORT Sys_Intr2 = ps2_2_intr
+ PORT Clkin1 = ps2_clk_rx_1
+ PORT Clkin2 = ps2_clk_rx_2
+ PORT Clkpd1 = ps2_clk_tx_1
+ PORT Clkpd2 = ps2_clk_tx_2
+ PORT Rx1 = ps2_d_rx_1
+ PORT Rx2 = ps2_d_rx_2
+ PORT Txpd1 = ps2_d_tx_1
+ PORT Txpd2 = ps2_d_tx_2
+ END
+
+ It would result in the following device tree nodes:
+
+ opb_ps2_dual_ref_0@a9000000 {
+ ranges = <0 a9000000 2000>;
+ // If this device had extra parameters, then they would
+ // go here.
+ ps2@0 {
+ compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
+ reg = <0 40>;
+ interrupt-parent = <&opb-intc>;
+ interrupts = <3 0>;
+ cell-index = <0>;
+ };
+ ps2@1000 {
+ compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
+ reg = <1000 40>;
+ interrupt-parent = <&opb-intc>;
+ interrupts = <3 0>;
+ cell-index = <0>;
+ };
+ };
+
+ Also, the system.mhs file defines bus attachments from the processor
+ to the devices. The device tree structure should reflect the bus
+ attachments. Again an example; this system.mhs fragment:
+
+ BEGIN ppc405_virtex4
+ PARAMETER INSTANCE = ppc405_0
+ PARAMETER HW_VER = 1.01.a
+ BUS_INTERFACE DPLB = plb_v34_0
+ BUS_INTERFACE IPLB = plb_v34_0
+ END
+
+ BEGIN opb_intc
+ PARAMETER INSTANCE = opb_intc_0
+ PARAMETER HW_VER = 1.00.c
+ PARAMETER C_BASEADDR = 0xD1000FC0
+ PARAMETER C_HIGHADDR = 0xD1000FDF
+ BUS_INTERFACE SOPB = opb_v20_0
+ END
+
+ BEGIN opb_uart16550
+ PARAMETER INSTANCE = opb_uart16550_0
+ PARAMETER HW_VER = 1.00.d
+ PARAMETER C_BASEADDR = 0xa0000000
+ PARAMETER C_HIGHADDR = 0xa0001FFF
+ BUS_INTERFACE SOPB = opb_v20_0
+ END
+
+ BEGIN plb_v34
+ PARAMETER INSTANCE = plb_v34_0
+ PARAMETER HW_VER = 1.02.a
+ END
+
+ BEGIN plb_bram_if_cntlr
+ PARAMETER INSTANCE = plb_bram_if_cntlr_0
+ PARAMETER HW_VER = 1.00.b
+ PARAMETER C_BASEADDR = 0xFFFF0000
+ PARAMETER C_HIGHADDR = 0xFFFFFFFF
+ BUS_INTERFACE SPLB = plb_v34_0
+ END
+
+ BEGIN plb2opb_bridge
+ PARAMETER INSTANCE = plb2opb_bridge_0
+ PARAMETER HW_VER = 1.01.a
+ PARAMETER C_RNG0_BASEADDR = 0x20000000
+ PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
+ PARAMETER C_RNG1_BASEADDR = 0x60000000
+ PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
+ PARAMETER C_RNG2_BASEADDR = 0x80000000
+ PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
+ PARAMETER C_RNG3_BASEADDR = 0xC0000000
+ PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
+ BUS_INTERFACE SPLB = plb_v34_0
+ BUS_INTERFACE MOPB = opb_v20_0
+ END
+
+ Gives this device tree (some properties removed for clarity):
+
+ plb-v34-0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "ibm,plb";
+ ranges; // 1:1 translation
+
+ plb-bram-if-cntrl-0@ffff0000 {
+ reg = <ffff0000 10000>;
+ }
+
+ opb-v20-0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <20000000 20000000 20000000
+ 60000000 60000000 20000000
+ 80000000 80000000 40000000
+ c0000000 c0000000 20000000>;
+
+ opb-uart16550-0@a0000000 {
+ reg = <a00000000 2000>;
+ };
+
+ opb-intc-0@d1000fc0 {
+ reg = <d1000fc0 20>;
+ };
+ };
+ };
+
+ That covers the general approach to binding xilinx IP cores into the
+ device tree. The following are bindings for specific devices:
+
+ i) Xilinx ML300 Framebuffer
+
+ Simple framebuffer device from the ML300 reference design (also on the
+ ML403 reference design as well as others).
+
+ Optional properties:
+ - resolution = <xres yres> : pixel resolution of framebuffer. Some
+ implementations use a different resolution.
+ Default is <d#640 d#480>
+ - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
+ Default is <d#1024 d#480>.
+ - rotate-display (empty) : rotate display 180 degrees.
+
+ ii) Xilinx SystemACE
+
+ The Xilinx SystemACE device is used to program FPGAs from an FPGA
+ bitstream stored on a CF card. It can also be used as a generic CF
+ interface device.
+
+ Optional properties:
+ - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
+
+ iii) Xilinx EMAC and Xilinx TEMAC
+
+ Xilinx Ethernet devices. In addition to general xilinx properties
+ listed above, nodes for these devices should include a phy-handle
+ property, and may include other common network device properties
+ like local-mac-address.
+
+ iv) Xilinx Uartlite
+
+ Xilinx uartlite devices are simple fixed speed serial ports.
+
+ Requred properties:
+ - current-speed : Baud rate of uartlite
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
^ permalink raw reply related
* [PATCH 2/4] bootwrapper: Bail from script if any command fails
From: Grant Likely @ 2007-10-23 4:27 UTC (permalink / raw)
To: paulus, linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20071023042353.30309.93118.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Add the 'set -e' command to the wrapper script so that if any command
fails then the script will automatically exit
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/boot/wrapper | 27 ++++++++++-----------------
1 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 347639c..5ae48f4 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -21,6 +21,9 @@
# (default ./arch/powerpc/boot)
# -W dir specify working directory for temporary files (default .)
+# Stop execution if any command fails
+set -e
+
# Allow for verbose output
if [ "$V" = 1 ]; then
set -x
@@ -116,7 +119,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
+ dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts"
fi
if [ -z "$kernel" ]; then
@@ -287,23 +290,13 @@ ps3)
rm -f "$object/otheros.bld"
- msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
- skip=$overlay_dest seek=$system_reset_kernel \
- count=$overlay_size bs=1 2>&1)
-
- if [ $? -ne "0" ]; then
- echo $msg
- exit 1
- fi
+ dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$overlay_dest seek=$system_reset_kernel \
+ count=$overlay_size bs=1
- msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
- skip=$system_reset_overlay seek=$overlay_dest \
- count=$overlay_size bs=1 2>&1)
-
- if [ $? -ne "0" ]; then
- echo $msg
- exit 2
- fi
+ dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$system_reset_overlay seek=$overlay_dest \
+ count=$overlay_size bs=1
gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
;;
^ permalink raw reply related
* [PATCH 0/4] Misc patches for the 2.6.24 merge window
From: Grant Likely @ 2007-10-23 4:27 UTC (permalink / raw)
To: paulus, linuxppc-dev; +Cc: David Gibson
Paulus,
Here is the last set of patches that I'd like to get in before Linus
slams the merge window shut. They're pretty minor changes. The wrapper
patches make it easier to debug and catch errors and David has already
okayed them. There's a speedup on the uartlite driver, and then a chunk
of documentation for the Xilinx device tree bindings.
Josh, can you please ack or nack the documentation change?
Peter, any issues with the uartlite change?
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 4/4] Uartlite: speed up console output
From: Grant Likely @ 2007-10-23 4:27 UTC (permalink / raw)
To: paulus, linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20071023042353.30309.93118.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Change the wait_tx routine to call cpu_relax() instead of udelay() to
reduce console output latency and test for the TXFULL bit instead of
TXEMPTY. That way the FIFO doesn't need to by 100% flushed before
writing the next character.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/serial/uartlite.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index dfef83f..a85f2d3 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -329,12 +329,14 @@ static struct uart_ops ulite_ops = {
static void ulite_console_wait_tx(struct uart_port *port)
{
int i;
+ u8 val;
- /* wait up to 10ms for the character(s) to be sent */
- for (i = 0; i < 10000; i++) {
- if (readb(port->membase + ULITE_STATUS) & ULITE_STATUS_TXEMPTY)
+ /* Spin waiting for TX fifo to have space available */
+ for (i = 0; i < 100000; i++) {
+ val = readb(port->membase + ULITE_STATUS);
+ if ((val & ULITE_STATUS_TXFULL) == 0)
break;
- udelay(1);
+ cpu_relax();
}
}
^ permalink raw reply related
* Re: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
From: David Gibson @ 2007-10-23 4:34 UTC (permalink / raw)
To: Michal Simek
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger,
Arnd Bergmann, Leonid
In-Reply-To: <1837.2996-6584-798350907-1193112476@seznam.cz>
On Tue, Oct 23, 2007 at 06:07:56AM +0200, Michal Simek wrote:
> >> In my opinion will be better generate only parameters which
> >> you want not all.
> >> That smells with unusable parameters.
> >
> >In the long term, this may be true. In the short term:
> >1) dtb size is not the key problem
> Yes of course
> >2) making sure that everything works is a key problem.
> >3) The code that generates the dts should be as simple as possible,
> >so that we can easily document what it does.
> Yes but you must document every parameter which your generate do. The better way is
> document only parameters which you want use.
>
> >In the long term, I'm all for optimizing the device tree that gets
> >built,
> >assuming that it appears to be a problem in real systems.
> We can optimize now. I made new version of my generator u-boot_v3_00_a (monstr.eu)
> where you can simply add parameter which you want to use.
>
> If you want use any parameter add it.
> For microblaze cpu - line 1184.
> And for others peripherals lines 926-980. (The last parameter of function call).
>
> Which parameters do you want for PPC405, Grant?
>
> Regards,
> Michal Simek
>
> This is example of generator.
>
> / {
> model = "mONStR";
> chosen {
> linux,platform = <600>;
linux,platform is long obsolete. Kill it.
> bootargs = "root=/dev/xsysace/disc0/part2";
> } ;
> cpus {
> #size-cells = <0>;
> #cpus = < 0 >;
> #address-cells = <1>;
> microblaze_0,5.00.c {
Still missing an @0 here.
> 32-bit;
> linux,boot-cpu;
32-bit and linux,boot-cpu are both obsolete (the first was never
specified anywhere) and should be removed.
> device_type = "cpu";
> reg = <0>;
> clock-frequency = <5f5e1000>;
> timebase-frequency = <1FCA055>;
> i-cache-line-size = <2000>;
> i-cache-size = <10>;
> d-cache-line-size = <2000>;
> d-cache-size = <10>;
> xilinx,pvr = <0>;
> xilinx,debug-enabled = <1>;
> xilinx,fsl-links = <0>;
> } ;
> } ;
>
> opb_mdm@41400000 {
> compatible = "opb_mdm_2.00.a\0opb_mdm";
Please use the new "opb_mdm_2.00.a", "opb_mdm" syntax.
> name = "debug_module";
Don't create properties called 'name'. In real OF the 'name' property
is a synonym for the node name without the @address part. Although
it's possible to encode a name property in a flattened tree with a
different value, it's a bad idea since it will clash with the OF
notion of this property. In Linux this will cause a collision when
the tree is unflattened.
We should probably fix dtc to reject this, in fact.
> reg = < 41400000 10000 >;
> device_type = "opb_mdm";
Get rid of all your device_type values, they're all bogus. The only
devices which should have device_type at all are the ethernets and
maybe the uarts, and in these cases the values should be "network" and
"serial" respectively.
> xilinx,mb-dbg-ports = <1>;
> xilinx,uart-width = <8>;
> xilinx,use-uart = <1>;
> } ;
> opb_uartlite@40600000 {
> compatible = "opb_uartlite_1.00.b\0opb_uartlite";
> name = "RS232_Uart_1";
> interrupts = < 4 0 >;
> reg = < 40600000 10000 >;
> device_type = "opb_uartlite";
> xilinx,baudrate = <2580>;
> xilinx,data-bits = <8>;
> xilinx,clk-freq = <5f5e100>;
> xilinx,odd-parity = <0>;
> xilinx,use-parity = <0>;
> } ;
> opb_ethernet@40c00000 {
The generic names convention means this should be called
"ethernet@40c00000"
> compatible = "opb_ethernet_1.04.a\0opb_ethernet";
> name = "Ethernet_MAC";
> interrupts = < 3 0 >;
> reg = < 40c00000 10000 >;
> device_type = "opb_ethernet";
> xilinx,cam-exist = <0>;
> xilinx,dev-blk-id = <1>;
> xilinx,dev-mir-enable = <1>;
> xilinx,dma-present = <1>;
> xilinx,include-dev-pencoder = <1>;
> xilinx,ipif-rdfifo-depth = <8000>;
> xilinx,ipif-wrfifo-depth = <8000>;
> xilinx,mii-exist = <1>;
> } ;
> opb_sysace@41820000 {
> compatible = "opb_sysace_1.00.c\0opb_sysace";
> name = "SysACE_CompactFlash";
> reg = < 41820000 10000 >;
> device_type = "opb_sysace";
> xilinx,mem-width = <10>;
> } ;
> opb_gpio@40000000 {
> compatible = "opb_gpio_3.01.b\0opb_gpio";
> name = "LEDs_4Bit";
> reg = < 40000000 10000 >;
> device_type = "opb_gpio";
> xilinx,gpio-width = <4>;
> xilinx,is-dual = <0>;
> } ;
> memory@30000000 {
> edk_name = "DDR_256MB_32MX64_rank1_row13_col10_cl2_5";
> compatible = "opb_ddr";
The memory node shouldn't generally need a compatible property. Note
that the RAM itself probably needs to be separate from the RAM
controller node, if such a thing exists.
> memreg:reg = < 30000000 10000000 >;
> device_type = "memory";
> } ;
> opb_ps2_dual_ref@7a400000 {
> compatible = "opb_ps2_dual_ref_1.00.a\0opb_ps2_dual_ref";
> name = "PS2_Ports";
> interrupts = < 2 0 >;
> interrupts = < 1 0 >;
> reg = < 7a400000 10000 >;
> device_type = "opb_ps2_dual_ref";
> } ;
> opb_timer@41c00000 {
> compatible = "opb_timer_1.00.b\0opb_timer";
> name = "opb_timer_1";
> interrupts = < 0 0 >;
> reg = < 41c00000 10000 >;
> device_type = "opb_timer";
> xilinx,count-width = <20>;
> xilinx,one-timer-only = <0>;
> } ;
> opb_intc@41200000 {
> compatible = "opb_intc_1.00.c\0opb_intc";
> name = "opb_intc_0";
> reg = < 41200000 10000 >;
> device_type = "opb_intc";
> } ;
> opb_uart16550@40400000 {
Should be named "serial@..."
> compatible = "opb_uart16550_1.00.d\0opb_uart16550";
> name = "opb_uart16550_0";
> reg = < 40400000 10000 >;
> device_type = "opb_uart16550";
> } ;
> opb_sysace@41800000 {
> compatible = "opb_sysace_1.00.c\0opb_sysace";
> name = "opb_sysace_0";
> reg = < 41800000 10000 >;
> device_type = "opb_sysace";
> xilinx,mem-width = <10>;
> } ;
> } ;
--
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: Problems with allyesconfig kernel build
From: Stephen Rothwell @ 2007-10-23 4:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: ppc-dev, amodra
In-Reply-To: <20071022211836.45a87a12.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On Mon, 22 Oct 2007 21:18:36 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 23 Oct 2007 14:02:31 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > This was first noted with the -mm tree, but has now migrated into Linus'
> > tree.
>
> Yeah, sorry, I didn't know what to do about that. I'm not even sure which
> patch caused it.
Not your fault.
> What did we do which caused all this to start happening?
We just grew too big, probably :-(
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: IB/ehca: Fix sg_page() fallout
From: Jens Axboe @ 2007-10-23 5:05 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Joachim Fenkes, torvalds, linux-kernel
In-Reply-To: <20071023043148.GA20904@lixom.net>
On Mon, Oct 22 2007, Olof Johansson wrote:
> More fallout from sg_page changes, found with powerpc allyesconfig:
>
> drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page'
> drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page'
> drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page'
Thanks a lot Olof, applied both fixups!
--
Jens Axboe
^ permalink raw reply
* Re: IB/ehca: Fix sg_page() fallout
From: Olof Johansson @ 2007-10-23 5:54 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev, Joachim Fenkes, torvalds, linux-kernel
In-Reply-To: <20071023050512.GK16425@kernel.dk>
More fallout from sg_page changes:
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page'
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page'
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page'
Signed-off-by: Olof Johansson <olof@lixom.net>
---
On Tue, Oct 23, 2007 at 07:05:12AM +0200, Jens Axboe wrote:
> On Mon, Oct 22 2007, Olof Johansson wrote:
> > More fallout from sg_page changes, found with powerpc allyesconfig:
> >
> > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
> > drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page'
> > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate':
> > drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page'
> > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
> > drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page'
>
> Thanks a lot Olof, applied both fixups!
I messed up the second fix. :( please replace with this.
-Olof
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index da88738..ead7230 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -1776,7 +1776,7 @@ static int ehca_set_pagebuf_user1(struct ehca_mr_pginfo *pginfo,
list_for_each_entry_continue(
chunk, (&(pginfo->u.usr.region->chunk_list)), list) {
for (i = pginfo->u.usr.next_nmap; i < chunk->nmap; ) {
- pgaddr = page_to_pfn(chunk->page_list[i].page)
+ pgaddr = page_to_pfn(sg_page(&chunk->page_list[i]))
<< PAGE_SHIFT ;
*kpage = phys_to_abs(pgaddr +
(pginfo->next_hwpage *
@@ -1832,7 +1832,7 @@ static int ehca_check_kpages_per_ate(struct scatterlist *page_list,
{
int t;
for (t = start_idx; t <= end_idx; t++) {
- u64 pgaddr = page_to_pfn(page_list[t].page) << PAGE_SHIFT;
+ u64 pgaddr = page_to_pfn(sg_page(&page_list[t])) << PAGE_SHIFT;
ehca_gen_dbg("chunk_page=%lx value=%016lx", pgaddr,
*(u64 *)abs_to_virt(phys_to_abs(pgaddr)));
if (pgaddr - PAGE_SIZE != *prev_pgaddr) {
@@ -1867,7 +1867,7 @@ static int ehca_set_pagebuf_user2(struct ehca_mr_pginfo *pginfo,
chunk, (&(pginfo->u.usr.region->chunk_list)), list) {
for (i = pginfo->u.usr.next_nmap; i < chunk->nmap; ) {
if (nr_kpages == kpages_per_hwpage) {
- pgaddr = ( page_to_pfn(chunk->page_list[i].page)
+ pgaddr = ( page_to_pfn(sg_page(&chunk->page_list[i]))
<< PAGE_SHIFT );
*kpage = phys_to_abs(pgaddr);
if ( !(*kpage) ) {
^ permalink raw reply related
* Re: [PATCH] Bugfix to commit 4f9a58d75bfe82ab2b8ba5b8506dfb190a267834
From: Olaf Hering @ 2007-10-23 6:37 UTC (permalink / raw)
To: Grant Likely; +Cc: Paul Mackerras, Linus Torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <20071022223737.21679.23812.stgit@trillian.cg.shawcable.net>
On Mon, Oct 22, Grant Likely wrote:
> Olaf, do I have the correct solution here?
Sure.
^ permalink raw reply
* Re: IB/ehca: Fix sg_page() fallout
From: Jens Axboe @ 2007-10-23 7:12 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Joachim Fenkes, torvalds, linux-kernel
In-Reply-To: <20071023055439.GA22426@lixom.net>
On Tue, Oct 23 2007, Olof Johansson wrote:
>
> More fallout from sg_page changes:
>
> drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page'
> drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page'
> drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page'
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
>
> ---
>
> On Tue, Oct 23, 2007 at 07:05:12AM +0200, Jens Axboe wrote:
> > On Mon, Oct 22 2007, Olof Johansson wrote:
> > > More fallout from sg_page changes, found with powerpc allyesconfig:
> > >
> > > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
> > > drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page'
> > > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate':
> > > drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page'
> > > drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
> > > drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page'
> >
> > Thanks a lot Olof, applied both fixups!
>
> I messed up the second fix. :( please replace with this.
No problem, applied.
--
Jens Axboe
^ permalink raw reply
* Re: powerpc: Fix fallout from sg_page() changes
From: Jens Axboe @ 2007-10-23 7:13 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, mingo, torvalds, linux-kernel
In-Reply-To: <20071023040948.GA19699@lixom.net>
On Mon, Oct 22 2007, Olof Johansson wrote:
> Fix fallout from 18dabf473e15850c0dbc8ff13ac1e2806d542c15:
>
> In file included from include/linux/dma-mapping.h:52,
> from drivers/base/dma-mapping.c:10:
> include/asm/dma-mapping.h: In function 'dma_map_sg':
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:289: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:290: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h: In function 'dma_sync_sg_for_cpu':
> include/asm/dma-mapping.h:331: error: 'struct scatterlist' has no member named 'page'
>
> drivers/scsi/ps3rom.c: In function 'fetch_to_dev_buffer':
> drivers/scsi/ps3rom.c:150: error: 'struct scatterlist' has no member named 'page'
Applied.
--
Jens Axboe
^ 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