* [PATCH] make platform_init() weak for 8xx
@ 2004-07-19 16:13 Andreas Oberritter
2004-07-19 16:32 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Oberritter @ 2004-07-19 16:13 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]
Hi Tom,
this patch renames platform_init to m8xx_init in m8xx_setup.c and adds
new weak platform_init, which can be overridden by boards to allow them
to e.g. register platform_devices like redwood5.c does for 40x.
Signed-off-by: Andreas Oberritter <obi@saftware.de>
[-- Attachment #2: m8xx_setup.diff --]
[-- Type: text/x-patch, Size: 1302 bytes --]
===== arch/ppc/syslib/m8xx_setup.c 1.29 vs edited =====
--- 1.29/arch/ppc/syslib/m8xx_setup.c 2004-05-28 00:37:33 +02:00
+++ edited/arch/ppc/syslib/m8xx_setup.c 2004-07-19 17:54:03 +02:00
@@ -47,6 +47,7 @@
#include <asm/xmon.h>
#include "ppc8xx_pic.h"
+#include "m8xx_setup.h"
static int m8xx_set_rtc_time(unsigned long time);
static unsigned long m8xx_get_rtc_time(void);
@@ -363,7 +364,7 @@
}
void __init
-platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+m8xx_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
parse_bootinfo(find_bootinfo());
@@ -413,3 +414,11 @@
m8xx_ide_init();
#endif
}
+
+void __init __attribute__ ((weak))
+platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ m8xx_init(r3, r4, r5, r6, r7);
+}
+
--- /dev/null 2004-07-17 13:36:50.945552208 +0200
+++ edited/arch/ppc/syslib/m8xx_setup.h 2004-07-19 17:15:37.854994064 +0200
@@ -0,0 +1,12 @@
+/*
+ * arch/ppc/syslib/m8xx_setup.h
+ */
+
+#ifndef _PPC_SYSLIB_M8XX_SETUP_H
+#define _PPC_SYSLIB_M8XX_SETUP_H
+
+void m8xx_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7);
+void m8xx_setup_arch(void);
+
+#endif /* _PPC_SYSLIB_M8XX_SETUP_H */
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] make platform_init() weak for 8xx
2004-07-19 16:13 [PATCH] make platform_init() weak for 8xx Andreas Oberritter
@ 2004-07-19 16:32 ` Tom Rini
2004-07-19 17:34 ` Andreas Oberritter
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2004-07-19 16:32 UTC (permalink / raw)
To: Andreas Oberritter; +Cc: linuxppc-embedded
On Mon, Jul 19, 2004 at 06:13:35PM +0200, Andreas Oberritter wrote:
> Hi Tom,
>
> this patch renames platform_init to m8xx_init in m8xx_setup.c and adds
> new weak platform_init, which can be overridden by boards to allow them
> to e.g. register platform_devices like redwood5.c does for 40x.
First, I don't see the redwood5 example you're talking about.
Second, this takes us in the direction of 82xx. Until the 82xx
abstractions get flushed out a bit more, I remain unconvinced that
they're really the right way to go (perhaps hooking the other direction
would work better, e.g. platform_init() calls board_init(), with a weak
version provided, and some functions forced to be provided by board.c,
such as m8xx_map_io).
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] make platform_init() weak for 8xx
2004-07-19 16:32 ` Tom Rini
@ 2004-07-19 17:34 ` Andreas Oberritter
2004-07-19 18:20 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Oberritter @ 2004-07-19 17:34 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
On Mon, 2004-07-19 at 18:32, Tom Rini wrote:
> On Mon, Jul 19, 2004 at 06:13:35PM +0200, Andreas Oberritter wrote:
> > this patch renames platform_init to m8xx_init in m8xx_setup.c and adds
> > new weak platform_init, which can be overridden by boards to allow them
> > to e.g. register platform_devices like redwood5.c does for 40x.
>
> First, I don't see the redwood5 example you're talking about.
http://ppc.bkbits.net:8080/linuxppc-2.5/anno/arch/ppc/platforms/4xx/redwood5.c@1.11?nav=index.html
> Second, this takes us in the direction of 82xx. Until the 82xx
> abstractions get flushed out a bit more, I remain unconvinced that
> they're really the right way to go (perhaps hooking the other direction
> would work better, e.g. platform_init() calls board_init(), with a weak
> version provided, and some functions forced to be provided by board.c,
> such as m8xx_map_io).
I chose this way because it seemed to be a simple way to port the dbox2
board to 2.6 using the new device API. Is there another 8xx board which
uses the device API for its onboard peripherials and can be used as a
reference? Can I get my devices registered without modifying
platform_init, or shall I send a patch with the board_init() you
mentioned? See my board.c attached.
Regards,
Andreas
[-- Attachment #2: dbox2.c --]
[-- Type: text/x-csrc, Size: 3463 bytes --]
/*
* arch/ppc/platforms/dbox2.c
*
* setup routines for the dbox2 board
*
* Copyright (C) 2004 Andreas Oberritter <obi@linuxtv.org>
*
*/
#include <linux/device.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <asm/commproc.h>
#include <asm/io.h>
#include <syslib/m8xx_setup.h>
enum dbox2_mid {
MID_NOKIA = 1,
MID_PHILIPS = 2,
MID_SAGEM = 3,
};
const char *manuf_name[3] = {
"Nokia",
"Philips",
"Sagem",
};
static struct resource enx_resources[] = {
[0] = {
.start = 0x08000000,
.end = 0x080033ff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 0x09000000,
.end = 0x091fffff,
.flags = IORESOURCE_MEM,
},
[2] = {
.start = SIU_IRQ1,
.end = SIU_IRQ1,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device enx_device = {
.name = "enx",
.id = 0,
.num_resources = ARRAY_SIZE(enx_resources),
.resource = enx_resources,
};
static struct resource gtx_resources[] = {
[0] = {
.start = 0x08400000,
.end = 0x08402fff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 0x08000000,
.end = 0x081fffff,
.flags = IORESOURCE_MEM,
},
[2] = {
.start = SIU_IRQ1,
.end = SIU_IRQ1,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device gtx_device = {
.name = "gtx",
.id = 0,
.num_resources = ARRAY_SIZE(gtx_resources),
.resource = gtx_resources,
};
static struct resource fp_resources[] = {
[0] = {
.start = SIU_IRQ2,
.end = SIU_IRQ2,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device fp_device = {
.name = "fp",
.id = 0,
.num_resources = ARRAY_SIZE(fp_resources),
.resource = fp_resources,
};
static struct resource cam_resources[] = {
[0] = {
.start = 0x0c000000,
.end = 0x0c01ffff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = SIU_IRQ3,
.end = SIU_IRQ3,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device cam_device = {
.name = "cam",
.id = 0,
.num_resources = ARRAY_SIZE(cam_resources),
.resource = cam_resources,
};
static struct resource avia_resources[] = {
[0] = {
.start = 0x0a000000,
.end = 0x0a0001ff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = SIU_IRQ4,
.end = SIU_IRQ4,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device avia_device = {
.name = "avia",
.id = 0,
.num_resources = ARRAY_SIZE(avia_resources),
.resource = avia_resources,
};
static struct platform_device *dbox2_devs[] __initdata = {
&enx_device,
&fp_device,
&cam_device,
&avia_device,
};
static int __init dbox2_add_devices(void)
{
u8 *config_area;
int manuf_id;
config_area = ioremap(0x1001ffe0, 0x20);
if (!config_area) {
printk(KERN_ERR "dbox2: could not map config area!\n");
return -EIO;
}
manuf_id = config_area[0];
iounmap(config_area);
if ((manuf_id < MID_NOKIA) || (manuf_id > MID_SAGEM)) {
printk(KERN_ERR "dbox2: invalid config area!\n");
return -EIO;
}
printk(KERN_INFO "dbox2: %s board detected.\n", manuf_name[manuf_id - 1]);
if (manuf_id == MID_NOKIA) {
dbox2_devs[0] = >x_device;
} else if (manuf_id == MID_PHILIPS) {
cam_resources[0].start += 0x40000;
cam_resources[0].end += 0x40000;
}
return platform_add_devices(dbox2_devs, ARRAY_SIZE(dbox2_devs));
}
static void __init dbox2_setup_arch(void)
{
m8xx_setup_arch();
device_initcall(dbox2_add_devices);
}
void __init platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
m8xx_init(r3, r4, r5, r6, r7);
ppc_md.setup_arch = dbox2_setup_arch;
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] make platform_init() weak for 8xx
2004-07-19 17:34 ` Andreas Oberritter
@ 2004-07-19 18:20 ` Tom Rini
2004-07-23 13:59 ` [PATCH] add board_init() (was [PATCH] make platform_init() weak for 8xx) Andreas Oberritter
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2004-07-19 18:20 UTC (permalink / raw)
To: Andreas Oberritter; +Cc: linuxppc-embedded
On Mon, Jul 19, 2004 at 07:34:28PM +0200, Andreas Oberritter wrote:
> On Mon, 2004-07-19 at 18:32, Tom Rini wrote:
> > On Mon, Jul 19, 2004 at 06:13:35PM +0200, Andreas Oberritter wrote:
> > > this patch renames platform_init to m8xx_init in m8xx_setup.c and adds
> > > new weak platform_init, which can be overridden by boards to allow them
> > > to e.g. register platform_devices like redwood5.c does for 40x.
> >
> > First, I don't see the redwood5 example you're talking about.
>
> http://ppc.bkbits.net:8080/linuxppc-2.5/anno/arch/ppc/platforms/4xx/redwood5.c@1.11?nav=index.html
Ah, I follow you now. This too, seems awkward to me. I'm making myself
a note to talk with Matt Porter when I see him tomorrow about this.
> > Second, this takes us in the direction of 82xx. Until the 82xx
> > abstractions get flushed out a bit more, I remain unconvinced that
> > they're really the right way to go (perhaps hooking the other direction
> > would work better, e.g. platform_init() calls board_init(), with a weak
> > version provided, and some functions forced to be provided by board.c,
> > such as m8xx_map_io).
>
> I chose this way because it seemed to be a simple way to port the dbox2
> board to 2.6 using the new device API. Is there another 8xx board which
> uses the device API for its onboard peripherials and can be used as a
> reference? Can I get my devices registered without modifying
> platform_init, or shall I send a patch with the board_init() you
> mentioned? See my board.c attached.
There currently isn't a reference platform for what you speak of. My
preference would be to see what I described given a shot to see if it
looks better or worse (and it better, or worse, in the flow of things).
But, tomorrow I leave for OLS, so if I don't reply, well, that's my
excuse.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] add board_init() (was [PATCH] make platform_init() weak for 8xx)
2004-07-19 18:20 ` Tom Rini
@ 2004-07-23 13:59 ` Andreas Oberritter
2004-07-27 21:01 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Oberritter @ 2004-07-23 13:59 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
Am Mo, den 19.07.2004 schrieb Tom Rini um 20:20:
> On Mon, Jul 19, 2004 at 07:34:28PM +0200, Andreas Oberritter wrote:
>
> > On Mon, 2004-07-19 at 18:32, Tom Rini wrote:
> > > Second, this takes us in the direction of 82xx. Until the 82xx
> > > abstractions get flushed out a bit more, I remain unconvinced that
> > > they're really the right way to go (perhaps hooking the other direction
> > > would work better, e.g. platform_init() calls board_init(), with a weak
> > > version provided, and some functions forced to be provided by board.c,
> > > such as m8xx_map_io).
> >
> > I chose this way because it seemed to be a simple way to port the dbox2
> > board to 2.6 using the new device API. Is there another 8xx board which
> > uses the device API for its onboard peripherials and can be used as a
> > reference? Can I get my devices registered without modifying
> > platform_init, or shall I send a patch with the board_init() you
> > mentioned? See my board.c attached.
>
> There currently isn't a reference platform for what you speak of. My
> preference would be to see what I described given a shot to see if it
> looks better or worse (and it better, or worse, in the flow of things).
How about this patch?
Regards,
Andreas
[-- Attachment #2: board_init.diff --]
[-- Type: text/x-patch, Size: 843 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/07/23 15:54:13+02:00 obi@pegasos.saftware.de
# add weak board_init() function which can be overridden by board support code
#
# arch/ppc/syslib/m8xx_setup.c
# 2004/07/23 15:53:53+02:00 obi@pegasos.saftware.de +6 -0
# add weak board_init() function which can be overridden by board support code
#
diff -Nru a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c 2004-07-23 15:54:57 +02:00
+++ b/arch/ppc/syslib/m8xx_setup.c 2004-07-23 15:54:57 +02:00
@@ -61,6 +61,11 @@
extern void m8xx_wdt_handler_install(bd_t *bp);
extern void rpxfb_alloc_pages(void);
+void __attribute__ ((weak))
+board_init(void)
+{
+}
+
void __init
m8xx_setup_arch(void)
{
@@ -103,6 +108,7 @@
}
#endif
#endif
+ board_init();
}
void
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] add board_init() (was [PATCH] make platform_init() weak for 8xx)
2004-07-23 13:59 ` [PATCH] add board_init() (was [PATCH] make platform_init() weak for 8xx) Andreas Oberritter
@ 2004-07-27 21:01 ` Tom Rini
0 siblings, 0 replies; 6+ messages in thread
From: Tom Rini @ 2004-07-27 21:01 UTC (permalink / raw)
To: Andreas Oberritter; +Cc: linuxppc-embedded
On Fri, Jul 23, 2004 at 03:59:53PM +0200, Andreas Oberritter wrote:
> Am Mo, den 19.07.2004 schrieb Tom Rini um 20:20:
> > On Mon, Jul 19, 2004 at 07:34:28PM +0200, Andreas Oberritter wrote:
> >
> > > On Mon, 2004-07-19 at 18:32, Tom Rini wrote:
> > > > Second, this takes us in the direction of 82xx. Until the 82xx
> > > > abstractions get flushed out a bit more, I remain unconvinced that
> > > > they're really the right way to go (perhaps hooking the other direction
> > > > would work better, e.g. platform_init() calls board_init(), with a weak
> > > > version provided, and some functions forced to be provided by board.c,
> > > > such as m8xx_map_io).
> > >
> > > I chose this way because it seemed to be a simple way to port the dbox2
> > > board to 2.6 using the new device API. Is there another 8xx board which
> > > uses the device API for its onboard peripherials and can be used as a
> > > reference? Can I get my devices registered without modifying
> > > platform_init, or shall I send a patch with the board_init() you
> > > mentioned? See my board.c attached.
> >
> > There currently isn't a reference platform for what you speak of. My
> > preference would be to see what I described given a shot to see if it
> > looks better or worse (and it better, or worse, in the flow of things).
>
> How about this patch?
Yes, I think that's about it.
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-07-27 21:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-19 16:13 [PATCH] make platform_init() weak for 8xx Andreas Oberritter
2004-07-19 16:32 ` Tom Rini
2004-07-19 17:34 ` Andreas Oberritter
2004-07-19 18:20 ` Tom Rini
2004-07-23 13:59 ` [PATCH] add board_init() (was [PATCH] make platform_init() weak for 8xx) Andreas Oberritter
2004-07-27 21:01 ` Tom Rini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).