6 messages, 2 authors, 2004-07-27 · open the first message on its own page
From: Andreas Oberritter <hidden>
Date: 2004-07-19 16:13:35
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 <redacted>
From: Tom Rini <hidden>
Date: 2004-07-19 16:32:03
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/
From: Andreas Oberritter <hidden>
Date: 2004-07-19 17:34:28
On Mon, 2004-07-19 at 18:32, Tom Rini wrote:
On Mon, Jul 19, 2004 at 06:13:35PM +0200, Andreas Oberritter wrote:quoted
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
From: Tom Rini <hidden>
Date: 2004-07-19 18:20:47
On Mon, Jul 19, 2004 at 07:34:28PM +0200, Andreas Oberritter wrote:
On Mon, 2004-07-19 at 18:32, Tom Rini wrote:quoted
On Mon, Jul 19, 2004 at 06:13:35PM +0200, Andreas Oberritter wrote:quoted
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.
quoted
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/
From: Andreas Oberritter <hidden>
Date: 2004-07-23 13:59:53
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:quoted
On Mon, 2004-07-19 at 18:32, Tom Rini wrote:quoted
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
From: Tom Rini <hidden>
Date: 2004-07-27 21:01:32
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:quoted
On Mon, Jul 19, 2004 at 07:34:28PM +0200, Andreas Oberritter wrote:quoted
On Mon, 2004-07-19 at 18:32, Tom Rini wrote:quoted
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/