Re: Fix regression. Make hot unlplug of CPU0 work again.
On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote: Early in the 2.6.23 cycle we broke the ability to offline cpu0 (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by ensuring that the (xics) default irq server, will not be 0 when taking cpu0 offline. Also catches a use of irq, when virq should be used (I think that the last one). Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go back to the drawing board. Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fix regression. Make hot unlplug of CPU0 work again.
On Fri, 2007-10-05 at 17:05 +1000, Tony Breeds wrote: On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote: Early in the 2.6.23 cycle we broke the ability to offline cpu0 (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by ensuring that the (xics) default irq server, will not be 0 when taking cpu0 offline. Also catches a use of irq, when virq should be used (I think that the last one). Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go back to the drawing board. Maybe we should revert the original patch and go back to the drawing board for 2.6.24? Making sure we address the initial problem (which was exposed by kexec I think) and that we don't break cpu hotplug on the way. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
On Fri, Oct 05, 2007 at 12:18:58AM -0500, Kumar Gala wrote: [...] Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Looks allright, if it also works, then ship it :-) Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Now that this has been ack'd by Ben if you can respin the patch set we can get these in for 2.6.24 Great, will do. (I assume you are using a UCC as ethernet for test some of the QE support on 8568?) Yup, UCC as eth. Plus I've also tested SPI (which is in QE) in loopback mode. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsl_spi_init: Support non-QE processors
On Oct 3, 2007, at 11:01 PM, Stephen Rothwell wrote:
On Wed, 03 Oct 2007 17:43:50 +0200 Peter Korsgaard
[EMAIL PROTECTED] wrote:
@@ -1220,14 +1220,17 @@ int __init fsl_spi_init(struct
spi_board_info *board_infos,
{
struct device_node *np;
unsigned int i;
-const u32 *sysclk;
+const u32 *qe_sysclk = 0, *soc_sysclk = 0;
Please use NULL when referring to pointers.
Peter, any chance of getting a respin. I'd like this to go into 2.6.24.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
On Thu, Oct 04, 2007 at 05:01:47PM -0700, Nish Aravamudan wrote: On 10/2/07, Tony Breeds [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote: I realise it'll make the patch bigger, but this doesn't seem like a particularly good name for the variable anymore. Sure, what about? Clarify when RTAS logging is enabled. Signed-off-by: Tony Breeds [EMAIL PROTECTED] For what it's worth, on a different ppc64 box, this resolves a similar panic for me. Tested-by: Nishanth Aravamudan [EMAIL PROTECTED] For the reasons explained, I'd really like to nack Tony's patch. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patch: Fix regression. Make hot unlplug of CPU0 work again.
On Fri, Oct 05, 2007 at 05:05:21PM, Tony Breeds wrote: On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote: Early in the 2.6.23 cycle we broke the ability to offline cpu0 (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by ensuring that the (xics) default irq server, will not be 0 when taking cpu0 offline. Also catches a use of irq, when virq should be used (I think that the last one). Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go back to the drawing board. Reviewing the first patch, xics_set_affinity no longer looks at the cpu_mask arg, instead get_irq_server reads it from the irq descriptor. Signed-off-by: Milton Miller [EMAIL PROTECTED] --- On top of tonys patch (13926) I don't have a system to test hotplug, so this is only compile tested. A more complete fix might be to pass the cpu_mask struct to get_irq_server, but kernel/irq/manage.c currently sets the descriptor first. Index: kernel/arch/powerpc/platforms/pseries/xics.c === --- kernel.orig/arch/powerpc/platforms/pseries/xics.c 2007-10-05 11:37:01.0 -0500 +++ kernel/arch/powerpc/platforms/pseries/xics.c2007-10-05 11:37:16.0 -0500 @@ -890,8 +890,8 @@ void xics_migrate_irqs_away(void) virq, cpu); /* Reset affinity to all cpus */ - desc-chip-set_affinity(virq, CPU_MASK_ALL); irq_desc[virq].affinity = CPU_MASK_ALL; + desc-chip-set_affinity(virq, CPU_MASK_ALL); unlock: spin_unlock_irqrestore(desc-lock, flags); } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH respin 0/7] MPC8568E-MDS related patches
Hello Kumar, This is respin of MPC8568E-MDS patches, on top of master branch as of today. If there are no objections against SPI patch, please Ack it, thus David could pick it up. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine
Currently, all QE SPI controllers are almost the same comparing to MPC83xx's, thus let's use that driver for them. Tested to work on MPC85xx in loopback mode. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- This is respin. Hope this time it will get ack from the PowerPC team. drivers/spi/Kconfig | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index b915711..a77ede5 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC Controller in master SPI mode. config SPI_MPC83xx - tristate Freescale MPC83xx SPI controller - depends on SPI_MASTER PPC_83xx EXPERIMENTAL + tristate Freescale MPC83xx/QUICC Engine SPI controller + depends on SPI_MASTER (PPC_83xx || QUICC_ENGINE) EXPERIMENTAL select SPI_BITBANG help - This enables using the Freescale MPC83xx SPI controller in master - mode. + This enables using the Freescale MPC83xx and QUICC Engine SPI + controllers in master mode. Note, this driver uniquely supports the SPI controller on the MPC83xx - family of PowerPC processors. The MPC83xx uses a simple set of shift - registers for data (opposed to the CPM based descriptor model). + family of PowerPC processors, plus processors with QUICC Engine + technology. This driver uses a simple set of shift registers for data + (opposed to the CPM based descriptor model). config SPI_OMAP_UWIRE tristate OMAP1 MicroWire -- 1.5.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/7] [POWERPC] mpc85xx_mds: reset UCC ethernet properly
Apart from that the current code doesn't compile it's also
meaningless with regard to the MPC8568E-MDS' BCSR.
This patch used to reset UCCs properly.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 57e840a..6913e99 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -113,18 +113,22 @@ static void __init mpc85xx_mds_setup_arch(void)
}
if (bcsr_regs) {
- u8 bcsr_phy;
-
- /* Reset the Ethernet PHY */
- bcsr_phy = in_be8(bcsr_regs[9]);
- bcsr_phy = ~0x20;
- out_be8(bcsr_regs[9], bcsr_phy);
-
- udelay(1000);
-
- bcsr_phy = in_be8(bcsr_regs[9]);
- bcsr_phy |= 0x20;
- out_be8(bcsr_regs[9], bcsr_phy);
+#define BCSR_UCC1_GETH_EN (0x1 7)
+#define BCSR_UCC2_GETH_EN (0x1 7)
+#define BCSR_UCC1_MODE_MSK (0x3 4)
+#define BCSR_UCC2_MODE_MSK (0x3 0)
+
+ /* Turn off UCC1 UCC2 */
+ clrbits8(bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ clrbits8(bcsr_regs[9], BCSR_UCC2_GETH_EN);
+
+ /* Mode is RGMII, all bits clear */
+ clrbits8(bcsr_regs[11], BCSR_UCC1_MODE_MSK |
+BCSR_UCC2_MODE_MSK);
+
+ /* Turn UCC1 UCC2 on */
+ setbits8(bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ setbits8(bcsr_regs[9], BCSR_UCC2_GETH_EN);
iounmap(bcsr_regs);
}
--
1.5.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/7] [POWERPC] QE pario: support for MPC85xx layout
8 bytes padding required to match MPC85xx registers layout.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Reviewed-by: Kim Phillips [EMAIL PROTECTED]
---
arch/powerpc/sysdev/qe_lib/qe_io.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c
b/arch/powerpc/sysdev/qe_lib/qe_io.c
index a114cb0..e53ea4d 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_io.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
@@ -36,6 +36,9 @@ struct port_regs {
__be32 cpdir2; /* Direction register */
__be32 cppar1; /* Pin assignment register */
__be32 cppar2; /* Pin assignment register */
+#ifdef CONFIG_PPC_85xx
+ u8 pad[8];
+#endif
};
static struct port_regs *par_io = NULL;
--
1.5.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/7] [POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
set_irq_chained_handler overwrites MPIC's handle_irq function
(handle_fasteoi_irq) thus MPIC never gets eoi event from the
cascaded IRQ. This situation hangs MPIC on MPC8568E.
To solve this problem efficiently, QEIC needs pluggable handlers,
specific to the underlaying interrupt controller.
Patch extends qe_ic_init() function to accept low and high interrupt
handlers. To avoid #ifdefs, stack of interrupt handlers specified in
the header file and functions are marked 'static inline', thus
handlers are compiled-in only if actually used (in the board file).
Another option would be to lookup for parent controller and
automatically detect handlers (will waste text size because of
never used handlers, so this option abolished).
qe_ic_init() also changed in regard to support multiplexed high/low
lines as found in MPC8568E-MDS, plus qe_ic_cascade_muxed_mpic()
handler implemented appropriately.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/platforms/83xx/mpc832x_mds.c |2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c |2 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c |2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c| 29 +++-
include/asm-powerpc/qe_ic.h | 68 -
6 files changed, 78 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c
b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index b8d8c91..972fa85 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -140,7 +140,7 @@ static void __init mpc832x_sys_init_IRQ(void)
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index 4da0698..fbca336 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -151,7 +151,7 @@ void __init mpc832x_rdb_init_IRQ(void)
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0b18a75..0f3855c 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -147,7 +147,7 @@ static void __init mpc836x_mds_init_IRQ(void)
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 00f4c3a..57e840a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -180,7 +180,7 @@ static void __init mpc85xx_mds_pic_init(void)
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c
b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 9a2d1ed..e1c0fd6 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -321,25 +321,9 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
return irq_linear_revmap(qe_ic-irqhost, irq);
}
-void qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
-{
- struct qe_ic *qe_ic = desc-handler_data;
- unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
-
- if (cascade_irq != NO_IRQ)
- generic_handle_irq(cascade_irq);
-}
-
-void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
-{
- struct qe_ic *qe_ic = desc-handler_data;
- unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
-
- if (cascade_irq != NO_IRQ)
- generic_handle_irq(cascade_irq);
-}
-
-void __init qe_ic_init(struct device_node *node, unsigned int flags)
+void __init qe_ic_init(struct device_node *node, unsigned int flags,
+ void (*low_handler)(unsigned int irq, struct irq_desc *desc),
+ void (*high_handler)(unsigned int irq, struct irq_desc *desc))
{
struct qe_ic *qe_ic;
struct resource res;
@@ -399,11 +383,12 @@ void __init qe_ic_init(struct device_node *node, unsigned
int flags)
qe_ic_write(qe_ic-regs, QEIC_CICR, temp);
set_irq_data(qe_ic-virq_low, qe_ic);
- set_irq_chained_handler(qe_ic-virq_low, qe_ic_cascade_low);
+
[PATCH 4/7] [POWERPC] mpc8568mds: update dts to be able to use UCCs
1. UCC1's RX_DV pin is 16, not 15;
2. UCC1's phy is at 0x7, not 0x1. Schematics says 0x7, and recent
u-boot also using 0x7.
3. Use gianfar's (eTSEC) mdio bus. This is hardware default setup.
4. tx-clock should be CLK16 (GE125, PB31);
5. phy-connection-type is RGMII-ID;
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8568mds.dts | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index 6ac134a..b4aa5e7 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -104,10 +104,10 @@
device_type = mdio;
compatible = gianfar;
reg = 24520 20;
- phy0: [EMAIL PROTECTED] {
+ phy0: [EMAIL PROTECTED] {
interrupt-parent = mpic;
interrupts = 1 1;
- reg = 0;
+ reg = 7;
device_type = ethernet-phy;
};
phy1: [EMAIL PROTECTED] {
@@ -242,7 +242,7 @@
4 1a 2 0 2 0 /* RxD7 */
4 0b 1 0 2 0 /* TX_EN */
4 18 1 0 2 0 /* TX_ER */
- 4 0f 2 0 2 0 /* RX_DV */
+ 4 10 2 0 2 0 /* RX_DV */
4 1e 2 0 2 0 /* RX_ER */
4 11 2 0 2 0 /* RX_CLK */
4 13 1 0 2 0 /* GTX_CLK */
@@ -334,10 +334,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 0;
- tx-clock = 19;
- phy-handle = qe_phy0;
- phy-connection-type = gmii;
+ tx-clock = 20;
pio-handle = pio1;
+ phy-handle = phy0;
+ phy-connection-type = rgmii-id;
};
[EMAIL PROTECTED] {
@@ -356,10 +356,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 0;
- tx-clock = 14;
- phy-handle = qe_phy1;
- phy-connection-type = gmii;
+ tx-clock = 20;
pio-handle = pio2;
+ phy-handle = phy1;
+ phy-connection-type = rgmii-id;
};
[EMAIL PROTECTED] {
@@ -371,10 +371,10 @@
/* These are the same PHYs as on
* gianfar's MDIO bus */
- qe_phy0: [EMAIL PROTECTED] {
+ qe_phy0: [EMAIL PROTECTED] {
interrupt-parent = mpic;
interrupts = 1 1;
- reg = 0;
+ reg = 7;
device_type = ethernet-phy;
};
qe_phy1: [EMAIL PROTECTED] {
--
1.5.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote: Having the link address jump around depending on the size of the kernel or zImage is wrong IMHO. It just screams weird can't boot issues. We need a way to specify exactly where we want the zImage linked no matter what the kernel or zImage size. Why? The zImage is relocatable. It doesn't matter where it's linked. Also, being able to control the link address (that is, the download address with some firmwares) is not a u-boot specific issue and we shouldn't make a u-boot specific solution. How is this a u-boot specific solution? The more general problem is that some firmwares examine the ELF header and download the zImage to address it was linked at. Some firmwares let you override this but some don't and those are the problem ones. That's not the more general problem; it's the same problem with a different file format. I still like my idea best. I haven't coded yet it so I don't have a patch but this is what I mean: 1) add a config option (default 4MB) for the link address 2) add a parameter to the wrapper script thru which we pass the value in the config option 3) the wrapper script changes the VMA/LMA to the address specified (objcopy --change-addresses=some math to get correct incr ?). I'd much rather it be automatic than require the user to guess an appropriate value (and be aware in the first place that it needs to be set). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8568mds.dts |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index b4aa5e7..5439437 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -410,7 +410,7 @@
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
interrupt-map-mask = f800 0 0 7;
interrupt-map =
/* IDSEL 0x12 AD18 */
@@ -434,13 +434,13 @@
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
- reg = 8000 1000;
+ reg = e0008000 1000;
compatible = fsl,mpc8540-pci;
device_type = pci;
};
/* PCI Express */
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
interrupt-map-mask = f800 0 0 7;
interrupt-map =
@@ -459,7 +459,7 @@
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
- reg = a000 1000;
+ reg = e000a000 1000;
compatible = fsl,mpc8548-pcie;
device_type = pci;
[EMAIL PROTECTED] {
--
1.5.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
Hello.
Anton Vorontsov wrote:
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the soc type node?
I don't suppose the PCI controllers could hang off the root node... :-/
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index b4aa5e7..5439437 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -410,7 +410,7 @@
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
interrupt-map-mask = f800 0 0 7;
interrupt-map =
/* IDSEL 0x12 AD18 */
@@ -434,13 +434,13 @@
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
- reg = 8000 1000;
+ reg = e0008000 1000;
compatible = fsl,mpc8540-pci;
device_type = pci;
};
/* PCI Express */
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
interrupt-map-mask = f800 0 0 7;
interrupt-map =
@@ -459,7 +459,7 @@
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
- reg = a000 1000;
+ reg = e000a000 1000;
compatible = fsl,mpc8548-pcie;
device_type = pci;
[EMAIL PROTECTED] {
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote: Hello. Anton Vorontsov wrote: Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix PCI/PCIe nodes, but actually it broke them even harder. ;-) Of course. But shouldn't those be the subnoses of the soc type node? Nope. PCI's ranges = ; isn't in the SOC address space. Valentine Barshak posted a patch titled [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci that started using of_translate_address() for ranges, and of_translate_address() will not work if PCI placed in the SOC node. Not sure if that patch applied or not, though. Good luck, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
Benjamin Herrenschmidt wrote: Depends on interpretation. IIRC currently the same die is used for 440EPx and 440GRx. I could be wrong here though and it is just a bug in the chip. But anyway we should support this somehow. Could be that I missed this in the current 440GRx (Rainier) arch/ppc support too. I have to admit, that no clever solution comes to my mind right away though. We can always come up with some kind of runtime detection, by turning on MSR:FP, issuing an fp instruction and catching the illegal instruction fault if any :-) Ben. Is it OK to workaround the GRX/EPX having the same PVR issue using device tree? Say, check the PVR value and if we have 440EPx PVR, but 440GRX node in the device tree, fix the cputable entry and omit FPU initialization code. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote: On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote: Hello. Anton Vorontsov wrote: Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix PCI/PCIe nodes, but actually it broke them even harder. ;-) Of course. But shouldn't those be the subnoses of the soc type node? Nope. PCI's ranges = ; isn't in the SOC address space. Valentine Barshak posted a patch titled [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci that started using of_translate_address() for ranges, and of_translate_address() will not work if PCI placed in the SOC node. Not sure if that patch applied or not, though. I'm confused, what's the actual issue with PCI that this patch addresses? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Fri, Oct 05, 2007 at 12:30:54PM -0500, Scott Wood wrote: On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote: Having the link address jump around depending on the size of the kernel or zImage is wrong IMHO. It just screams weird can't boot issues. We need a way to specify exactly where we want the zImage linked no matter what the kernel or zImage size. Why? Why? Because its only safe to download a zImage to certain safe locations. Where those safe locations are vary by firmware, firmware version, and zImage size. This is the issue we're discussing. I've already explained _why_ the link address matters WRT where its downloaded. The zImage is relocatable. It doesn't matter where it's linked. We know...and a zImage running at an address it wasn't linked at is not the issue. Also, being able to control the link address (that is, the download address with some firmwares) is not a u-boot specific issue and we shouldn't make a u-boot specific solution. How is this a u-boot specific solution? Because the hoops being jumped through in the patch(es) are to make u-boot happy and no other firmware. The more general problem is that some firmwares examine the ELF header and download the zImage to address it was linked at. Some firmwares let you override this but some don't and those are the problem ones. That's not the more general problem; it's the same problem with a different file format. True, I misspoke. I'll restate it this way: The more general problem is that some firmwares will only download to the address the zImage is linked at. So, we need to control what that link address is. I still like my idea best. I haven't coded yet it so I don't have a patch but this is what I mean: 1) add a config option (default 4MB) for the link address 2) add a parameter to the wrapper script thru which we pass the value in the config option 3) the wrapper script changes the VMA/LMA to the address specified (objcopy --change-addresses=some math to get correct incr ?). I'd much rather it be automatic than require the user to guess an appropriate value (and be aware in the first place that it needs to be set). Sure, automatic is nice; conjuring up the magic to make it work in all situations isn't. Having the link address--and therefore the download address on some systems--mysteriously and uncontrollably jump around based on the zImage size is asking for trouble. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH respin 0/7] MPC8568E-MDS related patches
On Oct 5, 2007, at 12:40 PM, Anton Vorontsov wrote: Hello Kumar, This is respin of MPC8568E-MDS patches, on top of master branch as of today. If there are no objections against SPI patch, please Ack it, thus David could pick it up. I've applied patches 1-5 however I'm not able to get UCC enet working on my board. Is there something special that has to be done? (I've got the card standalone, no MDS backplane). I'm using the 1.3.0-rc2 u-boot w/o any modifications. Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that works w/o any issue. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
On Fri, 2007-10-05 at 22:36 +0400, Valentine Barshak wrote: Benjamin Herrenschmidt wrote: Depends on interpretation. IIRC currently the same die is used for 440EPx and 440GRx. I could be wrong here though and it is just a bug in the chip. But anyway we should support this somehow. Could be that I missed this in the current 440GRx (Rainier) arch/ppc support too. I have to admit, that no clever solution comes to my mind right away though. We can always come up with some kind of runtime detection, by turning on MSR:FP, issuing an fp instruction and catching the illegal instruction fault if any :-) Ben. Is it OK to workaround the GRX/EPX having the same PVR issue using device tree? Say, check the PVR value and if we have 440EPx PVR, but 440GRX node in the device tree, fix the cputable entry and omit FPU initialization code. Fixing the CPU features based on the tree is definitely legit. We do that on pseries. In fact, with paulus latest patch, the cputable is __initdata and the cur CPU features is a -copy- which makes it even more legitimate to whack it. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
