* [PATCH v5 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-14 10:21 UTC (permalink / raw)
To: linuxppc-dev
This patch adds support for 'mpc5200-simple-platform' compatible
boards which do not need a platform specific setup. Such boards
are supported assuming the following:
- GPIO pins are configured by the firmware,
- CDM configuration (clocking) is setup correctly by firmware,
- if the 'fsl,has-wdt' property is present in one of the
gpt nodes, then it is safe to use such gpt to reset the board,
- PCI is supported if enabled in the kernel configuration
and if there is a PCI bus node defined in the device tree.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
This is a updated version of the patch 04/13 from the patchset that
adds arch/powerpc support for three MPC5200 based boards:
TQ-Components TQM5200, Schindler CM5200 and Promess Motion-PRO.
Supported boards table was made static __initdata and
sorted alphabetically.
Cheers,
Marian Balakowicz
arch/powerpc/boot/dts/lite5200.dts | 2 -
arch/powerpc/boot/dts/lite5200b.dts | 2 -
arch/powerpc/platforms/52xx/Kconfig | 22 ++++++-
arch/powerpc/platforms/52xx/Makefile | 1
arch/powerpc/platforms/52xx/mpc5200_simple.c | 84 ++++++++++++++++++++++++++
5 files changed, 107 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc5200_simple.c
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 6731763..5902362 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200";
// revision = "1.0";
- compatible = "fsl,lite5200","generic-mpc5200";
+ compatible = "fsl,lite5200";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index b540388..b509129 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200b";
// revision = "1.0";
- compatible = "fsl,lite5200b","generic-mpc5200";
+ compatible = "fsl,lite5200b";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 2938d49..36e880b 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -19,6 +19,26 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
+config PPC_MPC5200_SIMPLE
+ bool "Generic support for simple MPC5200 based boards"
+ depends on PPC_MULTIPLATFORM && PPC32
+ select PPC_MPC5200
+ default n
+ help
+ This option enables support for a simple MPC52xx based boards which
+ do not need a custom platform specific setup. Such boards are
+ supported assuming the following:
+
+ - GPIO pins are configured by the firmware,
+ - CDM configuration (clocking) is setup correctly by firmware,
+ - if the 'fsl,has-wdt' property is present in one of the
+ gpt nodes, then it is safe to use such gpt to reset the board,
+ - PCI is supported if enabled in the kernel configuration
+ and if there is a PCI bus node defined in the device tree.
+
+ Boards that are compatible with this generic platform support
+ are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+
config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
depends on PPC_MULTIPLATFORM && PPC32
@@ -34,5 +54,3 @@ config PPC_LITE5200
select WANT_DEVICE_TREE
select PPC_MPC5200
default n
-
-
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index 307dbc1..fe1b81b 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -6,6 +6,7 @@ obj-y += mpc52xx_pic.o mpc52xx_common.o
obj-$(CONFIG_PCI) += mpc52xx_pci.o
endif
+obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
obj-$(CONFIG_PPC_EFIKA) += efika.o
obj-$(CONFIG_PPC_LITE5200) += lite5200.o
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
new file mode 100644
index 0000000..049c03d
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -0,0 +1,84 @@
+/*
+ * Support for 'mpc5200-simple-platform' compatible boards.
+ *
+ * Written by Marian Balakowicz <m8@semihalf.com>
+ * Copyright (C) 2007 Semihalf
+ *
+ * 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.
+ *
+ * Description:
+ * This code implements support for a simple MPC52xx based boards which
+ * do not need a custom platform specific setup. Such boards are
+ * supported assuming the following:
+ *
+ * - GPIO pins are configured by the firmware,
+ * - CDM configuration (clocking) is setup correctly by firmware,
+ * - if the 'fsl,has-wdt' property is present in one of the
+ * gpt nodes, then it is safe to use such gpt to reset the board,
+ * - PCI is supported if enabled in the kernel configuration
+ * and if there is a PCI bus node defined in the device tree.
+ *
+ * Boards that are compatible with this generic platform support
+ * are listed in a 'board' table.
+ */
+
+#undef DEBUG
+#include <asm/time.h>
+#include <asm/machdep.h>
+#include <asm/mpc52xx.h>
+
+/*
+ * Setup the architecture
+ */
+static void __init mpc5200_simple_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("mpc5200_simple_setup_arch()", 0);
+
+ /* Some mpc5200 & mpc5200b related configuration */
+ mpc5200_setup_xlb_arbiter();
+
+ /* Map wdt for mpc52xx_restart() */
+ mpc52xx_map_wdt();
+
+ mpc52xx_setup_pci();
+}
+
+/* list of the supported boards */
+static const char *board[] __initdata = {
+ "promess,motionpro",
+ "schindler,cm5200",
+ "tqc,tqm5200",
+ NULL
+};
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc5200_simple_probe(void)
+{
+ unsigned long node = of_get_flat_dt_root();
+ int i = 0;
+
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(node, board[i]))
+ break;
+ i++;
+ }
+
+ return (board[i] != NULL);
+}
+
+define_machine(mpc5200_simple_platform) {
+ .name = "mpc5200-simple-platform",
+ .probe = mpc5200_simple_probe,
+ .setup_arch = mpc5200_simple_setup_arch,
+ .init = mpc52xx_declare_of_platform_devices,
+ .init_IRQ = mpc52xx_init_irq,
+ .get_irq = mpc52xx_get_irq,
+ .restart = mpc52xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+};
^ permalink raw reply related
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-14 10:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195034697.28865.34.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Wed, 14 Nov 2007 21:04:57 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
> On Wed, 2007-11-14 at 10:39 +0100, Gerhard Pircher wrote:
> > Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
> > masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
> > prefetch engines (I don't care about the performance loss).
> > I couldn't find any other code that sets the M bit, except for huge
> > TLB
> > page support, but isn't that only for PPC64?
>
> Right, it's only 64 bits. You've double checked nothing broke the M bit
> thing ? In which case, I don't know what else...
Yes, I did. Otherwise the machine dies much earlier in the boot process.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-14 10:04 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071114093939.297890@gmx.net>
On Wed, 2007-11-14 at 10:39 +0100, Gerhard Pircher wrote:
> Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
> masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
> prefetch engines (I don't care about the performance loss).
> I couldn't find any other code that sets the M bit, except for huge
> TLB
> page support, but isn't that only for PPC64?
Right, it's only 64 bits. You've double checked nothing broke the M bit
thing ? In which case, I don't know what else...
Ben.
^ permalink raw reply
* Virtex TEMAC 1000Mb/s trouble, but 100b/s is working
From: alex_snippet @ 2007-11-14 9:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
I'm porting Linux for custom board based on Virtex4 FX, vanilla kernel
2.6.22.5 , Xilinx EDK 9.1 BSP,
ELDK41 - cross-compiler
target nfs-root pointed to ELDK41/ppc_4xx
Kernel command line:
Linux/PPC load: root=/dev/nfs rw console=ttyS0,9600
nfsroot=192.168.0.1:/target
ip=on
All work successfully was done, i tested all at 100Mb's connection speed,
but yesterday my customer said that with 1Gbit connection it did't work :(
end of log following:
3.341532] eth0: XTemac: Options: 0xb8f2
[ 11.855386] eth0: XTemac: We renegotiated the speed to: 1000
[ 11.923237] eth0: XTemac: speed set to 1000Mb/s
[ 13.000064] Sending DHCP requests ......, OK
[ 65.484075] IP-Config: Got DHCP answer from 0.0.0.0, my address is
192.168.0.
192
[ 65.573684] IP-Config: Complete:
[ 65.610416] device=eth0, addr=192.168.0.192, mask=255.255.255.0,
gw=192
.168.0.1,
[ 65.705572] host=192.168.0.192, domain=, nis-domain=(none),
[ 65.777872] bootserver=0.0.0.0, rootserver=192.168.0.1, rootpath=
[ 65.861982] Looking up port of RPC 100003/2 on 192.168.0.1
[ 65.929093] Looking up port of RPC 100005/1 on 192.168.0.1
[ 66.024134] VFS: Mounted root (nfs filesystem).
[ 66.079160] Freeing unused kernel memory: 104k init
[ 71.640314] nfs: server 192.168.0.1 not responding, still trying
[ 76.040311] nfs: server 192.168.0.1 not responding, still trying
Load process was friezed at this point. When connection speed is 100Mb/s
everything is ok.
Please advise me what to do, i tried to increase ppc core frequency from 100
to 300 MHz - the same problem.
When i'm using virtual machine instead of real hardware it's working on
1000Gb/s :) but isn't on real hardware.
I'm using Fedora 7 as a host.
May be there are some nfs-demon settings?
My MHS file fragment:
BEGIN hard_temac
PARAMETER INSTANCE = hard_temac_0
PARAMETER HW_VER = 3.00.b
PARAMETER C_PHY_TYPE = 1
PARAMETER C_EMAC1_PRESENT = 0
BUS_INTERFACE V4EMACDST0 = V4EMAC0
PORT GMII_TXD_0 = GMII_TXD0
PORT GMII_TX_EN_0 = GMII_TX_EN0
PORT GMII_TX_ER_0 = GMII_TX_ER0
PORT GMII_TX_CLK_0 = GMII_TX_CLK0
PORT GMII_RXD_0 = GMII_RXD0
PORT GMII_RX_DV_0 = GMII_RX_DV0
PORT GMII_RX_ER_0 = GMII_RX_ER0
PORT GMII_RX_CLK_0 = GMII_RX_CLK0
PORT MDC_0 = MDC0
PORT MDIO_0 = MDIO0
PORT GTX_CLK_0 = GTX_CLK0
PORT MII_TX_CLK_0 = MII_TX_CLK0
PORT RESET = Emac_Reset
PORT REFCLK = sys_clk_s
END
BEGIN plb_temac
PARAMETER INSTANCE = TriMode_MAC_GMII
PARAMETER HW_VER = 3.00.a
PARAMETER C_BASEADDR = 0x81200000
PARAMETER C_HIGHADDR = 0x8120ffff
PARAMETER C_MAC_FIFO_DEPTH = 64
PARAMETER C_RX_DRE_TYPE = 0
PARAMETER C_TX_DRE_TYPE = 0
PARAMETER C_DMA_TYPE = 1
PARAMETER C_PLB_CLK_PERIOD_PS = 10000
BUS_INTERFACE MSPLB = plb
BUS_INTERFACE V4EMACSRC = V4EMAC0
PORT IP2INTC_Irpt = TEMAC_Interrupt
PORT Emac_Reset = Emac_Reset
PORT PhyResetN = PhyResetN
END
--
View this message in context: http://www.nabble.com/Virtex-TEMAC-1000Mb-s-trouble%2C-but-100b-s-is-working-tf4803823.html#a13743302
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-14 9:39 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194997072.28865.5.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Wed, 14 Nov 2007 10:37:52 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
> Add printk's to things :-) It's a UP kernel so there should be no
> spinlocks anyway.
>
> Best is to try to get a 100% reprocase and printk your way toward the
> origin of the problem if you don't have a HW debugger. Unless you manage
> to sneak in an irq to xmon but if you are totally locked up, you
> probably can't.
Also xmon seems to lockup the machine. I was able to active it through the
magic sysrq key, but the machine died afterwards.
> Could also be something you do that your buggy northbridge doesn't like.
> For example, maybe it dislikes M bit in the hash table and you end up
> with it set due to other reasons (I know we had changes in this area).
Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
prefetch engines (I don't care about the performance loss).
I couldn't find any other code that sets the M bit, except for huge TLB
page support, but isn't that only for PPC64?
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Gerhard Pircher @ 2007-11-14 9:20 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195003029.28865.16.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Wed, 14 Nov 2007 12:17:09 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: Jon Smirl <jonsmirl@gmail.com>, grant.likely@secretlab.ca, linuxppc-dev@ozlabs.org
> Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
>
> On Tue, 2007-11-13 at 23:21 +0100, Gerhard Pircher wrote:
> > -------- Original-Nachricht --------
> > > Datum: Tue, 13 Nov 2007 17:10:29 -0500
> > > Von: "Jon Smirl" <jonsmirl@gmail.com>
> > > An: "Grant Likely" <grant.likely@secretlab.ca>
> > > CC: "Gerhard Pircher" <gerhard_pircher@gmx.net>,
> linuxppc-dev@ozlabs.org
> > > Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
> > >
> > > Here are the choices:
> > > http://www.macraigor.com/cpus.htm
> > Looks like the Abatron BDI-2000 is the cheapest hardware debugger that
> > supports 74xx G4 CPUs. :-(
>
> Do you have the appropriate connector for it on the motherboard as
> well ? If not, then you are out of luck...
>
> Ben.
Yes, the connector is on the CPU module.
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: I2C on mpc8248 / device tree
From: Kumar Gala @ 2007-11-14 7:17 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711131539n228f9f21q7b2acc896499b80d@mail.gmail.com>
On Nov 13, 2007, at 5:39 PM, Alan Bennett wrote:
> I've got four devices on i2c that I need to read. Simple thermal
> and voltage monitors. I2c works fine in uboot, and now I'm trying
> to get things to work in linux.
>
> In the kernel .config I enable
> I2C
> and
> I2C_MPC
This driver isn't for the I2C on 8248. You need a cpm2 i2c driver
for that controller.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Fix fs_enet module build
From: David Miller @ 2007-11-14 5:09 UTC (permalink / raw)
To: jochen; +Cc: jeff, netdev, linux-kernel, linuxppc-embedded, akpm
In-Reply-To: <4739EDA8.6020800@scram.de>
From: Jochen Friedrich <jochen@scram.de>
Date: Tue, 13 Nov 2007 19:32:08 +0100
> If fs_enet is build as module, on PPC_CPM_NEW_BINDING platforms
> mii-fec/mii-bitbang should be build as module, as well. On other
> platforms, mii-fec/mii-bitbang must be included into the main module.
> Otherwise some symbols remain undefined. Additionally, fs_enet uses
> libphy, so add a select PHYLIB.
>
> Building modules, stage 2.
> MODPOST 5 modules
> ERROR: "fs_scc_ops" [drivers/net/fs_enet/fs_enet.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
This is truly ugly and creates an unnecessarily hard to
maintain and complex driver.
Please find a way to fix this for real, so that the
PPC_CPM_NEW_BINDING ifdef is not necessary at all and
things get built modular or not naturally as we handle
things for other cases like this.
THanks.
^ permalink raw reply
* Re: [PATCH] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
From: Stephen Rothwell @ 2007-11-14 4:11 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1Irw8I-0000b4-5e@jdl.com>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Tue, 13 Nov 2007 07:48:50 -0600 Jon Loeliger <jdl@jdl.com> wrote:
>
> I'm assuming I can chip away at _all_ of these,
> including the ones in the drivers/ directories as well.
Knock yourself out! :-)
> I haven't a clue who will really pick all these up.
> We could arrange for Paul to grab the arch/powerpc.
> But the rest? Mr Morton perhaps?
Just keep in mind that some of these changes may affect Sparc and
Sparc64, so Dave Miller is you man for those.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] pSeries: make pseries_defconfig minus PCI build again
From: Stephen Rothwell @ 2007-11-14 4:07 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/pseries/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 16e4e40..306a9d0 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -21,7 +21,7 @@ config PPC_SPLPAR
config EEH
bool "PCI Extended Error Handling (EEH)" if EMBEDDED
- depends on PPC_PSERIES
+ depends on PPC_PSERIES && PCI
default y if !EMBEDDED
config SCANLOG
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH 0/2] PowerPC: 4xx uic updates
From: Benjamin Herrenschmidt @ 2007-11-14 3:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, dwg
In-Reply-To: <20071113200514.72d03792@zod.rchland.ibm.com>
On Tue, 2007-11-13 at 20:05 -0600, Josh Boyer wrote:
> On Tue, 13 Nov 2007 23:15:59 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > These patches update 4xx uic code. The first one
> > fixes a minor issue with edge-triggered interrupts,
> > while the second one makes it use generic level and edge irq
> > handlers. I've added irq ack'ing to the unmask callback for
> > level-triggered interrupts, because to de-assert them we have
> > to do 2 things is the exact order as below:
> > 1. de-assert the external source in the ISR.
> > 2. ack the IRQ on the UIC.
> > So, ack'ing level interrupts before unmasking them makes possible
> > to use generic level irq handler and it doesn't hurt, cause
> > we can never miss a level-triggered interrupt. It always stays
> > asserted untill the external source is removed and ack'ed on UIC.
> >
> > These have been tested on Sequoia PowerPC 440EPx board.
>
> Is my mail server slow, or did patch 2 of 2 never make it out?
It never reached me neither.
Ben
^ permalink raw reply
* Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: Benjamin Herrenschmidt @ 2007-11-14 3:43 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071114021326.GB19378@localhost.localdomain>
On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote:
> Hrm. I *think* I'm convinced this is safe, although acking in a
> callback which doesn't say it acks is rather yucky. Essentially this
> code is trading flow readability (because just reading
> handle_level_irq will tell you something other than what it does in
> our case) for smaller code size. I'm not sure if this is a good trade
> or not.
>
> There's also one definite problem: according to the discussions I had
> with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what
> we want for edge interrupts.
>
> Apparently handle_edge_irq is only for edge interrupts on "broken"
> PICs which won't latch new interrupts while the irq is masked. UIC is
> not in this category, so handle_level_irq is actually what we want,
> even for an edge irq.
>
> Yes, I thought the naming was more than a little confusing, too.
Hrm... handle_edge_irq works for both and you have a small performance
benefit in not masking, and thus using handle_edge_irq, so I don't
totally agree here. Basically, what handle_edge_irq() does is lazy
masking. Now there -is- an issue here is that if you do lazy masking,
you need to be able to re-emit in some convenient way.
Ben.
^ permalink raw reply
* Re: [PATCH] pci hotplug: fix rpaphp directory naming
From: Greg KH @ 2007-11-14 3:26 UTC (permalink / raw)
To: Linas Vepstas
Cc: rick.jones2, pcihpd-discuss, Alex Chiang, Matthew Wilcox, gregkh,
linux-kernel, linuxppc-dev, linux-acpi, Kristen Carlson Accardi,
linux-pci, strosake, lenb
In-Reply-To: <20071114003455.GD8509@austin.ibm.com>
On Tue, Nov 13, 2007 at 06:34:55PM -0600, Linas Vepstas wrote:
>
>
> Fix presentation of the slot number in the /sys/bus/pci/slots
> directory to match that used in the majority of other drivers.
We need a signed-off-by: to be able to apply this...
thanks,
greg k-h
^ permalink raw reply
* RE: printk/console_init - baud rate setting
From: Siva Prasad @ 2007-11-14 2:28 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.62.0711130915480.31003@pademelon.sonytel.be>
Thanks a lot Geert and Benjamin for your response.
Code is indeed calling register_console from three different places=20
1) con_init()[name-tty],=20
2) serial8250_console_init()[name-ttyS],=20
3) early_uart_console_init()[name-uart].=20
Among these, 8250 must be the active one. Also
serial8250_console_write() keeps hitting the BDI2000 break point with
same address and count again and again.
I am getting garbage on the screen. So, I presume this must be some sort
of baud rate issue. Can some one help me out understand how this baud is
set for serial drivers? I want to run at 115200.
Thanks
Siva
-----Original Message-----
From: geert@sonytel.be [mailto:geert@sonytel.be] On Behalf Of Geert
Uytterhoeven
Sent: Tuesday, November 13, 2007 12:17 AM
To: Siva Prasad
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: printk/console_init
On Mon, 12 Nov 2007, Siva Prasad wrote:
> I am using 2.6.19 Linux on 8641D based system.
>=20
> I am using early printk's and it works fine until console_init() is
> executed. After that it does not, as the early printk's get disabled,
> which is fine. However, I don't see any prints after that at all, that
> are based on regular printk statements. I looked directly into the
> memory at __log_buf and found all the print messages. It is just not
> coming out to the serial port properly.
>=20
> It would be great if some one can tell me various parameters that I
need
> to consider changing, to successfully port the serial driver for a new
> board.
>=20
> Based on the early printk's, I am getting the following messages...
>=20
> Using MPC86xx HPCN machine description
> Total memory =3D 1024MB; using 2048kB for hash table (at cfe00000)
> Linux version 2.6.19 (sprasad@cider.bivio.net) (gcc version 4.1.1
> 20060525 (Red Hat 4.1.1-1)) #115 SMP Mon Nov 12 18:21:43 PST 2007
> Found legacy serial port 0 for /soc8641@ff700000/serial@4500
> mem=3Dff704500, taddr=3Dff704500, irq=3D1a, clk=3D1496250, speed=3D0
> Found MPC86xx PCIE host bridge at 0x00000000ff708000. Firmware bus
> number: 0->254
> Found MPC86xx PCIE host bridge at 0x00000000ff709000. Firmware bus
> number: 0->255
> MPC86xx HPCN board from Freescale Semiconductor
> Zone PFN ranges:
> DMA 0 -> 196608
> Normal 196608 -> 196608
> HighMem 196608 -> 262144
> early_node_map[1] active PFN ranges
> 0: 0 -> 262144
> start_kernel: 8 22000000.
> Built 1 zonelists. Total pages: 260096
> Kernel command line: console=3DttyS0,115200 root=3D/dev/sda8
^^^^^^^^^^^^
> mpic: Setting up MPIC " MPIC " version 1.2 at ff740000, max 2 CPUs
> mpic: ISU size: 16, shift: 4, mask: f
> mpic: Initializing for 80 sources
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> time_init: decrementer frequency =3D 150.000000 MHz
> time_init: processor frequency =3D 1496.250000 MHz
> <........ Nothing gets printed after this .......>
Did your serial driver (a) call register_console() (b) using the correct
name?
With kind regards,
=20
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village * Da Vincilaan 7-D1 * B-1935 Zaventem * Belgium
=20
Phone: +32 (0)2 700 8453=09
Fax: +32 (0)2 700 8622=09
E-mail: Geert.Uytterhoeven@sonycom.com=09
Internet: http://www.sony-europe.com/
=09
Sony Network and Software Technology Center Europe=09
A division of Sony Service Centre (Europe) N.V.=09
Registered office: Technologielaan 7 * B-1840 Londerzeel * Belgium=09
VAT BE 0413.825.160 * RPR Brussels=09
Fortis Bank Zaventem * Swift GEBABEBB08A * IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: 4xx uic updates
From: David Gibson @ 2007-11-14 2:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071113200514.72d03792@zod.rchland.ibm.com>
On Tue, Nov 13, 2007 at 08:05:14PM -0600, Josh Boyer wrote:
> On Tue, 13 Nov 2007 23:15:59 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > These patches update 4xx uic code. The first one
> > fixes a minor issue with edge-triggered interrupts,
> > while the second one makes it use generic level and edge irq
> > handlers. I've added irq ack'ing to the unmask callback for
> > level-triggered interrupts, because to de-assert them we have
> > to do 2 things is the exact order as below:
> > 1. de-assert the external source in the ISR.
> > 2. ack the IRQ on the UIC.
> > So, ack'ing level interrupts before unmasking them makes possible
> > to use generic level irq handler and it doesn't hurt, cause
> > we can never miss a level-triggered interrupt. It always stays
> > asserted untill the external source is removed and ack'ed on UIC.
> >
> > These have been tested on Sequoia PowerPC 440EPx board.
>
> Is my mail server slow, or did patch 2 of 2 never make it out?
It reached me eventually, but only to my ibm address, not via the
list (whereas I got both copies of 0 and 1).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: David Gibson @ 2007-11-14 2:13 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071113202731.GA26319@ru.mvista.com>
On Tue, Nov 13, 2007 at 11:27:31PM +0300, Valentine Barshak wrote:
> This patch makes PowerPC 4xx UIC use generic edge and level irq handlers
> instead of a custom handle_uic_irq() function. Acking a level irq on UIC
> has no effect if the interrupt is still asserted by the device, even if
> the interrupt is already masked. So, to really de-assert the interrupt
> we need to de-assert the external source first *and* ack it on UIC then.
> The handle_level_irq() function masks and ack's the interrupt with mask_ack
> callback prior to calling the actual ISR and unmasks it at the end.
> So, to use it with UIC level interrupts we need to ack in the unmask
> callback instead, after the ISR has de-asserted the external interrupt source.
> Even if we ack the interrupt that we didn't handle (unmask/ack it at
> the end of the handler, while next irq is already pending) it will not
> de-assert the irq, untill we de-assert its exteral source.
Hrm. I *think* I'm convinced this is safe, although acking in a
callback which doesn't say it acks is rather yucky. Essentially this
code is trading flow readability (because just reading
handle_level_irq will tell you something other than what it does in
our case) for smaller code size. I'm not sure if this is a good trade
or not.
There's also one definite problem: according to the discussions I had
with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what
we want for edge interrupts.
Apparently handle_edge_irq is only for edge interrupts on "broken"
PICs which won't latch new interrupts while the irq is masked. UIC is
not in this category, so handle_level_irq is actually what we want,
even for an edge irq.
Yes, I thought the naming was more than a little confusing, too.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: 4xx uic updates
From: Josh Boyer @ 2007-11-14 2:05 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, dwg
In-Reply-To: <20071113201559.GA26172@ru.mvista.com>
On Tue, 13 Nov 2007 23:15:59 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> These patches update 4xx uic code. The first one
> fixes a minor issue with edge-triggered interrupts,
> while the second one makes it use generic level and edge irq
> handlers. I've added irq ack'ing to the unmask callback for
> level-triggered interrupts, because to de-assert them we have
> to do 2 things is the exact order as below:
> 1. de-assert the external source in the ISR.
> 2. ack the IRQ on the UIC.
> So, ack'ing level interrupts before unmasking them makes possible
> to use generic level irq handler and it doesn't hurt, cause
> we can never miss a level-triggered interrupt. It always stays
> asserted untill the external source is removed and ack'ed on UIC.
>
> These have been tested on Sequoia PowerPC 440EPx board.
Is my mail server slow, or did patch 2 of 2 never make it out?
josh
^ permalink raw reply
* Xilinx Linux git server available
From: Wolfgang Reissnegger @ 2007-11-14 1:56 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm happy to announce that the Xilinx Linux Kernel git server is finally up and running and available to the public.
The Xilinx Linux Kernel is based on the mainline Linux Kernel from kernel.org and adds driver support for various Xilinx IP cores and Xilinx reference boards. It contains many (but not all) of the MicroBlaze contributions and enhancements from John Williams' PetaLogix Linux distribution and some PPC work from Grant Likely. It also contains contributions from Stephen Neuendorffer, Joachim Foerster and Brian Hill, to name a few.
The kernel includes drivers to support the following Xilinx IP cores:
* EMAC, EMACLITE, TEMAC, LLTEMAC
* UART, UARTLITE
* SYSACE
* SPI, GPIO, FB, GPIO, HWICAP, AC97
and support for the following boards:
* ML40x, ML4x0
* Spartan 3E 1600, XUPV2P
In a couple weeks we will be adding MicroBlaze v7 MMU support.
The kernel is licensed under the GPL version 2 and is provided AS IS. It is _not_ supported in any way or form by the Xilinx Support Center. If you call the Xilinx Support center, they will not be able to help you. For those interested in a supported Linux distribution, please contact one of the many partner companies at:
http://www.xilinx.com/ise/embedded/epartners/listing.htm
Please, also keep in mind that the kernel is not actively being tested and will may set your house on fire.
The git URL for the Xilinx Linux Kernel sources is:
git://git.xilinx.com/linux-2.6-xlnx.git
The Web front-end for this server can be found at:
http://git.xilinx.com
At this time there are two branches available:
* lin26-xlnx
This branch is based on the latest stable kernel release (currently 2.6.23)
* lin26-xlnx-rc
This branch tracks the leading edge mainline (currently 2.6.24-rc2)
The git server also hosts a clone of Grant Likely's OF device tree generation tool with additions by Stephen Neuendorffer to support MicroBlaze systems. The git URL for this repository is:
git://git.xilinx.com/gen-mhs-devtree.git
If you have suggestions or want to contribute to the Xilinx Linux Kernel, please send your feedback, patches or other contributions to:
git _at_ xilinx.com
Hope to hear from you soon :-)
Thanks,
Wolfgang
^ permalink raw reply
* Xilinx Linux git server
From: Wolfgang Reissnegger @ 2007-11-14 1:38 UTC (permalink / raw)
To: linuxppc-embedded, uclinux-dev
Hi all,
I'm happy to announce that the Xilinx Linux Kernel git server is finally up and running and available to the public.
The Xilinx Linux Kernel is based on the mainline Linux Kernel from kernel.org and adds driver support for various Xilinx IP cores and Xilinx reference boards. It contains many (but not all) of the MicroBlaze contributions and enhancements from John Williams' PetaLogix Linux distribution and some PPC work from Grant Likely. It also contains contributions from Stephen Neuendorffer, Joachim Foerster and Brian Hill, to name a few.
The kernel includes drivers to support the following Xilinx IP cores:
* EMAC, EMACLITE, TEMAC, LLTEMAC
* UART, UARTLITE
* SYSACE
* SPI, GPIO, FB, GPIO, HWICAP, AC97
and support for the following boards:
* ML40x, ML4x0
* Spartan 3E 1600, XUPV2P
In a couple weeks we will be adding MicroBlaze v7 MMU support.
The kernel is licensed under the GPL version 2 and is provided AS IS. It is _not_ supported in any way or form by the Xilinx Support Center. If you call the Xilinx Support center, they will not be able to help you. For those interested in a supported Linux distribution, please contact one of the many partner companies at:
http://www.xilinx.com/ise/embedded/epartners/listing.htm
Please, also keep in mind that the kernel is not actively being tested and will may set your house on fire.
The git URL for the Xilinx Linux Kernel sources is:
git://git.xilinx.com/linux-2.6-xlnx.git
The Web front-end for this server can be found at:
http://git.xilinx.com
At this time there are two branches available:
* lin26-xlnx
This branch is based on the latest stable kernel release (currently 2.6.23)
* lin26-xlnx-rc
This branch tracks the leading edge mainline (currently 2.6.24-rc2)
The git server also hosts a clone of Grant Likely's OF device tree generation tool with additions by Stephen Neuendorffer to support MicroBlaze systems. The git URL for this repository is:
git://git.xilinx.com/gen-mhs-devtree.git
If you have suggestions or want to contribute to the Xilinx Linux Kernel, please send your feedback, patches or other contributions to:
git _at_ xilinx.com
Hope to hear from you soon :-)
Thanks,
Wolfgang
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Jon Smirl @ 2007-11-14 1:32 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1195003078.28865.18.camel@pasglop>
On 11/13/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > That's why Dominic wants to get OpenOCD running on the PowerPC. All we
> > need is the programming documentation for controlling the CPU via the
> > debug hardware.
>
> Note that this is basically different for every CPU around.
I'd like to get it for the MPC5200 because of the project I am working
on, an open source audio device. It would be nice if there was a cheap
hardware debugger available for hackers to use on it. Maybe one of the
Freescale developers will see this and send me the right docs.
Is it radically different? Dominic has been able to support every ARM
7/9 chip he can get his hands on without too much trouble once the
core support was written. I don't think he has ARM 11 working yet.
>
> > Obviously this documentation exist, all of the commercial vendors had
> > to have it to develop their debuggers. Maybe it is already out there
> > and we just don't know where to look.
>
> Ben.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] pci hotplug: rm bogus item in rpaphp struct
From: Linas Vepstas @ 2007-11-14 1:19 UTC (permalink / raw)
To: Greg KH, gregkh, Kristen Carlson Accardi; +Cc: linuxppc-dev, linux-pci
Remove unused struct element.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/pci/hotplug/rpaphp.h | 1 -
drivers/pci/hotplug/rpaphp_pci.c | 1 -
2 files changed, 2 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp.h 2007-11-13 18:37:31.000000000 -0600
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h 2007-11-13 19:00:42.000000000 -0600
@@ -76,7 +76,6 @@ struct slot {
char *name;
struct device_node *dn;
struct pci_bus *bus;
- struct list_head *pci_devs;
struct hotplug_slot *hotplug_slot;
};
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13 18:37:31.000000000 -0600
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13 19:00:13.000000000 -0600
@@ -100,7 +100,6 @@ int rpaphp_enable_slot(struct slot *slot
info->adapter_status = EMPTY;
slot->bus = bus;
- slot->pci_devs = &bus->devices;
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Benjamin Herrenschmidt @ 2007-11-14 1:17 UTC (permalink / raw)
To: Jon Smirl; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9e4733910711131553ked87330ubc0c439c42e51ace@mail.gmail.com>
> That's why Dominic wants to get OpenOCD running on the PowerPC. All we
> need is the programming documentation for controlling the CPU via the
> debug hardware.
Note that this is basically different for every CPU around.
> Obviously this documentation exist, all of the commercial vendors had
> to have it to develop their debuggers. Maybe it is already out there
> and we just don't know where to look.
Ben.
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Benjamin Herrenschmidt @ 2007-11-14 1:17 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071113222149.271610@gmx.net>
On Tue, 2007-11-13 at 23:21 +0100, Gerhard Pircher wrote:
> -------- Original-Nachricht --------
> > Datum: Tue, 13 Nov 2007 17:10:29 -0500
> > Von: "Jon Smirl" <jonsmirl@gmail.com>
> > An: "Grant Likely" <grant.likely@secretlab.ca>
> > CC: "Gerhard Pircher" <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> > Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
>
> > On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > Abatron BDI-2000.
> > >
> > > Oops, but that's not all that cheap. ($2750USD). You might try
> > > looking at the Macraigor Wiggler
> > > (http://www.macraigor.com/wiggler.htm), but it has limited powerpc
> > > support.
> >
> > Here are the choices:
> > http://www.macraigor.com/cpus.htm
> Looks like the Abatron BDI-2000 is the cheapest hardware debugger that
> supports 74xx G4 CPUs. :-(
Do you have the appropriate connector for it on the motherboard as
well ? If not, then you are out of luck...
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] PowerPC: 4xx uic: add mask_ack callback
From: David Gibson @ 2007-11-14 0:57 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071113202521.GA26295@ru.mvista.com>
On Tue, Nov 13, 2007 at 11:25:21PM +0300, Valentine Barshak wrote:
> This adds uic_mask_ack_irq() callback to PowerPC 4xx uic code
> to avoid kernel crash. It is used for edge-triggered interrupts
> by handle_uic_irq().
Oops. Obviously never caught this obvious bug, because I've never
used an edge-triggered interrupt on the Ebony yet.
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] pci hotplug: fix rpaphp directory naming
From: Linas Vepstas @ 2007-11-14 0:34 UTC (permalink / raw)
To: Greg KH, gregkh, Kristen Carlson Accardi
Cc: pcihpd-discuss, Alex Chiang, Matthew Wilcox, rick.jones2,
linux-kernel, linuxppc-dev, linux-acpi, linux-pci, strosake, lenb
Fix presentation of the slot number in the /sys/bus/pci/slots
directory to match that used in the majority of other drivers.
------
On Tue, Nov 13, 2007 at 02:58:30PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
> > /sys/bus/pci/slots
> > /sys/bus/pci/slots/control
> > /sys/bus/pci/slots/control/remove_slot
> > /sys/bus/pci/slots/control/add_slot
> > /sys/bus/pci/slots/0001:00:02.0
> > /sys/bus/pci/slots/0001:00:02.0/phy_location
>
> Ugh. Almost two years ago, paulus promised me he was going to fix the
> slot name for rpaphp. Guess he didn't.
You have to ask the right person. :-) I've been defacto mainaining
the rpaphp code for unpteen years now. On the other hand, I am also
much, much better at promising than delivering.
> This is one of the hateful things about the current design -- hotplug
> drivers do too much. Instead of being just the interface between the
> Linux PCI code and the hardware, they create sysfs directories, add
> files,
> and generally have far too much freedom.
I chopped out several hundred LOC from rpaphp a year ago,
and hopefuly that might make furthre simplification easier
someday.
> We have four different schemes currently for naming in slots/,
> 1. slot number. Used by cpqphp, ibmphp, acpiphp, pciehp, shpc.
> 2. domain:bus:dev:fn. Used by fakephp.
> 3a. domain:bus:dev. Used by rpaphp and sgihp.
> 3b. Except that rpaphp uses phy_location to present the information
> that
> should be in the name and sgihp uses path.
>
> ... I've forgotten what cpci uses. And yenta doesn't use it.
>
> How is anyone supposed to write sane managability tools in the
> presence
> of such anarchy?
>
> > ~ # cat /sys/bus/pci/slots/0000:00:02.2/phy_location
> > U787A.001.DNZ00Z5-P1-C2
>
> Right. This should look like:
>
> # cat /sys/bus/pci/slots/U787A.001.DNZ00Z5-P1-C2/address
> 0000:00:02
This patch implements exactly what you describe. Boot tested.
I assume you really mean it -- if so, then please review and
ack the patch !?
I have absolutely no clue if this breaks any existing IBM tools.
I'm pretty sure it doesn't ... but attention Mike Strosaker! does it?
drivers/pci/hotplug/rpaphp.h | 1
drivers/pci/hotplug/rpaphp_pci.c | 14 -----------
drivers/pci/hotplug/rpaphp_slot.c | 47 +++++++++++++++++++-------------------
3 files changed, 24 insertions(+), 38 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13 17:52:10.000000000 -0600
@@ -64,19 +64,6 @@ int rpaphp_get_sensor_state(struct slot
return rc;
}
-static void set_slot_name(struct slot *slot)
-{
- struct pci_bus *bus = slot->bus;
- struct pci_dev *bridge;
-
- bridge = bus->self;
- if (bridge)
- strcpy(slot->name, pci_name(bridge));
- else
- sprintf(slot->name, "%04x:%02x:00.0", pci_domain_nr(bus),
- bus->number);
-}
-
/**
* rpaphp_enable_slot - record slot state, config pci device
*
@@ -114,7 +101,6 @@ int rpaphp_enable_slot(struct slot *slot
info->adapter_status = EMPTY;
slot->bus = bus;
slot->pci_devs = &bus->devices;
- set_slot_name(slot);
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_slot.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c 2007-11-13 18:05:13.000000000 -0600
@@ -33,23 +33,31 @@
#include <asm/rtas.h>
#include "rpaphp.h"
-static ssize_t location_read_file (struct hotplug_slot *php_slot, char *buf)
+static ssize_t address_read_file (struct hotplug_slot *php_slot, char *buf)
{
- char *value;
- int retval = -ENOENT;
+ int retval;
struct slot *slot = (struct slot *)php_slot->private;
+ struct pci_bus *bus;
if (!slot)
- return retval;
+ return -ENOENT;
- value = slot->location;
- retval = sprintf (buf, "%s\n", value);
+ bus = slot->bus;
+ if (!bus)
+ return -ENOENT;
+
+ if (bus->self)
+ retval = sprintf(buf, pci_name(bus->self));
+ else
+ retval = sprintf(buf, "%04x:%02x:00.0",
+ pci_domain_nr(bus), bus->number);
+
return retval;
}
-static struct hotplug_slot_attribute php_attr_location = {
- .attr = {.name = "phy_location", .mode = S_IFREG | S_IRUGO},
- .show = location_read_file,
+static struct hotplug_slot_attribute php_attr_address = {
+ .attr = {.name = "address", .mode = S_IFREG | S_IRUGO},
+ .show = address_read_file,
};
/* free up the memory used by a slot */
@@ -64,7 +72,6 @@ void dealloc_slot_struct(struct slot *sl
kfree(slot->hotplug_slot->info);
kfree(slot->hotplug_slot->name);
kfree(slot->hotplug_slot);
- kfree(slot->location);
kfree(slot);
}
@@ -83,16 +90,13 @@ struct slot *alloc_slot_struct(struct de
GFP_KERNEL);
if (!slot->hotplug_slot->info)
goto error_hpslot;
- slot->hotplug_slot->name = kmalloc(BUS_ID_SIZE + 1, GFP_KERNEL);
+ slot->hotplug_slot->name = kmalloc(strlen(drc_name) + 1, GFP_KERNEL);
if (!slot->hotplug_slot->name)
goto error_info;
- slot->location = kmalloc(strlen(drc_name) + 1, GFP_KERNEL);
- if (!slot->location)
- goto error_name;
slot->name = slot->hotplug_slot->name;
+ strcpy(slot->name, drc_name);
slot->dn = dn;
slot->index = drc_index;
- strcpy(slot->location, drc_name);
slot->power_domain = power_domain;
slot->hotplug_slot->private = slot;
slot->hotplug_slot->ops = &rpaphp_hotplug_slot_ops;
@@ -100,8 +104,6 @@ struct slot *alloc_slot_struct(struct de
return (slot);
-error_name:
- kfree(slot->hotplug_slot->name);
error_info:
kfree(slot->hotplug_slot->info);
error_hpslot:
@@ -133,8 +135,8 @@ int rpaphp_deregister_slot(struct slot *
list_del(&slot->rpaphp_slot_list);
- /* remove "phy_location" file */
- sysfs_remove_file(&php_slot->kobj, &php_attr_location.attr);
+ /* remove "address" file */
+ sysfs_remove_file(&php_slot->kobj, &php_attr_address.attr);
retval = pci_hp_deregister(php_slot);
if (retval)
@@ -166,8 +168,8 @@ int rpaphp_register_slot(struct slot *sl
return retval;
}
- /* create "phy_location" file */
- retval = sysfs_create_file(&php_slot->kobj, &php_attr_location.attr);
+ /* create "address" file */
+ retval = sysfs_create_file(&php_slot->kobj, &php_attr_address.attr);
if (retval) {
err("sysfs_create_file failed with error %d\n", retval);
goto sysfs_fail;
@@ -175,8 +177,7 @@ int rpaphp_register_slot(struct slot *sl
/* add slot to our internal list */
list_add(&slot->rpaphp_slot_list, &rpaphp_slot_head);
- info("Slot [%s](PCI location=%s) registered\n", slot->name,
- slot->location);
+ info("Slot [%s] registered\n", slot->name);
return 0;
sysfs_fail:
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp.h 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h 2007-11-13 18:06:16.000000000 -0600
@@ -74,7 +74,6 @@ struct slot {
u32 type;
u32 power_domain;
char *name;
- char *location;
struct device_node *dn;
struct pci_bus *bus;
struct list_head *pci_devs;
^ 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