* [PATCH] powerpc: cleaned up fsl_soc.c
From: Kumar Gala @ 2006-01-23 22:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Cleaned up fsl_soc.c based on comments from Olof Johansson. Ran through
Lindent, and split gfar_mdio init into its own function.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 9a8e139654ff5807b5b8fc3f73e9d118f22a3947
tree 04fed9acbcb1565682808ac49946898ddc18a153
parent b87359141569cb0fb0fad4ba6fed7de04ec22af9
author Kumar Gala <galak@kernel.crashing.org> Mon, 23 Jan 2006 17:04:23 -0600
committer Kumar Gala <galak@kernel.crashing.org> Mon, 23 Jan 2006 17:04:23 -0600
arch/powerpc/sysdev/fsl_soc.c | 152 +++++++++++++++++++++++++----------------
1 files changed, 94 insertions(+), 58 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 064c9de..e0887d5 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -40,7 +40,7 @@ phys_addr_t get_immrbase(void)
return immrbase;
soc = of_find_node_by_type(NULL, "soc");
- if (soc != 0) {
+ if (soc) {
unsigned int size;
void *prop = get_property(soc, "reg", &size);
immrbase = of_translate_address(soc, prop);
@@ -49,21 +49,20 @@ phys_addr_t get_immrbase(void)
return immrbase;
}
-EXPORT_SYMBOL(get_immrbase);
-static const char * gfar_tx_intr = "tx";
-static const char * gfar_rx_intr = "rx";
-static const char * gfar_err_intr = "error";
+EXPORT_SYMBOL(get_immrbase);
-static int __init gfar_of_init(void)
+static int __init gfar_mdio_of_init(void)
{
struct device_node *np;
unsigned int i;
- struct platform_device *mdio_dev, *gfar_dev;
+ struct platform_device *mdio_dev;
struct resource res;
int ret;
- for (np = NULL, i = 0; (np = of_find_compatible_node(np, "mdio", "gianfar")) != NULL; i++) {
+ for (np = NULL, i = 0;
+ (np = of_find_compatible_node(np, "mdio", "gianfar")) != NULL;
+ i++) {
int k;
struct device_node *child = NULL;
struct gianfar_mdio_data mdio_data;
@@ -73,12 +72,14 @@ static int __init gfar_of_init(void)
ret = of_address_to_resource(np, 0, &res);
if (ret)
- goto mdio_err;
+ goto err;
- mdio_dev = platform_device_register_simple("fsl-gianfar_mdio", res.start, &res, 1);
+ mdio_dev =
+ platform_device_register_simple("fsl-gianfar_mdio",
+ res.start, &res, 1);
if (IS_ERR(mdio_dev)) {
ret = PTR_ERR(mdio_dev);
- goto mdio_err;
+ goto err;
}
for (k = 0; k < 32; k++)
@@ -86,17 +87,44 @@ static int __init gfar_of_init(void)
while ((child = of_get_next_child(np, child)) != NULL) {
if (child->n_intrs) {
- u32 *id = (u32 *) get_property(child, "reg", NULL);
+ u32 *id =
+ (u32 *) get_property(child, "reg", NULL);
mdio_data.irq[*id] = child->intrs[0].line;
}
}
- ret = platform_device_add_data(mdio_dev, &mdio_data, sizeof(struct gianfar_mdio_data));
+ ret =
+ platform_device_add_data(mdio_dev, &mdio_data,
+ sizeof(struct gianfar_mdio_data));
if (ret)
- goto mdio_unreg;
+ goto unreg;
}
- for (np = NULL, i = 0; (np = of_find_compatible_node(np, "network", "gianfar")) != NULL; i++) {
+ return 0;
+
+unreg:
+ platform_device_unregister(mdio_dev);
+err:
+ return ret;
+}
+
+arch_initcall(gfar_mdio_of_init);
+
+static const char *gfar_tx_intr = "tx";
+static const char *gfar_rx_intr = "rx";
+static const char *gfar_err_intr = "error";
+
+static int __init gfar_of_init(void)
+{
+ struct device_node *np;
+ unsigned int i;
+ struct platform_device *gfar_dev;
+ struct resource res;
+ int ret;
+
+ for (np = NULL, i = 0;
+ (np = of_find_compatible_node(np, "network", "gianfar")) != NULL;
+ i++) {
struct resource r[4];
struct device_node *phy, *mdio;
struct gianfar_platform_data gfar_data;
@@ -110,7 +138,7 @@ static int __init gfar_of_init(void)
ret = of_address_to_resource(np, 0, &r[0]);
if (ret)
- goto gfar_err;
+ goto err;
r[1].start = np->intrs[0].line;
r[1].end = np->intrs[0].line;
@@ -133,11 +161,13 @@ static int __init gfar_of_init(void)
r[3].flags = IORESOURCE_IRQ;
}
- gfar_dev = platform_device_register_simple("fsl-gianfar", i, &r[0], np->n_intrs + 1);
+ gfar_dev =
+ platform_device_register_simple("fsl-gianfar", i, &r[0],
+ np->n_intrs + 1);
if (IS_ERR(gfar_dev)) {
ret = PTR_ERR(gfar_dev);
- goto gfar_err;
+ goto err;
}
mac_addr = get_property(np, "address", NULL);
@@ -145,26 +175,26 @@ static int __init gfar_of_init(void)
if (model && !strcasecmp(model, "TSEC"))
gfar_data.device_flags =
- FSL_GIANFAR_DEV_HAS_GIGABIT |
- FSL_GIANFAR_DEV_HAS_COALESCE |
- FSL_GIANFAR_DEV_HAS_RMON |
- FSL_GIANFAR_DEV_HAS_MULTI_INTR;
+ FSL_GIANFAR_DEV_HAS_GIGABIT |
+ FSL_GIANFAR_DEV_HAS_COALESCE |
+ FSL_GIANFAR_DEV_HAS_RMON |
+ FSL_GIANFAR_DEV_HAS_MULTI_INTR;
if (model && !strcasecmp(model, "eTSEC"))
gfar_data.device_flags =
- FSL_GIANFAR_DEV_HAS_GIGABIT |
- FSL_GIANFAR_DEV_HAS_COALESCE |
- FSL_GIANFAR_DEV_HAS_RMON |
- FSL_GIANFAR_DEV_HAS_MULTI_INTR |
- FSL_GIANFAR_DEV_HAS_CSUM |
- FSL_GIANFAR_DEV_HAS_VLAN |
- FSL_GIANFAR_DEV_HAS_EXTENDED_HASH;
+ FSL_GIANFAR_DEV_HAS_GIGABIT |
+ FSL_GIANFAR_DEV_HAS_COALESCE |
+ FSL_GIANFAR_DEV_HAS_RMON |
+ FSL_GIANFAR_DEV_HAS_MULTI_INTR |
+ FSL_GIANFAR_DEV_HAS_CSUM |
+ FSL_GIANFAR_DEV_HAS_VLAN |
+ FSL_GIANFAR_DEV_HAS_EXTENDED_HASH;
ph = (phandle *) get_property(np, "phy-handle", NULL);
phy = of_find_node_by_phandle(*ph);
if (phy == NULL) {
ret = -ENODEV;
- goto gfar_unreg;
+ goto unreg;
}
mdio = of_get_parent(phy);
@@ -174,7 +204,7 @@ static int __init gfar_of_init(void)
if (ret) {
of_node_put(phy);
of_node_put(mdio);
- goto gfar_unreg;
+ goto unreg;
}
gfar_data.phy_id = *id;
@@ -183,23 +213,22 @@ static int __init gfar_of_init(void)
of_node_put(phy);
of_node_put(mdio);
- ret = platform_device_add_data(gfar_dev, &gfar_data, sizeof(struct gianfar_platform_data));
+ ret =
+ platform_device_add_data(gfar_dev, &gfar_data,
+ sizeof(struct
+ gianfar_platform_data));
if (ret)
- goto gfar_unreg;
+ goto unreg;
}
return 0;
-mdio_unreg:
- platform_device_unregister(mdio_dev);
-mdio_err:
- return ret;
-
-gfar_unreg:
+unreg:
platform_device_unregister(gfar_dev);
-gfar_err:
+err:
return ret;
}
+
arch_initcall(gfar_of_init);
static int __init fsl_i2c_of_init(void)
@@ -209,17 +238,19 @@ static int __init fsl_i2c_of_init(void)
struct platform_device *i2c_dev;
int ret;
- for (np = NULL, i = 0; (np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL; i++) {
+ for (np = NULL, i = 0;
+ (np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL;
+ i++) {
struct resource r[2];
struct fsl_i2c_platform_data i2c_data;
- unsigned char * flags = NULL;
+ unsigned char *flags = NULL;
memset(&r, 0, sizeof(r));
memset(&i2c_data, 0, sizeof(i2c_data));
ret = of_address_to_resource(np, 0, &r[0]);
if (ret)
- goto i2c_err;
+ goto err;
r[1].start = np->intrs[0].line;
r[1].end = np->intrs[0].line;
@@ -228,7 +259,7 @@ static int __init fsl_i2c_of_init(void)
i2c_dev = platform_device_register_simple("fsl-i2c", i, r, 2);
if (IS_ERR(i2c_dev)) {
ret = PTR_ERR(i2c_dev);
- goto i2c_err;
+ goto err;
}
i2c_data.device_flags = 0;
@@ -240,18 +271,22 @@ static int __init fsl_i2c_of_init(void)
if (flags)
i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
- ret = platform_device_add_data(i2c_dev, &i2c_data, sizeof(struct fsl_i2c_platform_data));
+ ret =
+ platform_device_add_data(i2c_dev, &i2c_data,
+ sizeof(struct
+ fsl_i2c_platform_data));
if (ret)
- goto i2c_unreg;
+ goto unreg;
}
return 0;
-i2c_unreg:
+unreg:
platform_device_unregister(i2c_dev);
-i2c_err:
+err:
return ret;
}
+
arch_initcall(fsl_i2c_of_init);
#ifdef CONFIG_PPC_83xx
@@ -267,51 +302,52 @@ static int __init mpc83xx_wdt_init(void)
if (!np) {
ret = -ENODEV;
- goto mpc83xx_wdt_nodev;
+ goto nodev;
}
soc = of_find_node_by_type(NULL, "soc");
if (!soc) {
ret = -ENODEV;
- goto mpc83xx_wdt_nosoc;
+ goto nosoc;
}
freq = (unsigned int *)get_property(soc, "bus-frequency", NULL);
if (!freq) {
ret = -ENODEV;
- goto mpc83xx_wdt_err;
+ goto err;
}
memset(&r, 0, sizeof(r));
ret = of_address_to_resource(np, 0, &r);
if (ret)
- goto mpc83xx_wdt_err;
+ goto err;
dev = platform_device_register_simple("mpc83xx_wdt", 0, &r, 1);
if (IS_ERR(dev)) {
ret = PTR_ERR(dev);
- goto mpc83xx_wdt_err;
+ goto err;
}
ret = platform_device_add_data(dev, freq, sizeof(int));
if (ret)
- goto mpc83xx_wdt_unreg;
+ goto unreg;
of_node_put(soc);
of_node_put(np);
return 0;
-mpc83xx_wdt_unreg:
+unreg:
platform_device_unregister(dev);
-mpc83xx_wdt_err:
+err:
of_node_put(soc);
-mpc83xx_wdt_nosoc:
+nosoc:
of_node_put(np);
-mpc83xx_wdt_nodev:
+nodev:
return ret;
}
+
arch_initcall(mpc83xx_wdt_init);
#endif
^ permalink raw reply related
* Re: u-boot debugging
From: Wolfgang Denk @ 2006-01-23 22:32 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200601231032.38295.david.jander@protonic.nl>
Everybody:
*please* do not continue responding to this thread!
Stop feeding the troll!
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The software required `Windows 95 or better', so I installed Linux.
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-23 22:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 209 bytes --]
Forgot to include the lspci log. So here it comes. Sorry!
Gerhard
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: lspci.log --]
[-- Type: text/x-log; name="lspci.log", Size: 10385 bytes --]
0000:00:00.0 Host bridge: Mai Logic Incorporated Articia S Host Bridge (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 0
Region 0: Memory at <unassigned> (32-bit, prefetchable)
Capabilities: [40] AGP version 1.0
Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
0000:00:01.0 PCI bridge: Mai Logic Incorporated Articia S PCI Bridge (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
!!! Unknown I/O range types 21/20
Memory behind bridge: 88000000-880fffff
Prefetchable memory behind bridge: 80000000-87ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
0000:00:06.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 7
Region 0: I/O ports at fe802000 [size=128]
Region 1: Memory at 98100000 (32-bit, non-prefetchable) [size=128]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16
Region 4: I/O ports at fe00cc00 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 31, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at fe802080 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 31, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at fe8020a0 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.4 Non-VGA unclassified device: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 11
Region 0: I/O ports at fe802100 [size=256]
Region 1: I/O ports at fe802200 [size=4]
Region 2: I/O ports at fe802204 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 30)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 11
Region 0: I/O ports at fe802300 [size=256]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
Subsystem: Creative Labs: Unknown device 8067
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (500ns min, 5000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at fe802400 [size=32]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:09.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
Subsystem: Creative Labs Gameport Joystick
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128
Region 0: I/O ports at fe802420 [size=8]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) (prog-if 00 [VGA])
Subsystem: PC Partner Limited: Unknown device 7c13
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (2000ns min)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 80000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at fe002000 [size=256]
Region 2: Memory at 88000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 88020000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=<none>
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01)
Subsystem: PC Partner Limited: Unknown device 7c12
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min), Cache Line Size: 0x08 (32 bytes)
Region 0: Memory at 88000000 (32-bit, prefetchable)
Region 1: Memory at 88010000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
80000000-efffffff : PCI host bridge
80000000-87ffffff : PCI Bus #01
80000000-87ffffff : 0000:01:00.0
80000000-87ffffff : radeonfb framebuffer
88000000-880fffff : PCI Bus #01
88000000-8800ffff : 0000:01:00.0
88000000-8800ffff : radeonfb mmio
88010000-8801ffff : 0000:01:00.1
88020000-8803ffff : 0000:01:00.0
98100000-9810007f : 0000:00:06.0
00000000-00bfffff : PCI host bridge
00000000-0000001f : dma1
00000020-00000021 : 8259 (master)
00000040-0000005f : timer
00000060-0000006f : i8042
00000080-0000008f : dma page reg
000000a0-000000a1 : 8259 (slave)
000000c0-000000df : dma2
00000170-00000177 : ide1
000001f0-000001f7 : ide0
00000278-0000027a : parport2
0000027b-0000027f : parport2
000002f8-000002ff : serial
00000376-00000376 : ide1
00000378-0000037a : parport0
000003bc-000003be : parport1
000003c0-000003df : vga+
000003e8-000003ef : serial
000003f6-000003f6 : ide0
000003f8-000003ff : serial
000004d0-000004d1 : 8259 edge control
00002000-00002fff : PCI Bus #01
00002000-000020ff : 0000:01:00.0
0000cc00-0000cc0f : 0000:00:07.1
0000cc00-0000cc07 : ide0
0000cc08-0000cc0f : ide1
00802000-0080207f : 0000:00:06.0
00802000-0080207f : 0000:00:06.0
00802080-0080209f : 0000:00:07.2
00802080-0080209f : uhci_hcd
008020a0-008020bf : 0000:00:07.3
008020a0-008020bf : uhci_hcd
00802100-008021ff : 0000:00:07.5
00802200-00802203 : 0000:00:07.5
00802204-00802207 : 0000:00:07.5
00802300-008023ff : 0000:00:07.6
00802400-0080241f : 0000:00:09.0
00802400-0080241f : EMU10K1
00802420-00802427 : 0000:00:09.1
00802420-00802427 : emu10k1-gp
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-23 22:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1137883724.12998.74.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Sun, 22 Jan 2006 09:48:44 +1100
>
> On Sat, 2006-01-21 at 02:59 +0100, Gerhard Pircher wrote:
>
> > Yes, I see. :( The code mostly allocates the resources for the AGPGART
> > driver beyond the real memory space, thus preventing the X server to
> > work. Sometimes the resource is also mapped to where the resource of
> > the graphic card resides (address 0x88000000, compare with the included
> > iomem file).
>
> The AGP aperture should generally be located "outside" of those spaces.
> That is above RAM and in some place where no device already resides...
> It can be made to overlap RAM but that isn't a good idea (that's what
> happens on Macs though due to a bug in the Apple chipset).
Ahh, so the AGP aperture should not be within the memory space and any other
PCI/IO address range. Slowly but surely I become confused. ;-)
> I don't see anything related to AGP in your output... you didn't post
> the lspci as root thus it's missing all the useful infos ;)
I included a new lspci output log. :-) (now done as root)
> Also, the AGP base isn't generally a PCI BAR of the bridge... it is one
> in your case ?
I'm afraid I can't answer this question (you know, we have no datasheet for
the ArticiaS yet). From what I can see in the log, there is an unassigned
memory region (type 0, should be <4GB I guess). Could this affect AGP
operation?
Gerhard
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
^ permalink raw reply
* Re: [PATCH 001/001 Updated] PMAC HD runtime blinking control
From: Cedric Pradalier @ 2006-01-23 21:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev
In-Reply-To: <1138024037.4907.24.camel@localhost.localdomain>
According to Benjamin Herrenschmidt, on Tue, 24 Jan 2006
00:47:16 +1100,
>> The key I could not understand was that hwif->gendev is
>> only initialised in the probe. So I had to move the
>> device creation after that.
>>
>> Currently, it is blinking by default. Should it be that
>> way? I guess so, since it is activated by a kernel config
>> option. It is easy to change if required.
>
>Yes. In fact, by enabled default for ATA disks and by disabled for ATAPI
>would make sense...
How do I tell the difference?. There is a 'kind' in pmif,
and also a atapi_dma flag in hwif. Which is more sensible?
>
>Also, we should think a bit about the file name... "blinking_led" isn't
>terrific for something that will end up in a non-ppc specific location.
>Or maybe on the contrary it's good ... what about "activity_led"
>rather ?
>
I'm open to any suggestion. I'll wait a bit to see if
someone else has a comment, then I'll change to
"activity_led".
--
Cedric
^ permalink raw reply
* Re: [PATCH 4/9] Migrate ML300 reference design to the platform bus
From: Grant Likely @ 2006-01-23 21:13 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <43D5130E.2020404@ru.mvista.com>
Andrei Konovalov wrote:
> Hi Grant,
>
> Grant C. Likely wrote:
>
>> Signed-off-by: Grant C. Likely <grant.likely@secretlab.ca>
>>
>> ---
>>
>> arch/ppc/Kconfig.debug | 2 -
>> arch/ppc/platforms/4xx/xilinx_ml300.c | 74
>> +++++++++++++++++++++++----------
>> arch/ppc/platforms/4xx/xilinx_ml300.h | 2 -
>> arch/ppc/syslib/Makefile | 2 -
>> 4 files changed, 55 insertions(+), 25 deletions(-)
>
>
> <snip>
>
>> +/* Board specifications structures */
>> +struct ppc_sys_spec *cur_ppc_sys_spec;
>> +struct ppc_sys_spec ppc_sys_specs[] = {
>> + {
>> + /* Only one entry, always assume the same design */
>> + .ppc_sys_name = "Xilinx ML300 Reference Design",
>> + .mask = 0x00000000,
>> + .value = 0x00000000,
>
>
> "Always assume the same design" could be a considerable limitation
> for the Virtex FPGAs.
>
> <snip>
>
>> @@ -131,6 +159,8 @@ platform_init(unsigned long r3, unsigned
>> {
>> ppc4xx_init(r3, r4, r5, r6, r7);
>>
>> + identify_ppc_sys_by_id(mfspr(SPRN_PVR));
>
>
> This is OK for the single ppc_sys_specs[] case, but in general
> I am not sure using PVR to identify the system makes much sense
> in case of Virtex FPGAs. IIRC, for the mpc8xxx Freescale SOCs PVR
> gives enough information to determine what on-chip peripherals are
> present (but not how multi-function peripherals like SCC are configured).
> In case of Xilinx the situation is worse: depending on the bitstream
> loaded into the FPGA, the same chip (the same PVR) and the board
> can have several sets of on-chip peripherals which could be completely
> different from each other. And knowing the PVR value alone puts no
> limitation
> on what peripherals could get into the FPGA (unless e.g. a Virtex-4
> specific
> hardware block is used by an IP - like in case of TEMAC).
>
> What do you think?
In short; I agree 100%. There are also some other issues with the way I
set things up. The only reason I used the ppc_sys functions was because
the other freescale ports used them. (It seemed like a good starting
point). I now thing platform devices should be registered directly by
the board setup code (or flattened-device-tree parser); just like your
code below.
> So far I've used a fairly dumb code like:
>
> static int __init xilinx_platform_init(void)
> {
> #ifdef XPAR_EMAC_0_BASEADDR
> memcpy(xemac_0_pdata.mac_addr, __res.bi_enetaddr, 6);
> platform_device_register(&xilinx_emac_0_device);
> #endif /* XPAR_EMAC_0_BASEADDR */
>
> #ifdef XPAR_TEMAC_0_BASEADDR
> memcpy(xtemac_0_pdata.mac_addr, __res.bi_enetaddr, 6);
> platform_device_register(&xilinx_temac_0_device);
> #endif /* XPAR_TEMAC_0_BASEADDR */
>
> #ifdef XPAR_TFT_0_BASEADDR
> platform_device_register(&xilinx_lcd_0_device);
> #endif /* XPAR_TFT_0_BASEADDR */
>
> #ifdef XPAR_GPIO_0_BASEADDR
> platform_device_register(&xilinx_gpio_0_device);
> #endif /* XPAR_GPIO_0_BASEADDR */
> #ifdef XPAR_GPIO_1_BASEADDR
> platform_device_register(&xilinx_gpio_1_device);
> #endif /* XPAR_GPIO_1_BASEADDR */
>
> #ifdef XPAR_PS2_0_BASEADDR
> platform_device_register(&xilinx_ps2_0_device);
> #endif /* XPAR_PS2_0_BASEADDR */
> #ifdef XPAR_PS2_1_BASEADDR
> platform_device_register(&xilinx_ps2_1_device);
> #endif /* XPAR_PS2_1_BASEADDR */
>
> return 0;
> }
>
> - to associate the devices to the drivers (the drivers
> call driver_register() from their module_init function).
> This helps me holding all that ugly stuff in one file
> (this single file can be used by multiple boards),
> and should make it easier to switch to something using
> the flattened device tree parsing when the OF DT comes
> into play.
yes; plus the flattened tree parser can allocate platform device
structures as needed at runtime.
>
> Probably using ppc_sys infrastructure now has some advantages,
> but they are not evident to me.
No, I don't really think it fits for the Virtex either; I'm just using
it as a starting point.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Problem getting code from git repository
From: Marty @ GMail @ 2006-01-23 20:56 UTC (permalink / raw)
To: linuxppc-embedded
V2hlbiBJIGF0dGVtcHQgdG8gcmV0cmlldmUgdGhlIGN1cnJlbnQgc291cmNlIGZyb20gdGhlIGdp
dCByZXBvc2l0b3J5CkkgZ2V0IHRoZSBmb2xsb3dpbmcKCkFueSBzdWdnZXN0aW9ucyA/Pz8gIE1h
cnRpbgoKCgp3ZWRlcG9obEB1YnVudHU6L29wdC9lbGRrL3BwY182eHgvdXNyL3NyYyQgY2ctY2xv
bmUKaHR0cDovL3d3dy5kZW54LmRlL2dpdC9saW51eC0yLjYtZGVueC5naXQgbGludXgtMi42LWRl
bnguZ2l0LwpkZWZhdWx0aW5nIHRvIGxvY2FsIHN0b3JhZ2UgYXJlYQoxMzoyMzo1NSBVUkw6aHR0
cDovL3d3dy5kZW54LmRlL2dpdC9saW51eC0yLjYtZGVueC5naXQvcmVmcy9oZWFkcy9tYXN0ZXIK
WzQxLzQxXSAtPiAicmVmcy9oZWFkcy9vcmlnaW4iIFsxXQplcnJvcjogRmlsZSAxYzA2Y2Y1YTk4
NTFhODM0OTNmNWI1ZjM3NDliNGNlZDRlMDdhZjI5CihodHRwOi8vd3d3LmRlbnguZGUvZ2l0L2xp
bnV4LTIuNi1kZW54LmdpdC9vYmplY3RzLzFjLzA2Y2Y1YTk4NTFhODM0OTNmNWI1ZjM3NDliNGNl
ZDRlMDdhZjI5KQpjb3JydXB0CgpDYW5ub3Qgb2J0YWluIG5lZWRlZCBjb21taXQgMWMwNmNmNWE5
ODUxYTgzNDkzZjViNWYzNzQ5YjRjZWQ0ZTA3YWYyOQp3aGlsZSBwcm9jZXNzaW5nIGNvbW1pdCAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLgplcnJvcjogY2Fubm90IG1h
cCBzaGExIGZpbGUgMWMwNmNmNWE5ODUxYTgzNDkzZjViNWYzNzQ5YjRjZWQ0ZTA3YWYyOQpjZy1w
dWxsOiBvYmplY3RzIHB1bGwgZmFpbGVkCmNnLWluaXQ6IHB1bGwgZmFpbGVkCndlZGVwb2hsQHVi
dW50dTovb3B0L2VsZGsvcHBjXzZ4eC91c3Ivc3JjJAo=
^ permalink raw reply
* RE: u-boot debugging
From: sri.dharmasanam @ 2006-01-23 18:42 UTC (permalink / raw)
To: albert.david, linuxppc-embedded
I agree that there was no need to take things personally here. Perhaps =
the reader didn't understand what oxymoron meant.
Debug tools is often a hotly disputed issue and it would have been nice =
to hear more thoughts (technical and business related) on a forum such =
as this.
Regards,
_Sri
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Albert David
Sent: Sunday, January 22, 2006 2:11 AM
To: linuxppc-embedded@ozlabs.org
Subject: u-boot debugging
>> On Friday 20 January 2006 08:00 pm, AtulAtulhSabharwalte:
>> > First learn to communicate in English. I can give you 25 Us
>> cents as I
>> > cannot afford 1 Mark. You are not work even a Mark.
>>
>> The complete lack of civility in this remark is inexcusable in
>> a public forum.
>> Herr DenkDenk provided an incredibly valuable service to the
>> community, and
>> deserves more respect than this.
>I agree whole heartily Glenn...
glenn and frank,
even me too! i agree with you.
Best regards,
Albert David.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 4/9] Migrate ML300 reference design to the platform bus
From: Andrei Konovalov @ 2006-01-23 17:31 UTC (permalink / raw)
To: Grant C. Likely; +Cc: linuxppc-embedded
In-Reply-To: <20060119081303.GA24908@weasley-twins.secretlab.ca>
Hi Grant,
Grant C. Likely wrote:
> Signed-off-by: Grant C. Likely <grant.likely@secretlab.ca>
>
> ---
>
> arch/ppc/Kconfig.debug | 2 -
> arch/ppc/platforms/4xx/xilinx_ml300.c | 74 +++++++++++++++++++++++----------
> arch/ppc/platforms/4xx/xilinx_ml300.h | 2 -
> arch/ppc/syslib/Makefile | 2 -
> 4 files changed, 55 insertions(+), 25 deletions(-)
<snip>
> +/* Board specifications structures */
> +struct ppc_sys_spec *cur_ppc_sys_spec;
> +struct ppc_sys_spec ppc_sys_specs[] = {
> + {
> + /* Only one entry, always assume the same design */
> + .ppc_sys_name = "Xilinx ML300 Reference Design",
> + .mask = 0x00000000,
> + .value = 0x00000000,
"Always assume the same design" could be a considerable limitation
for the Virtex FPGAs.
<snip>
> @@ -131,6 +159,8 @@ platform_init(unsigned long r3, unsigned
> {
> ppc4xx_init(r3, r4, r5, r6, r7);
>
> + identify_ppc_sys_by_id(mfspr(SPRN_PVR));
This is OK for the single ppc_sys_specs[] case, but in general
I am not sure using PVR to identify the system makes much sense
in case of Virtex FPGAs. IIRC, for the mpc8xxx Freescale SOCs PVR
gives enough information to determine what on-chip peripherals are
present (but not how multi-function peripherals like SCC are configured).
In case of Xilinx the situation is worse: depending on the bitstream
loaded into the FPGA, the same chip (the same PVR) and the board
can have several sets of on-chip peripherals which could be completely
different from each other. And knowing the PVR value alone puts no limitation
on what peripherals could get into the FPGA (unless e.g. a Virtex-4 specific
hardware block is used by an IP - like in case of TEMAC).
What do you think?
So far I've used a fairly dumb code like:
static int __init xilinx_platform_init(void)
{
#ifdef XPAR_EMAC_0_BASEADDR
memcpy(xemac_0_pdata.mac_addr, __res.bi_enetaddr, 6);
platform_device_register(&xilinx_emac_0_device);
#endif /* XPAR_EMAC_0_BASEADDR */
#ifdef XPAR_TEMAC_0_BASEADDR
memcpy(xtemac_0_pdata.mac_addr, __res.bi_enetaddr, 6);
platform_device_register(&xilinx_temac_0_device);
#endif /* XPAR_TEMAC_0_BASEADDR */
#ifdef XPAR_TFT_0_BASEADDR
platform_device_register(&xilinx_lcd_0_device);
#endif /* XPAR_TFT_0_BASEADDR */
#ifdef XPAR_GPIO_0_BASEADDR
platform_device_register(&xilinx_gpio_0_device);
#endif /* XPAR_GPIO_0_BASEADDR */
#ifdef XPAR_GPIO_1_BASEADDR
platform_device_register(&xilinx_gpio_1_device);
#endif /* XPAR_GPIO_1_BASEADDR */
#ifdef XPAR_PS2_0_BASEADDR
platform_device_register(&xilinx_ps2_0_device);
#endif /* XPAR_PS2_0_BASEADDR */
#ifdef XPAR_PS2_1_BASEADDR
platform_device_register(&xilinx_ps2_1_device);
#endif /* XPAR_PS2_1_BASEADDR */
return 0;
}
- to associate the devices to the drivers (the drivers
call driver_register() from their module_init function).
This helps me holding all that ugly stuff in one file
(this single file can be used by multiple boards),
and should make it easier to switch to something using
the flattened device tree parsing when the OF DT comes
into play.
Probably using ppc_sys infrastructure now has some advantages,
but they are not evident to me.
Thanks,
Andrei
^ permalink raw reply
* Trouble with SMC serial port in ppc/boot/simple on Embedded Planet 8248 board
From: Laurent Pinchart @ 2006-01-23 16:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm trying to port the Linux kernel (2.6.15.1) to the Embedded Planet 8248
board. The board has a proprietary boot loader and uses SMC1 has a serial
console.
After some work (2.6.15.1 has a nasty bug related to relocation which has been
fixed in the git tree), I have been able to load and start the kernel image.
Unfortunately, the early serial output is lost. Here is the kernel boot
messages I get with 2.6.15.1 :
-----------------------------------------------------------------------------
Embedded Planet EP8248 PowerPC port
Built 1 zonelists
Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram0 rw
PID hash table entries: 4096 (order: 12, 65536 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 777088k available (1520k kernel code, 440k data, 96k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
-----------------------------------------------------------------------------
And here is the same with the modified 2.6.10-pre3 kernel shipped with the
board:
-----------------------------------------------------------------------------
loaded at: 00200000 002D01E8
relocated to: 00400000 004D01E8
board data at: 004CE12C 004CE168
relocated to: 0040509C 004050D8
zimage at: 00405A31 004CD2C4
avail ram: 004D1000 01000000
Linux/PPC load: console=ttyCPM0,9600n8 root=/dev/ram0 rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.10-rc3 (laurent@pclaurent) (gcc version 3.4.1) #5 Thu Jan 19
15:25:42 CET 2006
Embedded Planet EP8248 PowerPC port
Built 1 zonelists
[...]
-----------------------------------------------------------------------------
Early boot messages (printed with puts in ppc/boot/simple/misc-embedded.c) are
lost.
I compared the Embedded Planet kernel with the 2.6.10-rc3 from kernel.org,
haven't seen any big change related to the SMC serial port. Embedded Planet
uses BRGC7 instead of BRGC1 for SMC1, but that didn't work better for me.
I of course enabled the RS232 transceivers in the board control and status
registers (BCSR).
Could anyone give me any pointer to where I should look at ?
Thanks in advance,
Laurent Pinchart
^ permalink raw reply
* Registers read-only
From: Moloko Vellocet @ 2006-01-23 15:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi, I'm writing a driver to manage the serial communication in a
MPC5200 board, but the interrupt I don't have obtained the call to
interrupt routine, I've configured the registers in the initialization
code as the following:
#define REG_MBAR MPC5xxx_MBAR
#define REG_BASE_PSC MPC5xxx_PSC3
#define REG_CR (REG_BASE_PSC + 0x08)
#define REG_RXTX (REG_BASE_PSC + 0x0C)
#define REG_IMR (REG_BASE_PSC + 0x14)
#define REG_SICR (REG_BASE_PSC + 0x40)
#define REG_RFALARM (REG_BASE_PSC + 0x6E)
#define REG_TFALARM (REG_BASE_PSC + 0x8E)
outb(0x0A, REG_CR);
wmb();
printk("REG_CR=3D%x\n", inb(REG_CR));
rmb();
outb(0x221000, REG_SICR);
wmb();
printk("REG_SICR=3D%x\n", inb(REG_SICR));
rmb();
outb(0x0004, REG_RFALARM);
wmb();
printk("REG_RFALARM=3D%x\n", inb(REG_RFALARM));
rmb();
outb(0x0004, REG_TFALARM);
wmb();
printk("REG_TFALARM=3D%x\n", inb(REG_TFALARM));
rmb();
outb(0x00000300, REG_IMR);
wmb();
printk("REG_IMR=3D%x\n", inb(REG_IMR));
rmb();
I'm getting always:
REG_CR=3D0
REG_SICR=3D0
REG_RFALARM=3D0
REG_TFALARM=3D0
REG_IMR=3D0
I have to configure 'port config' register doing a 'or' with the
actual value in the register, but I can't get the values contained in
the registers. Are the register write-only.
I've registered the following interrupts:
if ((err =3D request_irq(MPC5xxx_IR_RX_IRQ, /*RX_IRQ_NUMBER,*/
interrupt_handler,
SA_INTERRUPT,
DEVICE_NAME,
NULL)) < 0)
goto fail_rx_req_irq;
if ((err =3D request_irq(MPC5xxx_IR_TX_IRQ, /*TX_IRQ_NUMBER,*/
interrupt_handler_tx,
SA_INTERRUPT,
DEVICE_NAME,
NULL)) < 0)
goto fail_tx_req_irq;
But the interrupts are not activated when I execute a ioctl to the
board the interrupt handler are not called.
Does anyone know the problem with this code?
--
_______________________________
Allann J. O. Silva
Genius Instituto de Tecnologia
Tel.:+55 (92) 3614-6586
www.genius.org.br
_______________________________
"I received the fundamentals of my education in school, but that was
not enough. My real education, the superstructure, the details, the
true architecture, I got out of the public library. For an
impoverished child whose family could not afford to buy books, the
library was the open door to wonder and achievement, and I can never
be sufficiently grateful that I had the wit to charge through that
door and make the most of it." (from I. Asimov, 1994)
^ permalink raw reply
* [PATCH] powerpc: Fix sigmask handling in sys_sigsuspend.
From: Heiko Carstens @ 2006-01-23 12:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, David Woodhouse, linux-kernel
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Better save the sigmask instead of throwing it away so it can be restored.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
Completely untested. Just noticed this when adding TIF_RESTORE_SIGMASK
support for s390.
arch/powerpc/kernel/signal_32.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 3747ab0..c6d0595 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -254,11 +254,9 @@ int do_signal(sigset_t *oldset, struct p
*/
long sys_sigsuspend(old_sigset_t mask)
{
- sigset_t saveset;
-
mask &= _BLOCKABLE;
spin_lock_irq(¤t->sighand->siglock);
- saveset = current->blocked;
+ current->saved_sigmask = current->blocked;
siginitset(¤t->blocked, mask);
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
^ permalink raw reply related
* Re: u-boot debugging
From: Atul Sabharwal @ 2006-01-23 14:10 UTC (permalink / raw)
To: Albert David, linuxppc-embedded
In-Reply-To: <61124de70601220210i718fbc9cm85cdd282e739555e@mail.gmail.com>
>>Herr DenkDenk provided an incredibly valuable service to the
>>community, and deserves more respect than this.
I agree with the latter but he cannot insult others to retain his sphere
of influence... And read my other e-mail which describes the main
problem... Its easy to join a band wagon but be sure if you are on the
right train. Not sinulting Wolf but I had to resort to this approach to
explain the insult in his remark. Besides, as usual, lot of people have
short memories. They dont scan the entire e-mail thread to see where
the e-mail chain went wrong. Who instigated the whole insult cycle.
And for the record, I did not insult wolf. He insulted me. I just humor
& ridicule to convey my across. Rest is your interpretation...
--
Atul
----- Original Message -----
From: "Albert David" <albert.david@gmail.com>
To: <linuxppc-embedded@ozlabs.org>
Sent: Sunday, January 22, 2006 2:10 AM
Subject: u-boot debugging
>> On Friday 20 January 2006 08:00 pm, AtulAtulhSabharwalte:
>> > First learn to communicate in English. I can give you 25 Us
>> cents as I
>> > cannot afford 1 Mark. You are not work even a Mark.
>>
>> The complete lack of civility in this remark is inexcusable in
>> a public forum.
>> Herr DenkDenk provided an incredibly valuable service to the
>> community, and
>> deserves more respect than this.
>I agree whole heartily Glenn...
glenn and frank,
even me too! i agree with you.
Best regards,
Albert David.
^ permalink raw reply
* Re: u-boot debugging
From: Atul Sabharwal @ 2006-01-23 13:44 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
In-Reply-To: <200601231032.38295.david.jander@protonic.nl>
> I detect an increasing amount of resentment in your words, and that is not
> good as far as my experience goes...
This is true... I have had quite a few bad experiences with open source
product.
e.g. RH 6.2 the loop back driver would flush data to the driver every second
time.
People at work would change compiler, graphic settings on me... Swap ln
commnad
options.... crack linux md5 passwords... break gid/uid settings... steal
my linux CD
roms... This happened to me at my ex-employer for about 2.5 years for
sure...
6 years in total (on my windows box with USB scanner, printers, boot sector
crashes,
file/pdf corruption... Besides the usual of getting SPAM, virus, trojans
etc... The latter
is okay but the rest is strange... ). Now when you are on a schedule
deadline, how many
bugs can one fix... Code which runs on one day does not on another day...
Its like
somebody (internally) is trying to sabotage my project or changing code
without knowing
what they are doing... They could be doing this just to get rid of me
either (which I dont
know ) as I dont know *who*. In the past, I used to just take my network
cable off and
not be bothered with personal backups but on a shared network with clearcase
I cant
go offline. Cannot upgrade from 9.0 to Fedora... Each day, there are
different problems
with the machine...
So, this is the prime basis of resentment in my words. Its kind of happening
again.
There are routines in u-boot e.g. cpu_post_exec_02 and cpu_post_exec_04
which use a
stackless approach to copy a function to a given address, execute them and
pass the values
back to the calling app. It was working the other day and now its not. I
test the first instruction
it has to execute and it was supposed to be 0x38000000 and it shows as
0x38000331. I mentioned
it to my peer and next day its different. I dont like hidden resources on
my project but dont know
if I should ask ? If its by design or by coincidence... Generally hidden
resources(unless very skilled
& dillignet) cause more harm than help...
I am not sure about gdb protocol support for Metrowerks but it should be an
easy extension. Just
like changing the Phy on BDI should be easy change. Not sure if it has a
FPGA or ASIC or some
controller driving the JTAG chain. JTAG on BDI (is probably 12 or 16MHz) so
its faster than
a 10Mbps ethernet link. They were just saving cost as JTAG chain
address/data cycles are long
so one wont get a full 10MHz data transfer. JTAG by itself can go to 40MHz
so, the next rev of
BDI can go with a faster JTAG chain and 100Mbps link or a USB link.
Advantages of Metwerks so far :
1. Comes with the reference board from Freescale with 1 month license.
2. I did not get any help from BDI to setup the config file for 870/885
processor.
3. BDI did not program the AMD 29F style flash part.
4. BDI does not program the micro IC chip on Xscale. If one wants to debug
loadable modules
using BDI it did not happen as it does before mounting the initial ram
disk. Seemed like
a VECTOR LO/HIGH problem which their FAE did not or was not willing to
explain. Too much
pain for the effort required to resolve the problem with external
folks...
5. On 8540, the BDI only worked with single stepping or running to a break
point 5-10 instructions
away. Not sure what was the problem as I had to relocate the entire
U-boot code to run from
a pre-init DDR RAM instead of a swizzled flash in 5-7 days with no PPC
experience. Just schedule
pressure becuase of lack of planning on other people's part. On top of
that, the mgmt wanted me to
limit hours. Not sure if to keep me less stressed or just be cheap!!
6. Based on the above experience with BDI, I recommended Metrowerks. On my
project, one of
the reference board was busted. We could not get it fixed. Each board
was $2.5K each but they
were useless. The software CD ROM was erased by someone (which had all
the manuals).
Somebody broke into my car and started smoking ciggerettes.
So, what should I say. How far can one complain. I just told the
psychologist that someone is giving me
a hard time. Its definitely not any disorder.... Generally as engineer, we
can differentiate between a
bug a feature and a hack. When a hack (or a hacker) is trying to hinder
your progress or cause grief
or spoof a website so that you have wrong u-boot code, the individual is in
trouble. Based on probability,
its usually somone from the inside who changes code, crashes your
CVS/clearcase or modifies code
without a trace(perfect bug fix or hack by clearing logs or buffer underrun
problem to hack). The cable
off solution along with shutting down all the server apps was an easy
solution as the kernel is not listening
to sockets (since http server is gone from 2.4 kernel). And if the site is
spoofed, its usually your area ISP who can help. (e.g. if you google for
u-boot on source forge you only get u-boot 1.0.0 and if you access the site
directly, you get access to 1.1.2 & 1.1.3). Thats the main reason for the
resentment.
Now, all one can do in these situations is complain. Now if the complain
falls on deaf ears, what more can
you do. Typical answer is that you are working too hard. But this is an
easy forced attrition method.
So, now if processors have a wireless link, forced attrition would be a
common problem.
And I am still objective. Wolf does not maintain the sourceforge site. He
is just the moderator or main
contributor. And we are not using VPN's globally to reduce spoof web site
problem as many open source
projects could have excess bugs in them...
--
Atul
^ permalink raw reply
* Re: [PATCH 001/001 Updated] PMAC HD runtime blinking control
From: Benjamin Herrenschmidt @ 2006-01-23 13:47 UTC (permalink / raw)
To: Cedric Pradalier; +Cc: Linuxppc-dev, debian-powerpc
In-Reply-To: <20060123233823.3f0dbad5.cedric.pradalier@inrialpes.fr>
> The key I could not understand was that hwif->gendev is
> only initialised in the probe. So I had to move the
> device creation after that.
>
> Currently, it is blinking by default. Should it be that
> way? I guess so, since it is activated by a kernel config
> option. It is easy to change if required.
Yes. In fact, by enabled default for ATA disks and by disabled for ATAPI
would make sense...
Also, we should think a bit about the file name... "blinking_led" isn't
terrific for something that will end up in a non-ppc specific location.
Or maybe on the contrary it's good ... what about "activity_led"
rather ?
> Anyway, here is the updated patch.
>
> signed-off-by: Cedric Pradalier <cedric.pradalier@free.fr>
> ---
> --- drivers/ide/ppc/pmac.c.orig 2006-01-03 13:21:10.000000000 +1000
> +++ drivers/ide/ppc/pmac.c 2006-01-23 23:32:18.000000000 +1000
> @@ -36,6 +36,11 @@
> #include <linux/pmu.h>
> #include <linux/scatterlist.h>
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> +#include <linux/device.h>
> +#include <asm/of_device.h>
> +#endif
> +
> #include <asm/prom.h>
> #include <asm/io.h>
> #include <asm/dbdma.h>
> @@ -427,6 +432,15 @@ static void pmac_ide_kauai_selectproc(id
>
> #ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
>
> +MODULE_AUTHOR("Paul Mackerras & Ben. Herrenschmidt");
> +MODULE_DESCRIPTION("Support for IDE interfaces on PowerMacs");
> +MODULE_LICENSE("GPL");
> +
> +static int blinking_led = 1;
> +module_param_named(noblink,blinking_led, invbool, 0666);
> +MODULE_PARM_DESC(noblink,"Enable/Disable blinking led [Default: enabled]");
> +
> +
> /* Set to 50ms minimum led-on time (also used to limit frequency
> * of requests sent to the PMU
> */
> @@ -437,8 +451,7 @@ static spinlock_t pmu_blink_lock;
> static unsigned long pmu_blink_stoptime;
> static int pmu_blink_ledstate;
> static struct timer_list pmu_blink_timer;
> -static int pmu_ide_blink_enabled;
> -
> +static int pmu_ide_blink_enabled = 0;
>
> static void
> pmu_hd_blink_timeout(unsigned long data)
> @@ -468,6 +481,8 @@ static void
> pmu_hd_kick_blink(void *data, int rw)
> {
> unsigned long flags;
> + if (!blinking_led)
> + return;
>
> pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
> wmb();
> @@ -483,6 +498,26 @@ pmu_hd_kick_blink(void *data, int rw)
> spin_unlock_irqrestore(&pmu_blink_lock, flags);
> }
>
> +static ssize_t show_blinkingled_activity(struct device *dev, struct device_attribute *attr, char *buf)\
> +{
> + return sprintf(buf, "%c\n", blinking_led?'1':'0');
> +}
> +
> +static ssize_t set_blinkingled_activity(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int blink;
> + if (sscanf (buf, "%d", &blink) != 1)
> + return -EINVAL;
> + blinking_led = (blink != 0);
> + printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
> + blinking_led?"enabled":"disabled");
> + return count;
> +}
> +
> +static DEVICE_ATTR (blinking_led, S_IRUGO | S_IWUSR,
> + show_blinkingled_activity, set_blinkingled_activity);
> +
> static int
> pmu_hd_blink_init(void)
> {
> @@ -516,6 +551,9 @@ pmu_hd_blink_init(void)
> init_timer(&pmu_blink_timer);
> pmu_blink_timer.function = pmu_hd_blink_timeout;
>
> + printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
> + blinking_led?"enabled":"disabled");
> +
> return 1;
> }
>
> @@ -1271,7 +1309,7 @@ static int
> pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
> {
> struct device_node *np = pmif->node;
> - int *bidp, i;
> + int *bidp;
>
> pmif->cable_80 = 0;
> pmif->broken_dma = pmif->broken_dma_warn = 0;
> @@ -1401,6 +1439,12 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
> /* We probe the hwif now */
> probe_hwif_init(hwif);
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> + /* We wait till here to have the gendev initialized in hwif */
> + device_create_file (&hwif->gendev, &dev_attr_blinking_led);
> +#endif
> +
> +
> return 0;
> }
>
^ permalink raw reply
* [PATCH 001/001 Updated] PMAC HD runtime blinking control
From: Cedric Pradalier @ 2006-01-23 13:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev, debian-powerpc
In-Reply-To: <1137898193.12998.83.camel@localhost.localdomain>
According to Benjamin Herrenschmidt, on Sun, 22 Jan 2006
13:49:53 +1100,
>On Sun, 2006-01-22 at 12:19 +1000, Cedric Pradalier wrote:
>> Hi,
>>
>> I've finally spend the time to mend the patch for control of
>> the HD led blinking at runtime. This is a patch against
>> 2.6.15
>>
>> The sysfs entry is attached to the PCI device and to the
>> MACIO device if available. I think that was what Ben was
>> asking for:
>
>Heh, nice :) Almost ! It would be better if it was attached to the sysfs
>node of the ide interface, you can find it in the HWIF array after
>probe, but I won't be too much of a pain about that for now :)
>
>Ben.
>
>
OK, I think now I got it.
pradalie@lauren-ph:~$ find /sys/ | grep blink
/sys/devices/pci0001:10/0001:10:17.0/0.80000000:mac-io/0.0001f000:ata-4/ide0/blinking_led
The key I could not understand was that hwif->gendev is
only initialised in the probe. So I had to move the
device creation after that.
Currently, it is blinking by default. Should it be that
way? I guess so, since it is activated by a kernel config
option. It is easy to change if required.
Anyway, here is the updated patch.
signed-off-by: Cedric Pradalier <cedric.pradalier@free.fr>
---
--- drivers/ide/ppc/pmac.c.orig 2006-01-03 13:21:10.000000000 +1000
+++ drivers/ide/ppc/pmac.c 2006-01-23 23:32:18.000000000 +1000
@@ -36,6 +36,11 @@
#include <linux/pmu.h>
#include <linux/scatterlist.h>
+#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+#include <linux/device.h>
+#include <asm/of_device.h>
+#endif
+
#include <asm/prom.h>
#include <asm/io.h>
#include <asm/dbdma.h>
@@ -427,6 +432,15 @@ static void pmac_ide_kauai_selectproc(id
#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+MODULE_AUTHOR("Paul Mackerras & Ben. Herrenschmidt");
+MODULE_DESCRIPTION("Support for IDE interfaces on PowerMacs");
+MODULE_LICENSE("GPL");
+
+static int blinking_led = 1;
+module_param_named(noblink,blinking_led, invbool, 0666);
+MODULE_PARM_DESC(noblink,"Enable/Disable blinking led [Default: enabled]");
+
+
/* Set to 50ms minimum led-on time (also used to limit frequency
* of requests sent to the PMU
*/
@@ -437,8 +451,7 @@ static spinlock_t pmu_blink_lock;
static unsigned long pmu_blink_stoptime;
static int pmu_blink_ledstate;
static struct timer_list pmu_blink_timer;
-static int pmu_ide_blink_enabled;
-
+static int pmu_ide_blink_enabled = 0;
static void
pmu_hd_blink_timeout(unsigned long data)
@@ -468,6 +481,8 @@ static void
pmu_hd_kick_blink(void *data, int rw)
{
unsigned long flags;
+ if (!blinking_led)
+ return;
pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
wmb();
@@ -483,6 +498,26 @@ pmu_hd_kick_blink(void *data, int rw)
spin_unlock_irqrestore(&pmu_blink_lock, flags);
}
+static ssize_t show_blinkingled_activity(struct device *dev, struct device_attribute *attr, char *buf)\
+{
+ return sprintf(buf, "%c\n", blinking_led?'1':'0');
+}
+
+static ssize_t set_blinkingled_activity(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int blink;
+ if (sscanf (buf, "%d", &blink) != 1)
+ return -EINVAL;
+ blinking_led = (blink != 0);
+ printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
+ blinking_led?"enabled":"disabled");
+ return count;
+}
+
+static DEVICE_ATTR (blinking_led, S_IRUGO | S_IWUSR,
+ show_blinkingled_activity, set_blinkingled_activity);
+
static int
pmu_hd_blink_init(void)
{
@@ -516,6 +551,9 @@ pmu_hd_blink_init(void)
init_timer(&pmu_blink_timer);
pmu_blink_timer.function = pmu_hd_blink_timeout;
+ printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
+ blinking_led?"enabled":"disabled");
+
return 1;
}
@@ -1271,7 +1309,7 @@ static int
pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
{
struct device_node *np = pmif->node;
- int *bidp, i;
+ int *bidp;
pmif->cable_80 = 0;
pmif->broken_dma = pmif->broken_dma_warn = 0;
@@ -1401,6 +1439,12 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
/* We probe the hwif now */
probe_hwif_init(hwif);
+#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+ /* We wait till here to have the gendev initialized in hwif */
+ device_create_file (&hwif->gendev, &dev_attr_blinking_led);
+#endif
+
+
return 0;
}
^ permalink raw reply
* Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach
From: Ben Collins @ 2006-01-23 13:12 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, linux-kernel, Adrian Bunk, linuxppc-dev, Olaf Hering
In-Reply-To: <s5hd5ijyw2q.wl%tiwai@suse.de>
On Mon, 2006-01-23 at 13:20 +0100, Takashi Iwai wrote:
> > > > > Can someone from the ppc developers drop me a small note whether
> > > > > SND_POWERMAC completely replaces DMASOUND_PMAC?
> > > >
> > > > It doesnt. Some tumbler models work only after one plug/unplug cycle of
> > > > the headphone. early powerbooks report/handle the mute settings
> > > > incorrectly. there are likely more bugs.
> > >
> > > Interesting... Ben Collins hacked something to have Toonie work as a
> > > "default" driver for non supported machine and saw that problem too, I
> > > think he fixes it, I'll check with him what's up there and if his fix
> > > applied to tumbler.c as well.
> >
> > My "fix" was basically the result of converting to the platform
> > functions. It's hit or miss whether this works with tumbler too.
> >
> > You can try the Ubuntu kernel packages (they can be unpacked and used on
> > non Ubuntu systems pretty easily) to see if it works for you. Tumbler
> > platform function conversion isn't even tested, so I'd be happy to hear
> > any feedback.
>
> Don't forget to forward your patches to alsa-devel or me ;)
I'm passing everything through to BenH, especially since it's all using
functions new in his ppc tree.
Update on this "fix", it worked only because platform function
interrupts weren't enabled. Now that they are, it's back to the same old
thing.
At least that's a clue, though.
--
Ben Collins
Kernel Developer - Ubuntu Linux
^ permalink raw reply
* Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach
From: Takashi Iwai @ 2006-01-23 12:20 UTC (permalink / raw)
To: Ben Collins
Cc: alsa-devel, Ben Collins, linux-kernel, Adrian Bunk, linuxppc-dev,
Olaf Hering
In-Reply-To: <1137799330.13530.30.camel@grayson>
At Fri, 20 Jan 2006 18:22:10 -0500,
Ben Collins wrote:
>
> On Sat, 2006-01-21 at 10:16 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2006-01-20 at 22:29 +0100, Olaf Hering wrote:
> > > On Fri, Jan 20, Adrian Bunk wrote:
> > >
> > >
> > > > Can someone from the ppc developers drop me a small note whether
> > > > SND_POWERMAC completely replaces DMASOUND_PMAC?
> > >
> > > It doesnt. Some tumbler models work only after one plug/unplug cycle of
> > > the headphone. early powerbooks report/handle the mute settings
> > > incorrectly. there are likely more bugs.
> >
> > Interesting... Ben Collins hacked something to have Toonie work as a
> > "default" driver for non supported machine and saw that problem too, I
> > think he fixes it, I'll check with him what's up there and if his fix
> > applied to tumbler.c as well.
>
> My "fix" was basically the result of converting to the platform
> functions. It's hit or miss whether this works with tumbler too.
>
> You can try the Ubuntu kernel packages (they can be unpacked and used on
> non Ubuntu systems pretty easily) to see if it works for you. Tumbler
> platform function conversion isn't even tested, so I'd be happy to hear
> any feedback.
Don't forget to forward your patches to alsa-devel or me ;)
thanks,
Takashi
^ permalink raw reply
* Re: u-boot debugging
From: David Jander @ 2006-01-23 9:32 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Atul Sabharwal
In-Reply-To: <005301c61e54$aadb1b10$02c0650a@ATULSPC>
On Saturday 21 January 2006 07:34, Atul Sabharwal wrote:
> You have a conflict of interest as you are just pissed with Metrowerks
> as they are your competitors. Open source is about free speech and
> not for people with vested interests. You seem to be one of the guys
> with vested interest.
Everybody has their interests. Even OSS programmers have interests, if not
always of economical nature. I don't think Mr. Denk has any more reasons to
"be pissed" with Metrowerks than you might have reasons to "be pissed" with
DENX or Abatron.
> You cannot repress people and tell them *oxymorons* or ninkampoops...
> If you do the cost benefit analysis between BDI and Metrowerks debugger,
> its the same. And their UI is better than ddd and works with a BDI also.
> So, if you consider all aspects, its a better product.
That is a very subjective observation. Here is a slightly more objective one
for you: BDI can use almost any UI that supports gdb, and there are quite a
lot. Not only DDD. Does Metrowerks offer you that amount of choice?
> And opensource is used all over the globe including the Asian subcontinent.
> And there are still sites which use hubs as people dont have the excess
> money
> to throw away on legacy products. Just sitting in your small cube does not
> give
> insight to global technology trends...
Well, I suppose using a 10Mbps switch shouldn't cost much more than a 100Mbps
hub, and you almost said it yourself, that it would be more efficient in a
crowded network ;-)
What I really wonder is what the choice between a switch and a hub has to do
with "global technology trends".
I detect an increasing amount of resentment in your words, and that is not
good as far as my experience goes.
Greetings,
--
David Jander
^ permalink raw reply
* RE: u-boot debugging
From: Alexandre BASTOS @ 2006-01-23 9:25 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201AC2CF4@us-bv-m23.global.tektronix.net>
> First learn to communicate in English. I can give you 25 Us cents as I
> cannot afford 1 Mark. You are not work even a Mark.
>
What in the hell is this. Please, there are some here who don't speak
a perfect english but try to use it as a common language to exchange.
I feel also offended about this.
And please, read something apart from user manuals ... mark is no longer
the german currency. Euro, ... you know?
Un saudo
Alex Bastos
^ permalink raw reply
* RE: u-boot debugging
From: Paula Saameño @ 2006-01-23 7:48 UTC (permalink / raw)
To: 20060122082849.66877.qmail, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
I do as well, Glenn... He gave me so much help in my learning and he only
deserves good comments!!
[-- Attachment #2: Type: text/html, Size: 104 bytes --]
^ permalink raw reply
* 2.4.x vs 2.6.x performance
From: Frank @ 2006-01-23 4:24 UTC (permalink / raw)
To: linuxppc-embedded
I remember reading a while back that the 2.6 kernel is
considerably slower then the 2.4 kernel (Wolfgang Denx). Has
anybody taken any performance measurements on a later kernel
version to see if the above still hods true?
I'm thinking about moving to 2.6 since a lot of open source
projects have stopped suporting the 2.4 kernel.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 001/001] PMAC HD runtime blinking control
From: Benjamin Herrenschmidt @ 2006-01-22 21:59 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <200601221256.25685.arekm@pld-linux.org>
On Sun, 2006-01-22 at 12:56 +0100, Arkadiusz Miskiewicz wrote:
> On Sunday 22 January 2006 03:19, Cedric Pradalier wrote:
> > Hi,
> >
> > I've finally spend the time to mend the patch for control of
> > the HD led blinking at runtime. This is a patch against
> > 2.6.15
>
> I wonder if it's also possible to disable blinking when laptop sleeps?
Not that I know.. this is entirely done by the PMU.
Ben.
^ permalink raw reply
* [PATCH] cleanup pmac_newworld variable usage
From: Olaf Hering @ 2006-01-22 21:19 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
remove extern declarations of pmac_newworld
move pmac_newworld to bss
if there is any "interrupt-controller" device, then it is newworld.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/ppc_ksyms.c | 1 -
arch/powerpc/platforms/powermac/setup.c | 8 ++++----
2 files changed, 4 insertions(+), 5 deletions(-)
Index: linux-2.6.16-rc1-olh/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.16-rc1-olh.orig/arch/powerpc/kernel/ppc_ksyms.c
+++ linux-2.6.16-rc1-olh/arch/powerpc/kernel/ppc_ksyms.c
@@ -57,7 +57,6 @@ extern void machine_check_exception(stru
extern void alignment_exception(struct pt_regs *regs);
extern void program_check_exception(struct pt_regs *regs);
extern void single_step_exception(struct pt_regs *regs);
-extern int pmac_newworld;
extern int sys_sigreturn(struct pt_regs *regs);
EXPORT_SYMBOL(clear_pages);
Index: linux-2.6.16-rc1-olh/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- linux-2.6.16-rc1-olh.orig/arch/powerpc/platforms/powermac/setup.c
+++ linux-2.6.16-rc1-olh/arch/powerpc/platforms/powermac/setup.c
@@ -88,11 +88,10 @@ int ppc_override_l2cr = 0;
int ppc_override_l2cr_value;
int has_l2cache = 0;
-int pmac_newworld = 1;
+int pmac_newworld;
static int current_root_goodness = -1;
-extern int pmac_newworld;
extern struct machdep_calls pmac_md;
#define DEFAULT_ROOT_DEVICE Root_SDA1 /* sda1 - slightly silly choice */
@@ -310,9 +309,10 @@ static void __init pmac_setup_arch(void)
for (ic = NULL; (ic = of_find_all_nodes(ic)) != NULL; )
if (get_property(ic, "interrupt-controller", NULL))
break;
- pmac_newworld = (ic != NULL);
- if (ic)
+ if (ic) {
+ pmac_newworld = 1;
of_node_put(ic);
+ }
/* Lookup PCI hosts */
pmac_pci_init();
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH 001/001] PMAC HD runtime blinking control
From: Arkadiusz Miskiewicz @ 2006-01-22 11:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc
In-Reply-To: <20060122121907.792abc72.cedric.pradalier@free.fr>
On Sunday 22 January 2006 03:19, Cedric Pradalier wrote:
> Hi,
>
> I've finally spend the time to mend the patch for control of
> the HD led blinking at runtime. This is a patch against
> 2.6.15
I wonder if it's also possible to disable blinking when laptop sleeps?
=2D-=20
Arkadiusz Mi=B6kiewicz PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/
^ 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