* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 19:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801211135r5cde9f6t9b6ee323a48bc44c@mail.gmail.com>
On 1/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/21/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
> >
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > ---
> > >
> > > arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> > > arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> > > arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> > > arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> > > arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> > > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> > > arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
> >
> > I believe I got the 83xx and 85xx already. look at my tree.
>
> Okay, I can drop those and repost.
Actually, that's too much work... I'll wait until paulus pulls your
tree, rebase and then repost.
/me is lazy.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 19:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6FA7C7C0-172D-4AD4-BDAF-A1E3845A63FE@kernel.crashing.org>
On 1/21/08, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
>
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> > arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> > arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> > arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> > arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> > arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
>
> I believe I got the 83xx and 85xx already. look at my tree.
Okay, I can drop those and repost.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Kumar Gala @ 2008-01-21 19:27 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080121185812.13486.68032.stgit@trillian.secretlab.ca>
On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
I believe I got the 83xx and 85xx already. look at my tree.
- k
^ permalink raw reply
* fixed phy support (warning related to FIXED_MII_100_FDX)
From: Kumar Gala @ 2008-01-21 19:19 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev list
Anton,
it looks like the "TI AR7 CPMAC Ethernet support" uses FIXED_PHY and
was selecting FIXED_MII_100_FDX which is gone.
Can you look into this. I get the following warning now:
scripts/kconfig/conf -s arch/powerpc/Kconfig
drivers/net/Kconfig:1713:warning: 'select' used by config symbol
'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
- k
^ permalink raw reply
* [PATCH 1/2] [POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 18:58 UTC (permalink / raw)
To: galak, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/8xx/ep88xc.c | 5 ++---
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 5 ++---
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 5 ++---
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/ep88xc.c b/arch/powerpc/platforms/8xx/ep88xc.c
index c518b6c..88afa35 100644
--- a/arch/powerpc/platforms/8xx/ep88xc.c
+++ b/arch/powerpc/platforms/8xx/ep88xc.c
@@ -155,12 +155,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
/* Publish the QE devices */
- if (machine_is(ep88xc))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(ep88xc, declare_of_platform_devices);
define_machine(ep88xc) {
.name = "Embedded Planet EP88xC",
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index d2927a4..d7965f8 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -128,12 +128,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (machine_is(mpc86x_ads))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc86x_ads, declare_of_platform_devices);
define_machine(mpc86x_ads) {
.name = "MPC86x ADS",
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 2cf1b6a..6ef8e9e 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -264,12 +264,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
/* Publish the QE devices */
- if (machine_is(mpc885_ads))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc885_ads, declare_of_platform_devices);
define_machine(mpc885_ads) {
.name = "Freescale MPC885 ADS",
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 18:58 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20080121185806.13486.56429.stgit@trillian.secretlab.ca>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
11 files changed, 12 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c b/arch/powerpc/platforms/82xx/mpc8272_ads.c
index fd83440..3fce6b3 100644
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -165,14 +165,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(mpc8272_ads))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc8272_ads, declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/82xx/pq2fads.c b/arch/powerpc/platforms/82xx/pq2fads.c
index 1be5005..68196e3 100644
--- a/arch/powerpc/platforms/82xx/pq2fads.c
+++ b/arch/powerpc/platforms/82xx/pq2fads.c
@@ -176,14 +176,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(pq2fads))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(pq2fads, declare_of_platform_devices);
define_machine(pq2fads)
{
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 1e570bb..dbdd4ad 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -110,15 +110,12 @@ static struct of_device_id mpc832x_ids[] = {
static int __init mpc832x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc832x_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc832x_ids, NULL);
return 0;
}
-device_initcall(mpc832x_declare_of_platform_devices);
+machine_device_initcall(mpc832x_mds, mpc832x_declare_of_platform_devices);
static void __init mpc832x_sys_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index ffb2e93..1b57028 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -63,9 +63,6 @@ static struct spi_board_info mpc832x_spi_boardinfo = {
static int __init mpc832x_spi_init(void)
{
- if (!machine_is(mpc832x_rdb))
- return 0;
-
par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
@@ -79,8 +76,7 @@ static int __init mpc832x_spi_init(void)
mpc83xx_spi_activate_cs,
mpc83xx_spi_deactivate_cs);
}
-
-device_initcall(mpc832x_spi_init);
+machine_device_initcall(mpc832x_rdb, mpc832x_spi_init);
/* ************************************************************************
*
@@ -123,15 +119,12 @@ static struct of_device_id mpc832x_ids[] = {
static int __init mpc832x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc832x_rdb))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc832x_ids, NULL);
return 0;
}
-device_initcall(mpc832x_declare_of_platform_devices);
+machine_device_initcall(mpc832x_rdb, mpc832x_declare_of_platform_devices);
void __init mpc832x_rdb_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 459fb72..2b8a0a3 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -115,13 +115,10 @@ static struct of_device_id mpc834x_ids[] = {
static int __init mpc834x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc834x_mds))
- return 0;
-
of_platform_bus_probe(NULL, mpc834x_ids, NULL);
return 0;
}
-device_initcall(mpc834x_declare_of_platform_devices);
+machine_device_initcall(mpc834x_mds, mpc834x_declare_of_platform_devices);
/*
* Called very early, MMU is off, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 2ac9890..db491ec 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -141,15 +141,12 @@ static struct of_device_id mpc836x_ids[] = {
static int __init mpc836x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc836x_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc836x_ids, NULL);
return 0;
}
-device_initcall(mpc836x_declare_of_platform_devices);
+machine_device_initcall(mpc836x_mds, mpc836x_declare_of_platform_devices);
static void __init mpc836x_mds_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index 9cdc32b..cfd0548 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -50,15 +50,12 @@ static struct of_device_id mpc837x_ids[] = {
static int __init mpc837x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc837x_mds))
- return 0;
-
/* Publish of_device */
of_platform_bus_probe(NULL, mpc837x_ids, NULL);
return 0;
}
-device_initcall(mpc837x_declare_of_platform_devices);
+machine_device_initcall(mpc837x_mds, mpc837x_declare_of_platform_devices);
static void __init mpc837x_mds_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index bccdc25..a3fa1b0 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -233,13 +233,10 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(mpc85xx_ads))
- return 0;
-
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc85xx_ads, declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 4d063ee..8b1de78 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -222,9 +222,6 @@ static int mpc85xx_cds_8259_attach(void)
struct device_node *cascade_node = NULL;
int cascade_irq;
- if (!machine_is(mpc85xx_cds))
- return 0;
-
/* Initialize the i8259 controller */
for_each_node_by_type(np, "interrupt-controller")
if (of_device_is_compatible(np, "chrp,iic")) {
@@ -262,8 +259,7 @@ static int mpc85xx_cds_8259_attach(void)
return 0;
}
-
-device_initcall(mpc85xx_cds_8259_attach);
+machine_device_initcall(mpc85xx_cds, mpc85xx_cds_8259_attach);
#endif /* CONFIG_PPC_I8259 */
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index e6c63a5..9f4f3aa 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -144,15 +144,12 @@ static struct of_device_id mpc85xx_ids[] = {
static int __init mpc85xx_publish_devices(void)
{
- if (!machine_is(mpc85xx_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL,mpc85xx_ids,NULL);
return 0;
}
-device_initcall(mpc85xx_publish_devices);
+machine_device_initcall(mpc85xx_mds, mpc85xx_publish_devices);
static void __init mpc85xx_mds_pic_init(void)
{
diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/powerpc/platforms/embedded6xx/ls_uart.c
index c99264c..9d891bd 100644
--- a/arch/powerpc/platforms/embedded6xx/ls_uart.c
+++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c
@@ -117,9 +117,6 @@ static int __init ls_uarts_init(void)
phys_addr_t phys_addr;
int len;
- if (!machine_is(linkstation))
- return 0;
-
avr = of_find_node_by_path("/soc10x/serial@80004500");
if (!avr)
return -EINVAL;
@@ -142,4 +139,4 @@ static int __init ls_uarts_init(void)
return 0;
}
-late_initcall(ls_uarts_init);
+machine_late_initcall(linkstation, ls_uarts_init);
^ permalink raw reply related
* Re: Patches added to master/for-2.6.25 branch of powerpc.git
From: Grant Likely @ 2008-01-21 18:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801172153v69d948e5hf01d963410123f38@mail.gmail.com>
On 1/17/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/17/08, Paul Mackerras <paulus@samba.org> wrote:
> > Grant Likely writes:
> >
> > > Paul, can you also please pull the following 52xx changes?
> >
> > Could you please re-do your tree and make sure the headline for each
> > commit starts with "[POWERPC]" (unless it isn't powerpc-specific, in
> > which case it probably shouldn't be in your tree...).
>
> Oops, I thought I had done that. Sorry, I'll get that respun ASAP.
Here you go; respun the 52xx patches as you requested. Please pull.
Also, can you please merge your 2.6.25 branch with Linus' top of tree?
There are some more patches which I'm withholding until then because
they'll cause nasty merge conflicts otherwise.
Thanks,
g.
The following changes since commit 52920df4aa9dd25836b8ed4dc0b177ea14c09e53:
Paul Mackerras (1):
Merge branch 'for-2.6.25' of
master.kernel.org:/.../olof/pasemi into for-2.6.25
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25
Grant Likely (2):
[POWERPC] mpc5200: eliminate mpc52xx_*_map_*() functions.
[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
John Rigby (2):
[POWERPC] Separate MPC52xx PSC FIFO registers from rest of PSC
[POWERPC] mpc5200: Cleanup checkpatch.pl problems in mpc52xx_uart.c
Marian Balakowicz (6):
[POWERPC] mpc5200: Add 'fsl,lpb' bus type for localplus bus
[POWERPC] mpc5200: Add common mpc52xx_setup_pci() routine
[POWERPC] mpc5200: Add TQM5200 DTS
[POWERPC] mpc5200: add CM5200 DTS
[POWERPC] mpc5200: Add Promess Motion-PRO DTS
[POWERPC] mpc5200: Add generic support for simple MPC5200 based boards
arch/powerpc/boot/dts/cm5200.dts | 236 +++++
arch/powerpc/boot/dts/lite5200.dts | 2 +-
arch/powerpc/boot/dts/lite5200b.dts | 2 +-
arch/powerpc/boot/dts/motionpro.dts | 309 ++++++
arch/powerpc/boot/dts/tqm5200.dts | 184 ++++
arch/powerpc/configs/lite5200_defconfig | 847 -----------------
arch/powerpc/configs/mpc5200_defconfig | 1286 ++++++++++++++++++++++++++
arch/powerpc/platforms/52xx/Kconfig | 27 +-
arch/powerpc/platforms/52xx/Makefile | 1 +
arch/powerpc/platforms/52xx/lite5200.c | 22 +-
arch/powerpc/platforms/52xx/lite5200_pm.c | 6 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 85 ++
arch/powerpc/platforms/52xx/mpc52xx_common.c | 63 +-
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 14 +
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 8 +-
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 8 +-
drivers/serial/mpc52xx_uart.c | 210 +++--
drivers/spi/mpc52xx_psc_spi.c | 9 +-
include/asm-powerpc/mpc52xx.h | 7 +-
include/asm-powerpc/mpc52xx_psc.h | 3 +
include/asm-ppc/mpc52xx_psc.h | 3 +
21 files changed, 2317 insertions(+), 1015 deletions(-)
create mode 100644 arch/powerpc/boot/dts/cm5200.dts
create mode 100644 arch/powerpc/boot/dts/motionpro.dts
create mode 100644 arch/powerpc/boot/dts/tqm5200.dts
delete mode 100644 arch/powerpc/configs/lite5200_defconfig
create mode 100644 arch/powerpc/configs/mpc5200_defconfig
create mode 100644 arch/powerpc/platforms/52xx/mpc5200_simple.c
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Generated xilinx linux 2.6 image sections
From: Stephen Neuendorffer @ 2008-01-21 18:45 UTC (permalink / raw)
To: greenlean, linuxppc-embedded
In-Reply-To: <14997109.post@talk.nabble.com>
The testapps are generated using a different linker script.
Based on what you sent out, it looks like your EDK design has a memory
at 0x10000000, but this is
not reflected in the linux image you've generated. This makes me
suspect that you haven't generated the BSP and copied the appropriate
xparameters file over xparameters_xup.h (assuming you are using
CONFIG_XILINX_XUPV2P).
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of greenlean
> Sent: Monday, January 21, 2008 5:06 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Generated xilinx linux 2.6 image sections
>=20
>=20
> Hi all,
>=20
> I'm trying to boot the 2.6 xilinx kernel downloaded from their git
server in
> the XUPV2P board I'm really having troubles (I can't see anything in
the
> minicom console terminal). I'm not seeing anything, neither the
ucompressing
> kernel string nor the prompt with the memory addresses that kernel
prompt at
> first time, so I have started to distrust of anything.
>=20
> When I download the kernel using xmd, I see:
>=20
> XMD% dow imagen_UART16550_ml300.elf
> section, .text: 0x00400000-0x0040387b
> section, .data: 0x00404000-0x004e6fff
> section, .bss: 0x004e7000-0x004e919f
> Downloaded Program imagen_UART16550_ml300.elf
> Setting PC with Program Start Address 0x00400000
>=20
> and when I download some of the TestApp generated by EDK I see:
>=20
> XMD% dow perif.elf
> section, .vectors: 0xfffe0000-0xfffe20c3
> section, .text: 0x10000000-0x10003b7b
> section, .init: 0x10003b7c-0x10003b9f
> section, .fini: 0x10003ba0-0x10003bbf
> section, .boot0: 0xfffe20c4-0xfffe20d3
> section, .boot: 0xfffffffc-0xffffffff
> section, .rodata: 0x10003bc0-0x10004111
> section, .sdata2: 0x10004114-0x10004113
> section, .sbss2: 0x10004114-0x10004113
> section, .data: 0x10004114-0x10004243
> section, .got: 0x10004244-0x10004243
> section, .got1: 0x10004244-0x10004243
> section, .got2: 0x10004244-0x1000425f
> section, .ctors: 0x10004260-0x10004267
> section, .dtors: 0x10004268-0x1000426f
> section, .fixup: 0x10004270-0x1000426f
> section, .eh_frame: 0x10004270-0x10004277
> section, .jcr: 0x10004278-0x1000427b
> section, .gcc_except_table: 0x1000427c-0x100042
> section, .sdata: 0x1000427c-0x10004293
> section, .sbss: 0x10004294-0x100042a3
> section, .bss: 0x100042a4-0x10004473
> section, .stack: 0x10004474-0x1000647f
> section, .heap: 0x10006480-0x1000847f
> Downloaded Program perif.elf
> Setting PC with Program Start Address 0xfffffffc
>=20
> Does anybody know why the kernel elf don't have a boot section like
the
> TestApp generated by EDK?
>=20
> I suppossed this is because the image kernel is compressed, but
despite
> beeing compressed it should have a boot section or something similar
???
> It's right that the kernel start address is set to the 0x00400000??
>=20
> Or does the section .text contains all the kernel code to uncompresse
the
> code of the kernel??
>=20
>=20
>=20
> --
> View this message in context:
http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-
> tp14997109p14997109.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] autodetect serial console on efika
From: Grant Likely @ 2008-01-21 18:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20080121152900.GA8664@aepfle.de>
On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
>
> Efika boards have to be booted with console=ttyPSC0 unless there is a
> graphics card plugged in. Detect if the firmware stdout is the serial
> connector.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
Hrrrum; I think this is a good idea, but I'm not thrilled with the
approach. Here are my concerns:
- Determining that linux,stdout-path points to a PSC should should be
done in common code. It's useful for all 5200 boards, not just the
Efika. (However, if 'failsafe' processing is efika specific, then it
can stay in efika.c). This might be best done within the PSC driver
itself, but I'm not sure.
- Recognizing a psc node should be done by inspecting the compatible
property, not by device_type and model properties.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Stephen Neuendorffer @ 2008-01-21 18:42 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, David Baird, linuxppc-embedded
In-Reply-To: <BAY115-W344A18C61627B3075C6281B23D0@phx.gbl>
Basically, git.xilinx.com has a tree with most of the xilinx-related
support already integrated and ported forward to a current kernel. It
also includes ongoing work to unify microblaze and powerpc device
drivers through flat device trees.
See:
http://www.mail-archive.com/linuxppc-embedded@ozlabs.org/msg28690.html
To use the git.xilinx.com tree you should *not* generate the driver code
directly into the Linux tree. Instead, you should generate the driver
code in a dummy directory and copy
arch/ppc/platforms/4xx/xparameters_ml*.h into the kernel tree.
The BSP generation process is designed older 2.6.10-era kernels and will
not work with recent kernels. =20
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Mohammad
Sadegh Sadri
> Sent: Monday, January 21, 2008 12:54 AM
> To: David Baird; linuxppc-embedded@ozlabs.org
> Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>=20
> thanks for you reply david,
>=20
> As far as I know the Linux driver for Xilinx PLB TEMAC was two parts :
1- adapter.c and 2- the rest
> of the driver files
>=20
> Only adapter.c was really a linux related file and the rest of the
files were Xilinx generic driver
> code for PLB TEMAC.
>=20
> correct?
>=20
> then now, I know EDK 9.2 generates the needed Linux support package
and needed related files, so if
> this is the case can we use these files as the needed driver in our
linux kernel?
>=20
> by the way, i did never hear about this git repository before...can
you describe us, where is it and
> how we can access it and which projects are now hosted by it?
>=20
>=20
> thanks
>=20
>=20
> > Date: Mon, 21 Jan 2008 00:54:30 -0700
> > From: dhbaird@gmail.com
> > To: mamsadegh@hotmail.com
> > Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
> >
> > On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<mamsadegh@hotmail.com> wrote:
> > > As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC
in
> > > Virtex-4 FX devices to PLB bus,
> > > now, in the new release of EDK , EDK 9.2 Xilinx has added a new
interface
> > > core , which is called XPS_LL_TEMAC and has a different structure
than
> > > normal PLB TEMAC. spacially it has some additional data transfer
buses.
> > >
> > > Now the question is,... is there any linux driver available for
this new
> > > core?
> >
> > Yes there is, but I had to use the git sources at:
> >
> > git.xilinx.com
>=20
>=20
> ________________________________
^ permalink raw reply
* Early driver development resources
From: Benedict, Michael @ 2008-01-21 18:20 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I wrote a driver for a 4 segment digital display device. I have
a requirement that this device be used as early as possible to report
kernel bootup state. The driver itself is pretty simple, just using
in/out_be32() and udelay(). The problem is that I don't know how to use
hardware resources in the early stages of booting, before I can call
request_mem_region() and friends.
Can anyone recommend a book / documentation / reference code /
anything that demonstrates this, or at least could improve my
understanding enough to accomplish this?
Many thanks,
Michael
^ permalink raw reply
* Re: patches for 2.6.25
From: Scott Wood @ 2008-01-21 18:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801211041100.14676@blarg.am.freescale.net>
On Mon, Jan 21, 2008 at 10:43:11AM -0600, Kumar Gala wrote:
> I'm sure I missed some patches for 2.6.25, so please point any out that
> people would like to see get in.
How about Jochen Friedrich's 8xx cleanup patches that were posted
recently?
-Scott
^ permalink raw reply
* [PATCH} PIKA FPGA WDT driver
From: Sean MacLennan @ 2008-01-21 18:03 UTC (permalink / raw)
To: linuxppc-dev
The PIKA FPGA has a watchdog. It is currently only used on the Warp
board, but it could be used on other future PIKA products. We tend to
try to reuse FPGA code as much as possible.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 52dff40..fc1b9fe 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -666,6 +666,14 @@ config BOOKE_WDT
Please see Documentation/watchdog/watchdog-api.txt for
more information.
+config PIKA_WDT
+ tristate "PIKA FPGA Watchdog"
+ depends on WARP
+ default y
+ help
+ This enables the watchdog in the PIKA FPGA. Currently used on
+ the Warp platform.
+
# PPC64 Architecture
config WATCHDOG_RTAS
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 87483cc..efa4731 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
+obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
# PPC64 Architecture
obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
diff --git a/drivers/watchdog/pika_wdt.c b/drivers/watchdog/pika_wdt.c
new file mode 100644
index 0000000..074756b
--- /dev/null
+++ b/drivers/watchdog/pika_wdt.c
@@ -0,0 +1,124 @@
+/*
+ * PIKA FPGA based Watchdog Timer
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ */
+
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/reboot.h>
+#include <linux/uaccess.h>
+#include <linux/io.h>
+#include <linux/of_platform.h>
+#include <linux/watchdog.h>
+
+
+static void __iomem *pikawdt_fpga;
+
+
+static inline void pikawdt_ping(void)
+{ /* Any write will do */
+ unsigned reset = in_be32(pikawdt_fpga);
+ out_be32(pikawdt_fpga, reset);
+}
+
+static int pikawdt_open(struct inode *inode, struct file *file)
+{
+ unsigned reset;
+
+ /* Enable the watchdog. Note this is an implicit ping. */
+ reset = in_be32(pikawdt_fpga);
+ reset |= 0xf80; /* enable with max timeout - 15 seconds */
+ out_be32(pikawdt_fpga, reset);
+
+ return 0;
+}
+
+static int pikawdt_release(struct inode *inode, struct file *file)
+{
+ pikawdt_ping(); /* one last time */
+ return 0;
+}
+
+static ssize_t pikawdt_write(struct file *file, const char __user *buf, size_t count,
+ loff_t *ppos)
+{
+ pikawdt_ping();
+ return count;
+}
+
+/* We support the bare minimum to be conformant. */
+static int pikawdt_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ if (cmd == WDIOC_KEEPALIVE) {
+ pikawdt_ping();
+ return 0;
+ } else
+ return -EINVAL;
+}
+
+static const struct file_operations pikawdt_fops = {
+ .owner = THIS_MODULE,
+ .open = pikawdt_open,
+ .release = pikawdt_release,
+ .write = pikawdt_write,
+ .ioctl = pikawdt_ioctl,
+};
+
+static struct miscdevice pikawdt_miscdev = {
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &pikawdt_fops,
+};
+
+static int __init pikawdt_init(void)
+{
+ struct device_node *np;
+ struct resource res;
+ int ret;
+
+ if ((np = of_find_compatible_node(NULL, NULL, "pika,fpga")) == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find fpga\n");
+ return -ENOENT;
+ }
+
+ /* We do not call of_iomap here since it would map in the entire
+ * fpga space, which is over 8k.
+ */
+ ret = of_address_to_resource(np, 0, &res);
+ of_node_put(np);
+
+ if (ret) {
+ printk(KERN_ERR __FILE__ ": Unable to get FPGA address\n");
+ return ret;
+ }
+
+ pikawdt_fpga = ioremap(res.start + 0x14, 4);
+ if (pikawdt_fpga == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map FPGA\n");
+ return -ENOENT;
+ }
+
+ ret = misc_register(&pikawdt_miscdev);
+ if (ret) {
+ iounmap(pikawdt_fpga);
+ printk(KERN_ERR "pikawdt: cannot register miscdev on minor=%d (err=%d)\n",
+ WATCHDOG_MINOR, ret);
+ return ret;
+ }
+
+ return 0;
+}
+module_init(pikawdt_init);
+
+
+static void __exit pikawdt_exit(void)
+{
+ misc_deregister(&pikawdt_miscdev);
+
+ iounmap(pikawdt_fpga);
+}
+module_exit(pikawdt_exit);
^ permalink raw reply related
* RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Koss, Mike (Mission Systems) @ 2008-01-21 17:44 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, David Baird, linuxppc-embedded
In-Reply-To: <BAY115-W344A18C61627B3075C6281B23D0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
In case anyone is interested, I'm currently working on an
almost-kernel-ready version that will be self-contained based on the
LL-DMA version (the native MPMC port, not the PLB). It's based upon the
old adapter from MontaVista, that I originally ported to 2.6 and the
MPMC2. Unfortunately, it won't be ready for another few weeks since I'm
working on hardware images currently.
-- Mike
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Monday, January 21, 2008 3:54 AM
To: David Baird; linuxppc-embedded@ozlabs.org
Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
thanks for you reply david,
As far as I know the Linux driver for Xilinx PLB TEMAC was two parts :
1- adapter.c and 2- the rest of the driver files
Only adapter.c was really a linux related file and the rest of the files
were Xilinx generic driver code for PLB TEMAC.
correct?
then now, I know EDK 9.2 generates the needed Linux support package and
needed related files, so if this is the case can we use these files as
the needed driver in our linux kernel?
by the way, i did never hear about this git repository before...can you
describe us, where is it and how we can access it and which projects are
now hosted by it?
thanks
> Date: Mon, 21 Jan 2008 00:54:30 -0700
> From: dhbaird@gmail.com
> To: mamsadegh@hotmail.com
> Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>
> On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<mamsadegh@hotmail.com> wrote:
> > As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC
in
> > Virtex-4 FX devices to PLB bus,
> > now, in the new release of EDK , EDK 9.2 Xilinx has added a new
interface
> > core , which is called XPS_LL_TEMAC and has a different structure
than
> > normal PLB TEMAC. spacially it has some additional data transfer
buses.
> >
> > Now the question is,... is there any linux driver available for this
new
> > core?
>
> Yes there is, but I had to use the git sources at:
>
> git.xilinx.com
________________________________
[-- Attachment #2: Type: text/html, Size: 3216 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] Warp Base Platform
From: Sean MacLennan @ 2008-01-21 17:55 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <478E9369.5090605@pikatech.com>
I finally got around to cleaning up the board driver, so the fpga init
function is now moved to the right place. The pika_dtm_start now asks
for the resources itself. This hopefully is the last patch to these
files for a while.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x && !CPM2 && !8xx && !PPC_83xx \
&& !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool "PIKA Warp"
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
+ Telephony Developers" link for more information.
+
#config LUAN
# bool "Luan"
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..0864d4f 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,5 @@ obj-$(CONFIG_BAMBOO) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
+obj-$(CONFIG_WARP) += warp-nand.o
diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
new file mode 100644
index 0000000..84ab78f
--- /dev/null
+++ b/arch/powerpc/platforms/44x/warp-nand.c
@@ -0,0 +1,105 @@
+/*
+ * PIKA Warp(tm) NAND flash specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ */
+
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/ndfc.h>
+
+#ifdef CONFIG_MTD_NAND_NDFC
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD0000000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+ .name = "kernel",
+ .offset = 0,
+ .size = 0x0200000
+ },
+ {
+ .name = "root",
+ .offset = 0x0200000,
+ .size = 0x3400000
+ },
+ {
+ .name = "user",
+ .offset = 0x3600000,
+ .size = 0x0A00000
+ },
+};
+
+struct ndfc_controller_settings warp_ndfc_settings = {
+ .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
+ .ndfc_erpn = 0,
+};
+
+static struct ndfc_chip_settings warp_chip0_settings = {
+ .bank_settings = 0x80002222,
+};
+
+struct platform_nand_ctrl warp_nand_ctrl = {
+ .priv = &warp_ndfc_settings,
+};
+
+static struct platform_device warp_ndfc_device = {
+ .name = "ndfc-nand",
+ .id = 0,
+ .dev = {
+ .platform_data = &warp_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+};
+
+static struct nand_ecclayout nand_oob_16 = {
+ .eccbytes = 3,
+ .eccpos = { 0, 1, 2, 3, 6, 7 },
+ .oobfree = { {.offset = 8, .length = 16} }
+};
+
+static struct platform_nand_chip warp_nand_chip0 = {
+ .nr_chips = 1,
+ .chip_offset = CS_NAND_0,
+ .nr_partitions = ARRAY_SIZE(nand_parts),
+ .partitions = nand_parts,
+ .chip_delay = 50,
+ .ecclayout = &nand_oob_16,
+ .priv = &warp_chip0_settings,
+};
+
+static struct platform_device warp_nand_device = {
+ .name = "ndfc-chip",
+ .id = 0,
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+ .dev = {
+ .platform_data = &warp_nand_chip0,
+ .parent = &warp_ndfc_device.dev,
+ }
+};
+
+static int warp_setup_nand_flash(void)
+{
+ platform_device_register(&warp_ndfc_device);
+ platform_device_register(&warp_nand_device);
+
+ return 0;
+}
+device_initcall(warp_setup_nand_flash);
+
+#endif
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
new file mode 100644
index 0000000..8f01563
--- /dev/null
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -0,0 +1,153 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <linux/kthread.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+
+#include "44x.h"
+
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "pika,warp");
+}
+
+define_machine(warp) {
+ .name = "Warp",
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+
+#define LED_GREEN (0x80000000 >> 0)
+#define LED_RED (0x80000000 >> 1)
+
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void __iomem *gpio_base = NULL;
+ unsigned leds;
+
+ if (gpio_base == NULL) {
+ struct device_node *np;
+
+ /* Power LEDS are on the second GPIO controller */
+ np = of_find_compatible_node(NULL, NULL, "ibm,gpio-440EP");
+ if (np)
+ np = of_find_compatible_node(np, NULL, "ibm,gpio-440EP");
+ if (np == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find gpio\n");
+ return;
+ }
+
+ gpio_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (gpio_base == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map gpio");
+ return;
+ }
+ }
+
+ leds = in_be32(gpio_base);
+
+ switch (green) {
+ case 0: leds &= ~LED_GREEN; break;
+ case 1: leds |= LED_GREEN; break;
+ }
+ switch (red) {
+ case 0: leds &= ~LED_RED; break;
+ case 1: leds |= LED_RED; break;
+ }
+
+ out_be32(gpio_base, leds);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+#ifdef CONFIG_SENSORS_AD7414
+static int pika_dtm_thread(void __iomem *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while (!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ return 0;
+}
+
+static int __init pika_dtm_start(void)
+{
+ struct task_struct *dtm_thread;
+ struct device_node *np;
+ struct resource res;
+ void __iomem *fpga;
+
+ np = of_find_compatible_node(NULL, NULL, "pika,fpga");
+ if (np == NULL)
+ return -ENOENT;
+
+ /* We do not call of_iomap here since it would map in the entire
+ * fpga space, which is over 8k.
+ */
+ if (of_address_to_resource(np, 0, &res)) {
+ of_node_put(np);
+ return -ENOENT;
+ }
+ of_node_put(np);
+
+ fpga = ioremap(res.start + 0x20, 4);
+ if (fpga == NULL)
+ return -ENOENT;
+
+ dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
+ if (IS_ERR(dtm_thread)) {
+ iounmap(fpga);
+ return PTR_ERR(dtm_thread);
+ }
+
+ return 0;
+}
+device_initcall(pika_dtm_start);
+#endif
^ permalink raw reply related
* Re: Warp Watchdog
From: Sean MacLennan @ 2008-01-21 17:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080121080157.0b66c7fc@zod.rchland.ibm.com>
Josh Boyer wrote:
> I'm not thrilled with it being in the platform file itself. It should
> really go into drivers/watchdog. It's OK that the watchdog is tied to
> Warp, that really isn't an issue. Just make it depend on Warp in the
> Kconfig file. And you can select it in your board config so that it's
> built in-kernel and not as a module.
>
> The code itself looks pretty clean.
>
Thanks for the feedback. I think I was trying to convince myself that
the platform was a good place but honestly felt it should be in the
drivers/watchdog. So I moved it there.
Cheers,
Sean
^ permalink raw reply
* Re: patches for 2.6.25
From: Jochen Friedrich @ 2008-01-21 17:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801211041100.14676@blarg.am.freescale.net>
Hi Kumar,
> I'm sure I missed some patches for 2.6.25, so please point any out that
> people would like to see get in.
What about this one, now that the fixed phy parts are in:
http://patchwork.ozlabs.org/linuxppc/patch?person=1023&id=15654
Thanks,
Jochen
^ permalink raw reply
* Re: Generated xilinx linux 2.6 image sections
From: Grant Likely @ 2008-01-21 17:16 UTC (permalink / raw)
To: greenlean; +Cc: linuxppc-embedded
In-Reply-To: <14997109.post@talk.nabble.com>
On 1/21/08, greenlean <jmgomez@atc.ugr.es> wrote:
>
> Hi all,
>
> I'm trying to boot the 2.6 xilinx kernel downloaded from their git server in
> the XUPV2P board I'm really having troubles (I can't see anything in the
> minicom console terminal). I'm not seeing anything, neither the ucompressing
> kernel string nor the prompt with the memory addresses that kernel prompt at
> first time, so I have started to distrust of anything.
>
> When I download the kernel using xmd, I see:
>
> XMD% dow imagen_UART16550_ml300.elf
> section, .text: 0x00400000-0x0040387b
> section, .data: 0x00404000-0x004e6fff
> section, .bss: 0x004e7000-0x004e919f
> Downloaded Program imagen_UART16550_ml300.elf
> Setting PC with Program Start Address 0x00400000
>
<snip>
> I suppossed this is because the image kernel is compressed, but despite
> beeing compressed it should have a boot section or something similar ???
> It's right that the kernel start address is set to the 0x00400000??
>
> Or does the section .text contains all the kernel code to uncompresse the
> code of the kernel??
Yes; what you're seeing is the sections for the boot wrapper; not for
the kernel itself. The bootwrapper carries a compressed kernel image
as it's payload (notice how large the .data section is?). To see the
sections on the kernel proper, use readelf on the vmlinux file in the
kernel tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Grant Likely @ 2008-01-21 17:11 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, linux-usb
In-Reply-To: <20080121103434.397382000@sunsite.dk>
On 1/21/08, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> USB controllers. This patch series implements a HCD driver and shows the
> work-in-progress status of a gadget driver.
>
> I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25.
>
> Changes since v3:
> - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
> - The dummy platform_device's created per serial engine are gone.
> - Gadget driver (WIP)
Can you please post/publish the diff between v3 and this series?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Juergen Beisert @ 2008-01-21 16:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mehlan, Markus (Ritter Elektronik)
In-Reply-To: <FACFFB02D783C64FB2CEF2D6825F6FC206EEF1C0@SRVEXC01.sts.saurer.vpn>
On Monday 21 January 2008 14:01, Mehlan, Markus (Ritter Elektronik) wrote:
> > -----Urspr=FCngliche Nachricht-----
> > Von: Juergen Beisert [mailto:jbe@pengutronix.de]
> > Gesendet: Montag, 21. Januar 2008 09:58
> > An: linuxppc-dev@ozlabs.org
> > Cc: Mehlan, Markus (Ritter Elektronik)
> > Betreff: Re: [MPC5200] problem running FEC and ATA
> >
> > Markus,
> >
> > On Monday 21 January 2008 08:10, Mehlan, Markus (Ritter
> >
> > Elektronik) wrote:
> > > i have the same problem with the fec driver. See my posting at
> >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2008-January/029466.html
> >
> > > Arnon, have you already fixed the FEC problem?
> >
> > Can you check this?
> >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2007-May/027046.html
>
> I have checked the article. To set the BSDIS bit in the XLB config regist=
er
> during initialization fixes my problem:
>
> xlb =3D (struct mpc52xx_xlb *)MPC5xxx_XLB;
> out_be32(&xlb->config, in_be32(&xlb->config) |
> MPC52xx_XLB_CFG_BSDIS);
Is anybody out there with more MPC5200B experience? Can someone tell me why=
=20
some MPC5200B are need this patch and others not? We have two different=20
systems here (cards from different vendors) with the same processor, one=20
needs this BSDIS-patch and the other not. ???????????????
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: Endian problem when accessing internel regs on 8347
From: Scott Wood @ 2008-01-21 16:40 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OFE90E4633.93F2906B-ON882573D7.002448B6-882573D7.00287256@selinc.com>
On Sun, Jan 20, 2008 at 11:21:48PM -0800, Bruce_Leonard@selinc.com wrote:
> Okay, after much digging and experimenting, I'll agree that the memory
> operand makes sense. When I first said that I was thinking of direct
> manipulation of memory, which the PPC doesn't support. (Don't ask, my
> brain sometimes goes off into la-la land without me :-> ) Also, update
> mode is applicable and makes sense. But I do still have a problem with
> the index mode, though it could be compiler magic. Here's why: the index
> mode of the 'lwz' instruction requires three operands, i.e., 'lwzx
> rD,rA,rB', and there's only place holders for two operands. Is the
> compiler smart enough to add the third operand for the index mode? If so,
> what does it put for the third operand?
When the compiler decides to use index mode, the second "operand" is a
string containing "rX, rY", just as when it decides not to, the second
operand is a string containing "offset(rX)".
> Another question is how does the compiler know which mode to pick?
The same way it decides which mode to use for internally generated loads
and stores. Compiler optimization implementation is beyond the scope of
this list. :-)
> And what is the significance of the trailing number? Some places in
> the code have %U1%X1 and others have %U2%X2? I've found documentation
> for the # and ## tokens, but I can't find anything for the %U or %X
> tokens.
The number is an index into the operand list at the end of the asm
statement.
> Now this has all been very interesting to learn but doesn't solve my
> underlying problem which I've finally drilled down to. At first I thought
> in_be32() might be broken because I wasn't getting back the value I knew
> to be in the internal register. I knew I had the address and the mapping
> to kernel space correct because I could use in_le32 and get the right
> value though it was byte swapped.
Are you absolutely sure that in_le32 to in_be32 is the only thing that
changed? If you change it back now, does it resume returning a byte-swap
of the correct value?
If that is indeed what is making the difference, then perhaps it's some
subtle timing (or memory corruption) difference caused by different code
generation because the compiler is forced to use index mode for in_le32
(though it appears that the same operand list is given to GCC in either
case -- is GCC smart enough to optimize away preperation of inputs that
aren't actually referenced in the asm statement?). Is there any
difference in the generated assembly besides the specific load
instruction used?
Alternatively, maybe your chip is just fried. :-)
> I don't want to just arbitrarily point to that %U1%X1 parameter list,
So please don't.
> but I get compiler errors if I try to remove them
That's why it's there. :-)
> Can't anyone suggest anything I can try?
Beer.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] i2c: Convert all new-style drivers to use module aliasing
From: Jon Smirl @ 2008-01-21 16:50 UTC (permalink / raw)
To: Jean Delvare; +Cc: David Brownell, linuxppc-dev, Linux I2C
In-Reply-To: <20080121114139.3aaa111a@hyperion.delvare>
In my version of these patches new style drivers could be loaded with
both the driver_name/name scheme and the modalias. In these patches
new style drivers can only be loaded via modalias. Is that what you
intended? I'm all for making new style driver only use the modalias
scheme.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* patches for 2.6.25
From: Kumar Gala @ 2008-01-21 16:43 UTC (permalink / raw)
To: linuxppc-dev
I'm sure I missed some patches for 2.6.25, so please point any out that
people would like to see get in.
- k
^ permalink raw reply
* Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-01-21 16:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
Documentation/powerpc/00-INDEX | 3
Documentation/powerpc/booting-without-of.txt | 91 +
Documentation/powerpc/qe_firmware.txt | 295 ++++
arch/powerpc/Kconfig | 3
arch/powerpc/boot/.gitignore | 1
arch/powerpc/boot/Makefile | 7
arch/powerpc/boot/cuboot-83xx.c | 3
arch/powerpc/boot/cuboot-85xx.c | 5
arch/powerpc/boot/devtree.c | 14
arch/powerpc/boot/dts/adder875-redboot.dts | 184 ++
arch/powerpc/boot/dts/adder875-uboot.dts | 183 ++
arch/powerpc/boot/dts/ep8248e.dts | 207 +++
arch/powerpc/boot/dts/mpc8313erdb.dts | 49
arch/powerpc/boot/dts/mpc832x_mds.dts | 51
arch/powerpc/boot/dts/mpc8349emitx.dts | 30
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 1
arch/powerpc/boot/dts/mpc834x_mds.dts | 2
arch/powerpc/boot/dts/mpc836x_mds.dts | 1
arch/powerpc/boot/dts/mpc8377_mds.dts | 279 ++++
arch/powerpc/boot/dts/mpc8378_mds.dts | 265 ++++
arch/powerpc/boot/dts/mpc8379_mds.dts | 293 ++++
arch/powerpc/boot/dts/mpc8544ds.dts | 6
arch/powerpc/boot/dts/mpc8572ds.dts | 7
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 113 +
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 6
arch/powerpc/boot/ep8248e.c | 55
arch/powerpc/boot/ops.h | 14
arch/powerpc/boot/redboot-8xx.c | 58
arch/powerpc/boot/redboot.h | 56
arch/powerpc/boot/wrapper | 2
arch/powerpc/configs/adder875-redboot_defconfig | 798 ++++++++++++
arch/powerpc/configs/adder875-uboot_defconfig | 798 ++++++++++++
arch/powerpc/configs/ep8248e_defconfig | 821 +++++++++++++
arch/powerpc/configs/mpc8313_rdb_defconfig | 46
arch/powerpc/configs/mpc834x_itx_defconfig | 3
arch/powerpc/configs/mpc8610_hpcd_defconfig | 171 ++
arch/powerpc/kernel/head_fsl_booke.S | 20
arch/powerpc/kernel/pci-common.c | 8
arch/powerpc/kernel/pci_32.c | 58
arch/powerpc/math-emu/op-4.h | 40
arch/powerpc/mm/fsl_booke_mmu.c | 6
arch/powerpc/mm/lmb.c | 13
arch/powerpc/mm/mem.c | 20
arch/powerpc/platforms/82xx/Kconfig | 13
arch/powerpc/platforms/82xx/Makefile | 1
arch/powerpc/platforms/82xx/ep8248e.c | 324 +++++
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 13
arch/powerpc/platforms/83xx/mpc832x_mds.c | 5
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 10
arch/powerpc/platforms/83xx/mpc834x_itx.c | 12
arch/powerpc/platforms/83xx/mpc834x_mds.c | 5
arch/powerpc/platforms/83xx/mpc836x_mds.c | 5
arch/powerpc/platforms/83xx/mpc837x_mds.c | 56
arch/powerpc/platforms/83xx/mpc83xx.h | 3
arch/powerpc/platforms/83xx/usb.c | 46
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 18
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 7
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 15
arch/powerpc/platforms/8xx/Kconfig | 9
arch/powerpc/platforms/8xx/Makefile | 1
arch/powerpc/platforms/8xx/adder875.c | 118 +
arch/powerpc/platforms/Kconfig | 6
arch/powerpc/sysdev/Makefile | 2
arch/powerpc/sysdev/fsl_pci.c | 139 --
arch/powerpc/sysdev/fsl_soc.c | 103 +
arch/powerpc/sysdev/ipic.c | 62
arch/powerpc/sysdev/mpic.c | 4
arch/powerpc/sysdev/qe_lib/Kconfig | 2
arch/powerpc/sysdev/qe_lib/qe.c | 247 +++
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 10
drivers/net/phy/Kconfig | 32
drivers/net/phy/fixed.c | 445 ++-----
drivers/serial/Kconfig | 10
drivers/serial/Makefile | 1
drivers/serial/ucc_uart.c | 1514 ++++++++++++++++++++++++
include/asm-powerpc/immap_qe.h | 34
include/asm-powerpc/lmb.h | 1
include/asm-powerpc/mpc8260.h | 1
include/asm-powerpc/pci-bridge.h | 3
include/asm-powerpc/qe.h | 61
include/linux/phy_fixed.h | 51
82 files changed, 7840 insertions(+), 641 deletions(-)
Anton Vorontsov (1):
[POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Becky Bruce (1):
[POWERPC] Fixup use of phys_addr_t in mpic code
Dale Farnsworth (1):
[POWERPC] 85xx: Respect KERNELBASE, PAGE_OFFSET, and PHYSICAL_START on e500
John Rigby (2):
[POWERPC] Add support for mpc512x interrupts to ipic
[POWERPC] Add IPIC Kconfig option
Kumar Gala (10):
[POWERPC] Fix handling of memreserve if the range lands in highmem
[POWERPC] Ensure we only handle PowerMac PCI bus fixup for memory resources
[POWERPC] Fixup transparent P2P resources
[POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx
[POWERPC] Remove update_bridge_resource
[POWERPC] 85xx: convert boards to use machine_device_initcall
[POWERPC] 83xx: convert boards to use machine_device_initcall
[POWERPC] bootwrapper: Add find_node_by_alias and dt_fixup_mac_address_by_alias
[POWERPC] bootwrapper: convert cuboot-8{3,5}xx to dt_fixup_mac_address_by_alias
[POWERPC] Fix incorrect interrupt map on FSL reference boards
Li Yang (3):
[POWERPC] 83xx: add device trees for MPC837x MDS board
[POWERPC] 83xx: Add MPC837x USB platform support
[POWERPC] 83xx: USB device tree cleanups
Liu Yu (1):
[POWERPC] Fix carry bug in 128-bit unsigned integer adding
Paul Gortmaker (1):
[POWERPC] 85xx: mpc85xx_ads: add in missing of_node_put()
Scott Wood (6):
[POWERPC] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
[POWERPC] 8xx: Analogue & Micro Adder875 board support.
[POWERPC] 82xx: Embedded Planet EP8248E support
[POWERPC] 83xx: MPC8313e RBD add NAND to device tree
[POWERPC] 83xx: MPC8313e RDB - Add NOR flash to the device tree.
[POWERPC] 83xx: Update MPC8313e RDB defconfig for MTD, NAND, JFFS2.
Timur Tabi (4):
[POWERPC] QE: Add ability to upload QE firmware
[POWERPC] QE: Add support for Freescale QUICCEngine UART
[POWERPC] qe-uart: add support for Freescale QUICCEngine UART
[POWERPC] Update MPC8610 HPCD to support audio drivers
Vitaly Bordug (3):
phy/fixed.c: rework to not duplicate PHY layer functionality
[POWERPC] MPC8349E-mITX: Vitesse 7385 PHY is not connected to the MDIO bus
[POWERPC] fsl_soc: add support to gianfar for fixed-link property
^ permalink raw reply
* Re: [PATCH 2/3] mpc8313erdb: Add NOR flash to the device tree.
From: Kumar Gala @ 2008-01-21 16:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080117223755.GB20697@loki.buserror.net>
On Thu, 17 Jan 2008, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8313erdb.dts | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
applied.
- k
^ 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