[PATCH 5/4] [POWERPC] Exception numbers are not relevent to iSeries
so remove them from the macros. Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/platforms/iseries/exception.h |4 ++-- arch/powerpc/platforms/iseries/head.S | 24 2 files changed, 14 insertions(+), 14 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/arch/powerpc/platforms/iseries/exception.h b/arch/powerpc/platforms/iseries/exception.h index 5b3f285..ced45a8 100644 --- a/arch/powerpc/platforms/iseries/exception.h +++ b/arch/powerpc/platforms/iseries/exception.h @@ -34,7 +34,7 @@ ori r10,r10,MSR_RI; \ mtmsrd r10,1 -#define STD_EXCEPTION_ISERIES(n, label, area) \ +#define STD_EXCEPTION_ISERIES(label, area) \ .globl label##_iSeries; \ label##_iSeries: \ HMT_MEDIUM; \ @@ -43,7 +43,7 @@ label##_iSeries: \ EXCEPTION_PROLOG_ISERIES_1; \ b label##_common -#define MASKABLE_EXCEPTION_ISERIES(n, label) \ +#define MASKABLE_EXCEPTION_ISERIES(label) \ .globl label##_iSeries; \ label##_iSeries: \ HMT_MEDIUM; \ diff --git a/arch/powerpc/platforms/iseries/head.S b/arch/powerpc/platforms/iseries/head.S index e9a3435..5381038 100644 --- a/arch/powerpc/platforms/iseries/head.S +++ b/arch/powerpc/platforms/iseries/head.S @@ -88,7 +88,7 @@ iSeries_secondary_smp_loop: /*** ISeries-LPAR interrupt handlers ***/ - STD_EXCEPTION_ISERIES(0x200, machine_check, PACA_EXMC) + STD_EXCEPTION_ISERIES(machine_check, PACA_EXMC) .globl data_access_iSeries data_access_iSeries: @@ -137,7 +137,7 @@ data_access_slb_iSeries: ld r12,LPPACASRR1(r12) b .slb_miss_realmode - STD_EXCEPTION_ISERIES(0x400, instruction_access, PACA_EXGEN) + STD_EXCEPTION_ISERIES(instruction_access, PACA_EXGEN) .globl instruction_access_slb_iSeries instruction_access_slb_iSeries: @@ -176,13 +176,13 @@ slb_miss_user_iseries: b slb_miss_user_common #endif - MASKABLE_EXCEPTION_ISERIES(0x500, hardware_interrupt) - STD_EXCEPTION_ISERIES(0x600, alignment, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0x700, program_check, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0x800, fp_unavailable, PACA_EXGEN) - MASKABLE_EXCEPTION_ISERIES(0x900, decrementer) - STD_EXCEPTION_ISERIES(0xa00, trap_0a, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0xb00, trap_0b, PACA_EXGEN) + MASKABLE_EXCEPTION_ISERIES(hardware_interrupt) + STD_EXCEPTION_ISERIES(alignment, PACA_EXGEN) + STD_EXCEPTION_ISERIES(program_check, PACA_EXGEN) + STD_EXCEPTION_ISERIES(fp_unavailable, PACA_EXGEN) + MASKABLE_EXCEPTION_ISERIES(decrementer) + STD_EXCEPTION_ISERIES(trap_0a, PACA_EXGEN) + STD_EXCEPTION_ISERIES(trap_0b, PACA_EXGEN) .globl system_call_iSeries system_call_iSeries: @@ -191,9 +191,9 @@ system_call_iSeries: EXCEPTION_PROLOG_ISERIES_1 b system_call_common - STD_EXCEPTION_ISERIES( 0xd00, single_step, PACA_EXGEN) - STD_EXCEPTION_ISERIES( 0xe00, trap_0e, PACA_EXGEN) - STD_EXCEPTION_ISERIES( 0xf00, performance_monitor, PACA_EXGEN) + STD_EXCEPTION_ISERIES(single_step, PACA_EXGEN) + STD_EXCEPTION_ISERIES(trap_0e, PACA_EXGEN) + STD_EXCEPTION_ISERIES(performance_monitor, PACA_EXGEN) decrementer_iSeries_masked: /* We may not have a valid TOC pointer in here. */ -- 1.5.2.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/7 v2] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
On Fri, 17 Aug 2007 13:17:18 -0500
Scott Wood wrote:
The existing OF glue code was crufty and broken. Rather than fix it,
it will be removed, and the ethernet driver now talks to the device
tree directly.
A bit short description, I'd rather expect some specific improvements list,
that are now up and running using device tree. Or if it is just move to new
infrastucture, let's state that, too.
Some other notes below.
The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
platforms are dropped from arch/ppc (which will hopefully be soon),
and existing arch/powerpc boards that I wasn't able to test on for
this patchset get converted (which should be even sooner).
mii-bitbang.c now also uses the generic bitbang code.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
Sorry, the previous version of this patch had bb_ops in the wrong
place, and wouldn't build when not using the new binding.
drivers/net/fs_enet/Kconfig|1 +
drivers/net/fs_enet/fs_enet-main.c | 286 ++--
drivers/net/fs_enet/fs_enet.h | 55 +-
drivers/net/fs_enet/mac-fcc.c | 89 ++--
drivers/net/fs_enet/mac-fec.c | 23 ++-
drivers/net/fs_enet/mac-scc.c | 55 +++--
drivers/net/fs_enet/mii-bitbang.c | 438
---
drivers/net/fs_enet/mii-fec.c | 140 -
include/linux/fs_enet_pd.h |5 + 9 files changed, 740
insertions(+), 352 deletions(-)
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index e27ee21..2765e49 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -11,6 +11,7 @@ config FS_ENET_HAS_SCC
config FS_ENET_HAS_FCC
bool Chip has an FCC usable for ethernet
depends on FS_ENET CPM2
+ select MDIO_BITBANG
default y
config FS_ENET_HAS_FEC
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c index 0ec30a8..7bf29a2 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -44,12 +44,18 @@
#include asm/irq.h
#include asm/uaccess.h
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+#include linux/of_platform.h
+#endif
+
#include fs_enet.h
/*/
+#ifndef CONFIG_PPC_CPM_NEW_BINDING
static char version[] __devinitdata =
DRV_MODULE_NAME .c:v DRV_MODULE_VERSION (
DRV_MODULE_RELDATE ) \n; +#endif
MODULE_AUTHOR(Pantelis Antoniou [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Freescale Ethernet Driver);
@@ -953,6 +959,7 @@ static int fs_ioctl(struct net_device *dev,
struct ifreq *rq, int cmd) extern int fs_mii_connect(struct
net_device *dev); extern void fs_mii_disconnect(struct net_device
*dev);
+#ifndef CONFIG_PPC_CPM_NEW_BINDING
static struct net_device *fs_init_instance(struct device *dev,
struct fs_platform_info *fpi)
{
@@ -1132,6 +1139,7 @@ static int fs_cleanup_instance(struct
net_device *ndev)
return 0;
}
+#endif
/**/
@@ -1140,35 +1148,279 @@ void *fs_enet_immap = NULL;
static int setup_immap(void)
{
- phys_addr_t paddr = 0;
- unsigned long size = 0;
-
#ifdef CONFIG_CPM1
- paddr = IMAP_ADDR;
- size = 0x1; /* map 64K */
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+ fs_enet_immap = mpc8xx_immr;
+#else
+ fs_enet_immap = ioremap(IMAP_ADDR, 0x4000);
+ WARN_ON(!fs_enet_immap);
#endif
-
-#ifdef CONFIG_CPM2
- paddr = CPM_MAP_ADDR;
- size = 0x4; /* map 256 K */
+#elif defined(CONFIG_CPM2)
+ fs_enet_immap = cpm2_immr;
#endif
- fs_enet_immap = ioremap(paddr, size);
- if (fs_enet_immap == NULL)
- return -EBADF; /* XXX ahem; maybe just
BUG_ON? */
return 0;
}
+#ifndef CONFIG_PPC_CPM_NEW_BINDING
static void cleanup_immap(void)
{
- if (fs_enet_immap != NULL) {
- iounmap(fs_enet_immap);
- fs_enet_immap = NULL;
- }
+#if defined(CONFIG_CPM1)
+ iounmap(fs_enet_immap);
+#endif
}
+#endif
/**/
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+static int __devinit find_phy(struct device_node *np,
+ struct fs_platform_info *fpi)
+{
+ struct device_node *phynode, *mdionode;
+ struct resource res;
+ int ret = 0, len;
+
+ const u32 *data = of_get_property(np, phy-handle, len);
+ if (!data || len != 4)
+ return -EINVAL;
+
+ phynode = of_find_node_by_phandle(*data);
+ if (!phynode)
+ return -EINVAL;
+
+ mdionode = of_get_parent(phynode);
+ if (!phynode)
+ goto out_put_phy;
+
+ ret = of_address_to_resource(mdionode, 0, res);
+ if (ret)
+ goto out_put_mdio;
+
+ data = of_get_property(phynode,
OF /chosen/initrd,* variables - patch, official?
Hi guys, Just a query here, there was a patch for /chosen/initrd,start and initrd,end variables gained from firmware or so, which allowed booting without getting those values into r3/r4, does anyone know the maintainer/author of that patch? Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine it's fairly useful (at least it is to me).. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF /chosen/initrd,* variables - patch, official?
On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote: Damn, I should use patchwork more efficiently; http://patchwork.ozlabs.org/linuxppc/patch?q=initrdfilter=noneid=12168 Does anyone have any suggestion on the best way to integrate this so that it just works on OF platforms? It seems only to be usable way too late in boot to work, this code would have to be called in boot/main.c which seems relatively.. impossible to achieve.. or called in some specialised platform init code.. It would have to be called from platform_init(). If called in main() it would clobber any other platform-specific initialization of the initrd parameters in loader_info. I hacked up a patch initially before I saw Milton's work and did it all in main.c (and did the same to mkvmlinuz..) and it seemed to work okay there. I'm really curious as to the status and usefulness of this here.. :( -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[no subject]
Hai, I am using the kernel 2.6.21. In the file (arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In this function it will skip the host birdge. But in the arch/powepc directory we don't have that types of file and the function pciauto_bus_scan() also removed. I want to know where the function was moved in arch/powerpc directory ? How the host bridge was skip in the arch/powerpc directory. Thanks and Regards Ramesh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Skipping the host bridge in arch/powerpc
Hai, I am using the kernel 2.6.21. In the file (arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In this function it will skip the host birdge. But in the arch/powepc directory we don't have that types of file and the function pciauto_bus_scan() also removed. I want to know where the function was moved in arch/powerpc directory ? How the host bridge was skip in the arch/powerpc directory. -- View this message in context: http://www.nabble.com/Skipping-the-host-bridge-in-arch-powerpc-tf4304798.html#a12253417 Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote: On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote: Damn, I should use patchwork more efficiently; http://patchwork.ozlabs.org/linuxppc/patch?q=initrdfilter=noneid=12168 Does anyone have any suggestion on the best way to integrate this so that it just works on OF platforms? It seems only to be usable way too late in boot to work, this code would have to be called in boot/main.c which seems relatively.. impossible to achieve.. or called in some specialised platform init code.. It would have to be called from platform_init(). If called in main() it would clobber any other platform-specific initialization of the initrd parameters in loader_info. So just to get this straight.. platform_init would be the function called from md.init or would be better at md.setup_arch? My goal right now is get something for CHRP (Pegasos) and Efika and try not to cause problems for anything else, but also really try not to clutter the thing with config checks, platform checks etc. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF /chosen/initrd,* variables - patch, official?
On Tue, Aug 21, 2007 at 01:36:49PM +0100, Matt Sealey wrote: David Gibson wrote: On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote: Damn, I should use patchwork more efficiently; http://patchwork.ozlabs.org/linuxppc/patch?q=initrdfilter=noneid=12168 Does anyone have any suggestion on the best way to integrate this so that it just works on OF platforms? It seems only to be usable way too late in boot to work, this code would have to be called in boot/main.c which seems relatively.. impossible to achieve.. or called in some specialised platform init code.. It would have to be called from platform_init(). If called in main() it would clobber any other platform-specific initialization of the initrd parameters in loader_info. So just to get this straight.. platform_init would be the function called from md.init or would be better at md.setup_arch? Uh... no... this is in the bootwrapper, long before ppc_md even exists. platform_init() is called from arch/powerpc/boot/crt0.S, immediately before main(). My goal right now is get something for CHRP (Pegasos) and Efika and try not to cause problems for anything else, but also really try not to clutter the thing with config checks, platform checks etc. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote:
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody would be too disgusted or have any problems?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 2/2] [POWERPC] MPC832x_RDB: update dts to use SPI1 in QE, register mmc_spi stub
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing spidev
with mmc_spi.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc832x_rdb.dts |2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 50 +
2 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index e9c332f..1ac0025 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -211,7 +211,7 @@
reg = 4c0 40;
interrupts = 2;
interrupt-parent = qeic;
- mode = cpu;
+ mode = cpu-qe;
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index e021b08..cf58d06 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -15,6 +15,7 @@
*/
#include linux/pci.h
+#include linux/spi/spi.h
#include asm/of_platform.h
#include asm/time.h
@@ -24,6 +25,7 @@
#include asm/qe_ic.h
#include mpc83xx.h
+#include ../../sysdev/fsl_soc.h
#undef DEBUG
#ifdef DEBUG
@@ -32,6 +34,54 @@
#define DBG(fmt...)
#endif
+extern int par_io_data_set(u8 port, u8 pin, u8 val);
+extern int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
+int assignment, int has_irq);
+
+static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
+{
+ pr_debug(%s %d %d\n, __func__, cs, polarity);
+ par_io_data_set(3, 13, polarity);
+}
+
+static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
+{
+ pr_debug(%s %d %d\n, __func__, cs, polarity);
+ par_io_data_set(3, 13, !polarity);
+}
+
+static struct spi_board_info mpc832x_spi_boardinfo = {
+ .bus_num = 0x4c0,
+ .chip_select = 0,
+ .max_speed_hz = 5000,
+ /*
+* XXX: This is spidev (spi in userspace) stub, should
+* be replaced by mmc_spi when mmc_spi will hit mainline.
+*/
+ .modalias = spidev,
+};
+
+static int __init mpc832x_spi_init(void)
+{
+ if (!machine_is(mpc832x_rdb))
+ return 0;
+
+ par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
+ par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
+ par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
+ par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
+
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS,O */
+ par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
+ par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
+
+ return fsl_spi_init(mpc832x_spi_boardinfo, 1,
+ mpc83xx_spi_activate_cs,
+ mpc83xx_spi_deactivate_cs);
+}
+
+device_initcall(mpc832x_spi_init);
+
/*
*
* Setup the architecture
--
1.5.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF /chosen/initrd,* variables - patch, official?
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
David Gibson wrote:
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody would be too disgusted or have any problems?
Err.. at the end of what? Each platform has it's own version of
platform_init().
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote:
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
David Gibson wrote:
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody would be too disgusted or have any problems?
Err.. at the end of what? Each platform has it's own version of
platform_init().
arch/powerpc/boot/of.c since it's not really relevant to me for non-OF
platforms?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5 0/2] SPI support for fsl_soc and mpc832x_rdb
On Tue, Aug 21, 2007 at 05:45:37PM +0400, Anton Vorontsov wrote: Hi all, Thanks for the previous reviews, this is v4 against Linus' tree, as of today. Okay, here is brand-new, shiny v5. Today and only today it comes without section mismatch warnings, don't miss your chance. Get it free of charge! ;-) -- 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 v5 2/2] [POWERPC] MPC832x_RDB: update dts to use SPI1 in QE, register mmc_spi stub
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing spidev
with mmc_spi.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc832x_rdb.dts |2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 50 +
2 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index e9c332f..1ac0025 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -211,7 +211,7 @@
reg = 4c0 40;
interrupts = 2;
interrupt-parent = qeic;
- mode = cpu;
+ mode = cpu-qe;
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index e021b08..cf58d06 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -15,6 +15,7 @@
*/
#include linux/pci.h
+#include linux/spi/spi.h
#include asm/of_platform.h
#include asm/time.h
@@ -24,6 +25,7 @@
#include asm/qe_ic.h
#include mpc83xx.h
+#include ../../sysdev/fsl_soc.h
#undef DEBUG
#ifdef DEBUG
@@ -32,6 +34,54 @@
#define DBG(fmt...)
#endif
+extern int par_io_data_set(u8 port, u8 pin, u8 val);
+extern int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
+int assignment, int has_irq);
+
+static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
+{
+ pr_debug(%s %d %d\n, __func__, cs, polarity);
+ par_io_data_set(3, 13, polarity);
+}
+
+static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
+{
+ pr_debug(%s %d %d\n, __func__, cs, polarity);
+ par_io_data_set(3, 13, !polarity);
+}
+
+static struct spi_board_info mpc832x_spi_boardinfo = {
+ .bus_num = 0x4c0,
+ .chip_select = 0,
+ .max_speed_hz = 5000,
+ /*
+* XXX: This is spidev (spi in userspace) stub, should
+* be replaced by mmc_spi when mmc_spi will hit mainline.
+*/
+ .modalias = spidev,
+};
+
+static int __init mpc832x_spi_init(void)
+{
+ if (!machine_is(mpc832x_rdb))
+ return 0;
+
+ par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
+ par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
+ par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
+ par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
+
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS,O */
+ par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
+ par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
+
+ return fsl_spi_init(mpc832x_spi_boardinfo, 1,
+ mpc83xx_spi_activate_cs,
+ mpc83xx_spi_deactivate_cs);
+}
+
+device_initcall(mpc832x_spi_init);
+
/*
*
* Setup the architecture
--
1.5.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/20] bootwrapper: flatdevtree fixes
David Gibson wrote: On Mon, Aug 20, 2007 at 12:39:49PM -0500, Scott Wood wrote: 1. ft_create_node was returning the internal pointer rather than a phandle. 2. ft_find_device_rel was treating a top phandle of NULL as an error, rather than as the root of the tree. 3. Return the node's name when getprop() is called with the name property. Hrm. I'm not convinced. (1) certainly needs fixing. (2) is kind of unclear - there is an ft_find_device() after all for doing root-based searches. The point of #2 was as part of the fix to #1 -- otherwise, the same check for NULL would have to be moved into ft_create_node to conditionally call ft_find_device or ft_find_device_rel. The non-relative function should probably be removed, though. (3) I really dislike; I just don't see the point. It's needed by dt_get_path(). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 09/20] bootwrapper: Declare udelay() in ops.h.
David Gibson wrote: On Mon, Aug 20, 2007 at 12:39:55PM -0500, Scott Wood wrote: Declarations in various users are removed. Signed-off-by: Scott Wood [EMAIL PROTECTED] Hrm... it should go in a header, certainly, but I wonder if io.h would be more suitable than the already rather bloated ops.h. It's not really I/O either... Maybe we should make a misc.h to put stuff in that doesn't fit anywhere else and doesn't really warrant its own header file? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches for ppc?
On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote: It's not a question of indivudual files being copied over - things are done differently in arch/powerpc. Things are gradually being ported over to arch/powerpc as people get the time - that's why arch/ppc isn't gone yet. And to be blunt, one of the points of arch/powerpc vs. arch/ppc is to actually leave behind some stuff. If no one ports it, no one wants it. So am I alone in getting a mixed message from Linux community to embedded community? On the one hand we have people like GKH telling embedded people to stop being private company/device specific forks but to submit their hardware to the tree where it will be supported for free by the kernel hackers, saving us the chore of supporting our code through all the kernel changes and forever chasing it. On the other hand we have people telling us that because we are too lazy to support our code the kernel guys aren't going to pull it forward for us. So in fact people 3rd party people like me are in between real problems, we base our code on say a Freescale chip, who submit to the kernel to save their support issues and we base our code on that. Now, the Freescale guys are too busy porting their latest chips across the PPC/Powerpc divide to port the old stuff so it gets left behind. That old stuff is still selling and the people who based code on it had the expectation that the code would continue to be supported. So now I'm being told not only to port my stuff or lose it but now also port freescale's stuff or lose it. And then we get beaten up because we stayed with ancient stuff like 2.6.21!!! Not picking on Freescale, or Segher, just trying to wave the flag, lots of people want it, they are just not all in a position to save it because we embedded people are by nature a fractured community of niche players with products that don't turn over with out customers every six months, some people will want to buy a product for years... And yes I do understand the Linux kernel hackers are nothing more than a group of diverse people from many companies so why is embedded any different argument, I just don't have an answer right now other than it is. Cheers Phil Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/20] bootwrapper: Add 8xx cuboot support.
David Gibson wrote: On Mon, Aug 20, 2007 at 12:40:01PM -0500, Scott Wood wrote: This allows booting on legacy, non-device-tree aware versions of U-boot. Is this really sufficient for all 8xx platforms? It should be enough for all u-boot-based 8xx boards, barring some u-boot which needs special fixups (as is done in cuboot-pq2.c). If such a need arises, they can be added to cuboot-8xx.c (if they're generic enough to work on all boards, even if not actually needed) or to a board-specific platform file (which can coexist just fine with the generic 8xx one). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 20/20] bootwrapper: Add fsl_get_immr(), mpc885_get_clock(), and pq2_get_clocks().
David Gibson wrote: On Mon, Aug 20, 2007 at 12:40:13PM -0500, Scott Wood wrote: fsl_get_immr() is equivalent to the kernel's get_immrbase() function. I notice that this function assumes that P==V. Is that true for all relevant platforms at this point? Yes. If that ever changes, we'd probably need to add a virtual-immr or similar. mpc885_get_clock() transforms a crystal frequency into a system frequency according to the PLL register settings. pq2_get_clocks() does the same as the above for the PowerQUICC II, except that it produces several different clocks. I'd prefer if these functions worked analagously to the ibm440gp_fixup_clocks() function in ebony.c and fixed up the clock values in the device tree directly, rather than returning them (where the caller will presumably poke them into the device tree). I wanted to separate the register interpretation from the knowledge of where things are in the device tree. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches for ppc?
On Tue, 21 Aug 2007 09:11:24 -0700 Phil Terry [EMAIL PROTECTED] wrote: On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote: It's not a question of indivudual files being copied over - things are done differently in arch/powerpc. Things are gradually being ported over to arch/powerpc as people get the time - that's why arch/ppc isn't gone yet. And to be blunt, one of the points of arch/powerpc vs. arch/ppc is to actually leave behind some stuff. If no one ports it, no one wants it. So am I alone in getting a mixed message from Linux community to embedded community? I don't think so.. On the one hand we have people like GKH telling embedded people to stop being private company/device specific forks but to submit their hardware to the tree where it will be supported for free by the kernel hackers, saving us the chore of supporting our code through all the kernel changes and forever chasing it. Yes. Just submit it to the arch/powerpc tree instead of arch/ppc. But this is only an issue for the _initial_ submit, and only while the merge is on-going. On the other hand we have people telling us that because we are too lazy to support our code the kernel guys aren't going to pull it forward for us. That's more of a issue for _existing_ code, not new code. So in fact people 3rd party people like me are in between real problems, we base our code on say a Freescale chip, who submit to the kernel to save their support issues and we base our code on that. Now, the Freescale guys are too busy porting their latest chips across the PPC/Powerpc divide to port the old stuff so it gets left behind. Or maybe it's just not ported yet? That old stuff is still selling and the people who based code on it had the expectation that the code would continue to be supported. So now I'm being told not only to port my stuff or lose it but now also port freescale's stuff or lose it. Well... it's not really going away until June 2008. There's time. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches for ppc?
On Aug 21, 2007, at 11:11 AM, Phil Terry wrote: On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote: It's not a question of indivudual files being copied over - things are done differently in arch/powerpc. Things are gradually being ported over to arch/powerpc as people get the time - that's why arch/ppc isn't gone yet. And to be blunt, one of the points of arch/powerpc vs. arch/ppc is to actually leave behind some stuff. If no one ports it, no one wants it. So am I alone in getting a mixed message from Linux community to embedded community? On the one hand we have people like GKH telling embedded people to stop being private company/device specific forks but to submit their hardware to the tree where it will be supported for free by the kernel hackers, saving us the chore of supporting our code through all the kernel changes and forever chasing it. On the other hand we have people telling us that because we are too lazy to support our code the kernel guys aren't going to pull it forward for us. There is clearly a balance here. While I don't think too many people are going to disagree with GKH intent, there is a practicality about it. If no kernel hacker has access to a particular board that was supported in arch/ppc and no one seems to care about it than it seems to be a candidate to not move forward. So in fact people 3rd party people like me are in between real problems, we base our code on say a Freescale chip, who submit to the kernel to save their support issues and we base our code on that. Now, the Freescale guys are too busy porting their latest chips across the PPC/Powerpc divide to port the old stuff so it gets left behind. That old stuff is still selling and the people who based code on it had the expectation that the code would continue to be supported. So now I'm being told not only to port my stuff or lose it but now also port freescale's stuff or lose it. If there is some specific freescale board/chip that is being left behind that you're concerned about please let me know. And then we get beaten up because we stayed with ancient stuff like 2.6.21!!! Not picking on Freescale, or Segher, just trying to wave the flag, lots of people want it, they are just not all in a position to save it because we embedded people are by nature a fractured community of niche players with products that don't turn over with out customers every six months, some people will want to buy a product for years... And yes I do understand the Linux kernel hackers are nothing more than a group of diverse people from many companies so why is embedded any different argument, I just don't have an answer right now other than it is. I'd ask you to mention specific boards/chip/functionality rather than generic statements so we can actual be aware of things we're forgetting or are important to people that we are not aware of. The fact that arch/ppc is 'dead' has been posted on the lists numerous times to give people the opportunity to let us all know what's important to people. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/7 v2] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
Vitaly Bordug wrote:
On Fri, 17 Aug 2007 13:17:18 -0500
Scott Wood wrote:
The existing OF glue code was crufty and broken. Rather than fix it,
it will be removed, and the ethernet driver now talks to the device
tree directly.
A bit short description, I'd rather expect some specific improvements list,
that are now up and running using device tree. Or if it is just move to new
infrastucture, let's state that, too.
Some of specific binding changes (there are too many to exhaustively
list) are enumerated in the new CPM binding patch, which I'll send
after Kumar's include/asm-ppc patch goes in (since it modifies one of
those files).
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+static int __devinit find_phy(struct device_node *np,
+ struct fs_platform_info *fpi)
+{
+ struct device_node *phynode, *mdionode;
+ struct resource res;
+ int ret = 0, len;
+
+ const u32 *data = of_get_property(np, phy-handle, len);
+ if (!data || len != 4)
+ return -EINVAL;
+
+ phynode = of_find_node_by_phandle(*data);
+ if (!phynode)
+ return -EINVAL;
+
+ mdionode = of_get_parent(phynode);
+ if (!phynode)
+ goto out_put_phy;
+
+ ret = of_address_to_resource(mdionode, 0, res);
+ if (ret)
+ goto out_put_mdio;
+
+ data = of_get_property(phynode, reg, len);
+ if (!data || len != 4)
+ goto out_put_mdio;
+
+ snprintf(fpi-bus_id, 16, PHY_ID_FMT, res.start, *data);
+
+out_put_mdio:
+ of_node_put(mdionode);
+out_put_phy:
+ of_node_put(phynode);
+ return ret;
+}
And without phy node?
It returns -EINVAL. :-)
+#ifdef CONFIG_FS_ENET_HAS_FEC
+#define IS_FEC(match) ((match)-data == fs_fec_ops)
+#else
+#define IS_FEC(match) 0
+#endif
+
Since we're talking directly with device tree, why bother with CONFIG_ stuff?
We are able to figure it out from dts..
We are figuring it out from the DTS (that's what match-data is). I
just didn't want boards without a FEC to have to build in support for it
and waste memory.
+ fpi-rx_ring = 32;
+ fpi-tx_ring = 32;
+ fpi-rx_copybreak = 240;
+ fpi-use_napi = 0;
+ fpi-napi_weight = 17;
+
move params over to dts?
No. These aren't attributes of the hardware, they're choices the driver
makes about how much memory to use and how to interact with the rest of
the kernel.
+ ret = find_phy(ofdev-node, fpi);
+ if (ret)
+ goto out_free_fpi;
+
so we're hosed without phy node.
How is that different from the old code, where you're hosed without
fep-fpi-bus_id?
+static struct of_device_id fs_enet_match[] = {
+#ifdef CONFIG_FS_ENET_HAS_SCC
same nagging. Are we able to get rid of Kconfig arcane defining which SoC
currently plays the game for fs_enet?
No, it's still needed for mpc885ads to determine pin setup and
conflicting device tree node removal (though that could go away if the
device tree is changed to reflect the jumper settings).
It's also useful for excluding unwanted code. I don't like using
8xx/CPM2 as the decision point for that -- why should I build in
mac-scc.c if I have no intention of using an SCC ethernet (either
because my board doesn't have one, or because it's slow and conflicts
with other devices)?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches for ppc?
On Tue, Aug 21, 2007 at 10:12:17AM -0700, Phil Terry wrote: Sorry guys, this is probably the wrong forum and I didn't mean to sound like I was trashing anyones efforts here. I don't think it was taken that way -- rather, we want to know what hardware people are still using with recent kernels. Greg KH's offer was a bit over-idealistic; hacker-hours are a finite resource, and there's not much point spending it on hardware which is primarily installed in landfills. :-) The offer seems to be founded on the assumption that the user base of a given device among kernel hackers is proportional to the user base in the general population, which is less likely to be true with embedded hardware. Thus, we need feedback on which hardware is being actively developed on. But then I see comments from other people who I assume are in the same boat and the response is, no one uses that. Theres no demand for it. We're dropping that Its like when I go to a pub in England and ask for a pint of mild ale. We don't serve that here, there's no demand for it. Huh, didn't I just demand it? Yes, and if they found themselves repeating that answer on a regular basis, they might decide to add a tap. Again, non-finite resources. :-) So then I get worried, how do I know who's plan and schedule include/excludes my board/chip/issue? You ask. Cheers Phil (who now has to drink American Beer.) Mmm... beer... I just *hate* it when I have to drink a nice Rogue, Stone, Breckenridge, Victory, etc. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches for ppc?
So then I get worried, how do I know who's plan and schedule include/excludes my board/chip/issue? The arch/ppc - arch/powerpc changeover is exceptional for various reasons. First, it is a huge change taking multiple years to complete. Only recently it has been decided when to finally drop arch/ppc completely; and that's not going to happen until almost a year from now. Secondly, it really does change many things at the core. It is almost impossible for people without in-depth knowledge of specific hardware too correctly port support code for that hardware over those core changes, and certainly impossible to actually test the ported code. So the only sane approach was to only port the hardware support code people _did_ have access to. Which isn't to say the other platforms still in demand will be left behind of course, some are still being ported over, and there is nothing preventing such a port even after arch/ppc is dead and gone either. Thirdly, Greg KH is talking more about generic drivers (PCI device drivers, for example) than about low-level platform code; at least that's my impression. The good news is that in the arch/powerpc world much more of the low-level stuff will be abstracted away, or at least sanely abstracted at all, so in the future we won't have all that many problems making even the biggest core changes anymore. I was trying to raise that generic issue, which is why I tried to be generic. Didn't mean to gore anyones ox. Don't worry, you didn't offend anyone as far as I can see :-) All of the more generic stuff (e.g., CPU/SoC support) should be ported over soon enough (if not, shout); some more specific stuff (support for some specific board, etc.) you will have to do yourself, or find someone else to do it for you. And you can always ask for help here, we're all very helpful and friendly here (if you believe that ;-) ) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[2.6 patch] ppc .gitignore update
From: Grant Likely [EMAIL PROTECTED] arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- a/arch/ppc/.gitignore +++ b/arch/ppc/.gitignore @@ -1 +1 @@ -include +/include ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
@@ -42,7 +42,7 @@
#ifdef __KERNEL__
#ifdef CONFIG_SMP
#define smp_mb() mb()
-#define smp_rmb()rmb()
+#define smp_rmb()__asm__ __volatile__ (__stringify(LWSYNC) : : :
memory)
#define smp_wmb()eieio()
#define smp_read_barrier_depends() read_barrier_depends()
#else
I had to think about this one for awhile. It looks at first glance to be the
right
thing to do. But I do wonder how long rmb() has been lwsync and if as a
practical
matter that has caused any problems? If this isn't causing any problems maybe
there
is some loigic we are overlooking?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
@@ -42,7 +42,7 @@
#ifdef __KERNEL__
#ifdef CONFIG_SMP
#define smp_mb()mb()
-#define smp_rmb() rmb()
+#define smp_rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
memory)
#define smp_wmb() eieio()
#define smp_read_barrier_depends() read_barrier_depends()
#else
I had to think about this one for awhile. It looks at first glance to
be the right
thing to do. But I do wonder how long rmb() has been lwsync
Since the {ppc,ppc64} - powerpc merge.
and if as a practical matter that has caused any problems?
It has not as far as I know.
If this isn't causing any problems maybe there
is some loigic we are overlooking?
The I/O accessor functions enforce the necessary ordering
already I believe.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'fixes-2.6.23' branch
Please pull from 'fixes-2.6.23' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git fixes-2.6.23 to receive the following updates: arch/powerpc/sysdev/fsl_pci.c |2 ++ include/linux/pci_ids.h |6 -- 2 files changed, 6 insertions(+), 2 deletions(-) Kumar Gala (1): [POWERPC] Fix PCI Device ID for MPC8544/8533 processors commit 15f6ddc7d9cf96f2ee88897c7164198ed6e45a77 Author: Kumar Gala [EMAIL PROTECTED] Date: Tue Aug 21 19:15:31 2007 -0500 [POWERPC] Fix PCI Device ID for MPC8544/8533 processors The initial user manuals for MPC8544/8533 had some issues with properly documenting the device IDs for MPC8544/8533. These processors are almost identical and both show up on the reference boards. Fix up the quirks for PCIe support to handle MPC8533/E. Signed-off-by: Kumar Gala [EMAIL PROTECTED] diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c index 9fb0ce5..114c90f 100644 --- a/arch/powerpc/sysdev/fsl_pci.c +++ b/arch/powerpc/sysdev/fsl_pci.c @@ -251,6 +251,8 @@ DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8568E, quirk_fsl_pcie_transpare DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8568, quirk_fsl_pcie_transparent); DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8567E, quirk_fsl_pcie_transparent); DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8567, quirk_fsl_pcie_transparent); +DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533E, quirk_fsl_pcie_transparent); +DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533, quirk_fsl_pcie_transparent); DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544E, quirk_fsl_pcie_transparent); DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544, quirk_fsl_pcie_transparent); DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_transparent); diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 07fc574..8938d59 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2092,8 +2092,10 @@ #define PCI_DEVICE_ID_MPC8568 0x0021 #define PCI_DEVICE_ID_MPC8567E 0x0022 #define PCI_DEVICE_ID_MPC8567 0x0023 -#define PCI_DEVICE_ID_MPC8544E 0x0030 -#define PCI_DEVICE_ID_MPC8544 0x0031 +#define PCI_DEVICE_ID_MPC8533E 0x0030 +#define PCI_DEVICE_ID_MPC8533 0x0031 +#define PCI_DEVICE_ID_MPC8544E 0x0032 +#define PCI_DEVICE_ID_MPC8544 0x0033 #define PCI_DEVICE_ID_MPC8641 0x7010 #define PCI_DEVICE_ID_MPC8641D 0x7011 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 17/20] bootwrapper: Add PlanetCore firmware support.
On Tue, Aug 21, 2007 at 11:29:15AM -0500, Scott Wood wrote:
David Gibson wrote:
+void planetcore_prepare_table(char *table)
+{
+ int last_was_newline = 0;
+
+ while (*table != 10 || !last_was_newline) {
+ if (*table == 10) {
+ *table = 0;
+ last_was_newline = 1;
+ } else {
+ last_was_newline = 0;
+ }
+
+ table++;
+ }
Hrm.. this loop makes my brain hurt. It's correct as far as I can
determine what it's supposed to be doing, but I think there's got to
be a way to make what it's doing a little more obvious.
How about something like this:
char last = 0;
while (1) {
if (*table == '\n') {
*table = 0;
if (last == *table)
return;
}
last = *table++;
}
*thinks*
How about:
do {
if (*table == '\n')
*table = '\0';
table++;
} while (*(table-1) || (*table != '\n'));
*table = '\0';
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix race in the pasemi timebase calibration
Olof Johansson writes: Make sure the new timebase value is available by the time take_timebase completes. Otherwise take_timebase might race with give_timebase, causing severe badness when the value later is modified (think looong hang trying to catch up with a very large number of lost ticks). OK. @@ -61,6 +62,7 @@ static void __devinit pas_give_timebase( mtspr(SPRN_TBCTL, TBCTL_UPDATE_LOWER | (tb 0x)); mtspr(SPRN_TBCTL, TBCTL_UPDATE_UPPER | (tb 32)); mtspr(SPRN_TBCTL, TBCTL_RESTART); + timebase_avail = 1; No memory barrier before setting timebase_avail? Shouldn't there be one? Actually I don't understand that code at all. Your give_timebase seems to freeze the timebase, read it, set it to the same value and restart, all without synchronizing with the other cpu, and your take_timebase does nothing except print the timebase. How does that work? Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF /chosen/initrd,* variables - patch, official?
On Tue, Aug 21, 2007 at 03:24:52PM +0100, Matt Sealey wrote:
David Gibson wrote:
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
David Gibson wrote:
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody would be too disgusted or have any problems?
Err.. at the end of what? Each platform has it's own version of
platform_init().
arch/powerpc/boot/of.c since it's not really relevant to me for non-OF
platforms?
Err... it would have to be a somewhat strange OF implementation that
gives the linux,initrd-* properties sane values before entry... I
doubt we want to do this for all real OF systems.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/20] bootwrapper: Add 8xx cuboot support.
On Tue, Aug 21, 2007 at 11:20:21AM -0500, Scott Wood wrote: David Gibson wrote: On Mon, Aug 20, 2007 at 12:40:01PM -0500, Scott Wood wrote: This allows booting on legacy, non-device-tree aware versions of U-boot. Is this really sufficient for all 8xx platforms? It should be enough for all u-boot-based 8xx boards, barring some u-boot which needs special fixups (as is done in cuboot-pq2.c). If such a need arises, they can be added to cuboot-8xx.c (if they're generic enough to work on all boards, even if not actually needed) or to a board-specific platform file (which can coexist just fine with the generic 8xx one). Ok. Presumably our bd_t won't exactly line up for all 8xx (since it varies from platform to platform, yes?) - but I gather the only bits we use do match up. That's probably worth a comment, so that someone doesn't try using some later bd_t field which is only in the right place for some 8xx systems. Otherwise, Acked-by: David Gibson [EMAIL PROTECTED] -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
On Tue, Aug 21, 2007 at 09:43:17PM +0200, Segher Boessenkool wrote:
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
@@ -42,7 +42,7 @@
#ifdef __KERNEL__
#ifdef CONFIG_SMP
#define smp_mb() mb()
-#define smp_rmb() rmb()
+#define smp_rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
memory)
#define smp_wmb() eieio()
#define smp_read_barrier_depends() read_barrier_depends()
#else
I had to think about this one for awhile. It looks at first glance to
be the right
thing to do. But I do wonder how long rmb() has been lwsync
Since the {ppc,ppc64} - powerpc merge.
and if as a practical matter that has caused any problems?
It has not as far as I know.
If this isn't causing any problems maybe there
is some loigic we are overlooking?
The I/O accessor functions enforce the necessary ordering
already I believe.
Hmm, I never followed those discussions last year about IO ordering, and
I can't see where (if) it was documented anywhere :(
It appears that legacy code is handled by defining the old IO accessors to
be completely ordered, and introducing new __raw_ variants that are not
(OTOH, it seems like other architectures are implementing __raw prefix as
inorder unless there is a _relaxed postfix).
Drivers are definitely using these __raw_ accessors, and from a quick
look, they do appear to be hoping that *mb() is going to order access for
them.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Rework SMP timebase handoff for pasemi
Rework timebase handoff to play nice with configurations with more than
2 cores, as well as with CPU hotplug.
Previous scheme just pushed out the current timebase from the giving
core to all cores without caring if they wanted it or not, nor checking
if they'd taken it. The taking side didn't make sure the giving side
had provided a value yet either. In other words, it was completely broken.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: mainline/arch/powerpc/platforms/pasemi/setup.c
===
--- mainline.orig/arch/powerpc/platforms/pasemi/setup.c
+++ mainline/arch/powerpc/platforms/pasemi/setup.c
@@ -50,26 +50,30 @@ static void pas_restart(char *cmd)
#ifdef CONFIG_SMP
static DEFINE_SPINLOCK(timebase_lock);
+static unsigned long timebase;
static void __devinit pas_give_timebase(void)
{
- unsigned long tb;
-
spin_lock(timebase_lock);
mtspr(SPRN_TBCTL, TBCTL_FREEZE);
- tb = mftb();
- mtspr(SPRN_TBCTL, TBCTL_UPDATE_LOWER | (tb 0x));
- mtspr(SPRN_TBCTL, TBCTL_UPDATE_UPPER | (tb 32));
- mtspr(SPRN_TBCTL, TBCTL_RESTART);
+ isync();
+ timebase = get_tb();
spin_unlock(timebase_lock);
- pr_debug(pas_give_timebase: cpu %d gave tb %lx\n,
-smp_processor_id(), tb);
+
+ while (timebase)
+ barrier();
+ mtspr(SPRN_TBCTL, TBCTL_RESTART);
}
static void __devinit pas_take_timebase(void)
{
- pr_debug(pas_take_timebase: cpu %d has tb %lx\n,
-smp_processor_id(), mftb());
+ while (!timebase)
+ smp_rmb();
+
+ spin_lock(timebase_lock);
+ set_tb(timebase 32, timebase 0x);
+ timebase = 0;
+ spin_unlock(timebase_lock);
}
struct smp_ops_t pas_smp_ops = {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
If this isn't causing any problems maybe there
is some loigic we are overlooking?
The I/O accessor functions enforce the necessary ordering
already I believe.
Ah, it looks like you might be right, IO should appear to go in-order,
in
which case the rmb() would simply need to order cacheable loads.
Interesting
way to do things... are drivers simply not up to scratch enough to
allow
out of order IO?
The powerpc kernel needs to have full sync insns in every I/O
accessor in order to enforce all the ordering rules Linux demands.
It's a bloody shame, but the alternative would be to make the
barriers lots more expensive. A third alternative would be to
have barrier ops that do not order everything, but just A vs. B
for various choices of A and B (coherent accesses, MMIO accesses,
etc.)
Anyway, this raises another question -- if IO accessors have the right
ordering, why is wmb() not an lwsync as well? There appears to be many
more wmb() calls than rmb()...
Input MMIO accessors are {sync, load, stall pipeline until load came
back}.
That's a full ordering on both sides.
Output MMIO on the other hand is done with {sync, store}. Now since
wmb() has to order MMIO writes vs. main memory writes, we need a full
sync here. On some (most, all?) CPUs an eieio is actually enough btw.
The barrier insn could be put at the end of all MMIO write ops too,
but I believe that would be more expensive (in execution time; in code
size it definitely would be, of course).
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Check _PAGE_RW and _PAGE_PRESENT on kernel addresses.
Scott Wood writes: Previously, the TLB miss handlers assumed that pages above KERNELBASE are always present and read/write. This assumption is false in the case of CONFIG_DEBUG_PAGEALLOC. blt+112f + mfspr r2,SPRN_SRR1/* and MSR_PR bit from SRR1 */ + rlwinm r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */ lis r2,[EMAIL PROTECTED]/* if kernel address, use */ addir2,r2,[EMAIL PROTECTED] /* kernel page table */ - mfspr r1,SPRN_SRR1/* and MSR_PR bit from SRR1 */ - rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */ I don't see that just moving those two lines up changes anything. If you turned the rlwinm into an rlwimi (as you did in the DataStoreTLBMiss case) then it might make more sense. Is this just an oversight? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Move iSeries startup code out of head_64.S
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/kernel/head_64.S | 86 + arch/powerpc/platforms/iseries/Makefile|1 + arch/powerpc/platforms/iseries/exception.S | 114 include/asm-powerpc/ppc_asm.h | 14 4 files changed, 131 insertions(+), 84 deletions(-) create mode 100644 arch/powerpc/platforms/iseries/exception.S This version creates platforms/iseries/exception.S instead of head.S. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 1e6d9cc..97f089b 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -802,56 +802,6 @@ system_call_iSeries: STD_EXCEPTION_ISERIES( 0xe00, trap_0e, PACA_EXGEN) STD_EXCEPTION_ISERIES( 0xf00, performance_monitor, PACA_EXGEN) - .globl system_reset_iSeries -system_reset_iSeries: - mfspr r13,SPRN_SPRG3 /* Get paca address */ - mfmsr r24 - ori r24,r24,MSR_RI - mtmsrd r24 /* RI on */ - lhz r24,PACAPACAINDEX(r13) /* Get processor # */ - cmpwi 0,r24,0 /* Are we processor 0? */ - bne 1f - b .__start_initialization_iSeries /* Start up the first processor */ -1: mfspr r4,SPRN_CTRLF - li r5,CTRL_RUNLATCH/* Turn off the run light */ - andcr4,r4,r5 - mtspr SPRN_CTRLT,r4 - -1: - HMT_LOW -#ifdef CONFIG_SMP - lbz r23,PACAPROCSTART(r13) /* Test if this processor -* should start */ - sync - LOAD_REG_IMMEDIATE(r3,current_set) - sldir28,r24,3 /* get current_set[cpu#] */ - ldx r3,r3,r28 - addir1,r3,THREAD_SIZE - subir1,r1,STACK_FRAME_OVERHEAD - - cmpwi 0,r23,0 - beq iSeries_secondary_smp_loop /* Loop until told to go */ - bne __secondary_start /* Loop until told to go */ -iSeries_secondary_smp_loop: - /* Let the Hypervisor know we are alive */ - /* 8002 is a call to HvCallCfg::getLps, a harmless Hypervisor function */ - lis r3,0x8002 - rldicr r3,r3,32,15 /* r0 = (r3 32) 0x */ -#else /* CONFIG_SMP */ - /* Yield the processor. This is required for non-SMP kernels - which are running on multi-threaded machines. */ - lis r3,0x8000 - rldicr r3,r3,32,15 /* r3 = (r3 32) 0x */ - addir3,r3,18/* r3 = 0x8012 which is yield */ - li r4,0/* yield timed */ - li r5,-1 /* yield forever */ -#endif /* CONFIG_SMP */ - li r0,-1 /* r0=-1 indicates a Hypervisor call */ - sc /* Invoke the hypervisor via a system call */ - mfspr r13,SPRN_SPRG3 /* Put r13 back */ - b 1b /* If SMP not configured, secondaries -* loop forever */ - decrementer_iSeries_masked: /* We may not have a valid TOC pointer in here. */ li r11,1 @@ -1622,39 +1572,6 @@ _GLOBAL(generic_secondary_smp_init) b __secondary_start #endif -#ifdef CONFIG_PPC_ISERIES -_INIT_STATIC(__start_initialization_iSeries) - /* Clear out the BSS */ - LOAD_REG_IMMEDIATE(r11,__bss_stop) - LOAD_REG_IMMEDIATE(r8,__bss_start) - sub r11,r11,r8 /* bss size */ - addir11,r11,7 /* round up to an even double word */ - rldicl. r11,r11,61,3/* shift right by 3 */ - beq 4f - addir8,r8,-8 - li r0,0 - mtctr r11 /* zero this many doublewords */ -3: stdur0,8(r8) - bdnz3b -4: - LOAD_REG_IMMEDIATE(r1,init_thread_union) - addir1,r1,THREAD_SIZE - li r0,0 - stdur0,-STACK_FRAME_OVERHEAD(r1) - - LOAD_REG_IMMEDIATE(r2,__toc_start) - addir2,r2,0x4000 - addir2,r2,0x4000 - - bl .iSeries_early_setup - bl .early_setup - - /* relocation is on at this point */ - - b .start_here_common -#endif /* CONFIG_PPC_ISERIES */ - - _STATIC(__mmu_off) mfmsr r3 andi. r0,r3,MSR_IR|MSR_DR @@ -1902,6 +1819,7 @@ _GLOBAL(pmac_secondary_start) * r13 = paca virtual address * SPRG3 = paca virtual address */ + .globl __secondary_start __secondary_start: /* Set thread priority to MEDIUM */ HMT_MEDIUM @@ -2032,7 +1950,7 @@ _INIT_STATIC(start_here_multiplatform) b . /* prevent speculative execution */ /* This is where all platforms converge
[PATCH] [POWERPC] Move the exception macros into a header file
It makes head_64.S a bit more readable and will allow us to move the iSeries excetions elsewhere. This also removes the last line of the comment: * The following macros define the code that appears as * the prologue to each of the exception handlers. They * are split into two parts to allow a single kernel binary * to be used for pSeries and iSeries. * LOL. One day... - paulus Anything is possible. :-) Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/kernel/head_64.S | 336 + include/asm-powerpc/exception.h | 356 +++ 2 files changed, 357 insertions(+), 335 deletions(-) create mode 100644 include/asm-powerpc/exception.h -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 97f089b..fe6122b 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -35,6 +35,7 @@ #include asm/thread_info.h #include asm/firmware.h #include asm/page_64.h +#include asm/exception.h #define DO_SOFT_DISABLE @@ -145,344 +146,9 @@ exception_marker: .text /* - * The following macros define the code that appears as - * the prologue to each of the exception handlers. They - * are split into two parts to allow a single kernel binary - * to be used for pSeries and iSeries. - * LOL. One day... - paulus - */ - -/* - * We make as much of the exception code common between native - * exception handlers (including pSeries LPAR) and iSeries LPAR - * implementations as possible. - */ - -/* * This is the start of the interrupt handlers for pSeries * This code runs with relocation off. */ -#define EX_R9 0 -#define EX_R10 8 -#define EX_R11 16 -#define EX_R12 24 -#define EX_R13 32 -#define EX_SRR040 -#define EX_DAR 48 -#define EX_DSISR 56 -#define EX_CCR 60 -#define EX_R3 64 -#define EX_LR 72 - -/* - * We're short on space and time in the exception prolog, so we can't - * use the normal SET_REG_IMMEDIATE macro. Normally we just need the - * low halfword of the address, but for Kdump we need the whole low - * word. - */ -#ifdef CONFIG_CRASH_DUMP -#define LOAD_HANDLER(reg, label) \ - orisreg,reg,(label)@h; /* virt addr of handler ... */ \ - ori reg,reg,(label)@l; /* .. and the rest */ -#else -#define LOAD_HANDLER(reg, label) \ - ori reg,reg,(label)@l; /* virt addr of handler ... */ -#endif - -/* - * Equal to EXCEPTION_PROLOG_PSERIES, except that it forces 64bit mode. - * The firmware calls the registered system_reset_fwnmi and - * machine_check_fwnmi handlers in 32bit mode if the cpu happens to run - * a 32bit application at the time of the event. - * This firmware bug is present on POWER4 and JS20. - */ -#define EXCEPTION_PROLOG_PSERIES_FORCE_64BIT(area, label) \ - mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \ - std r9,area+EX_R9(r13); /* save r9 - r12 */ \ - std r10,area+EX_R10(r13); \ - std r11,area+EX_R11(r13); \ - std r12,area+EX_R12(r13); \ - mfspr r9,SPRN_SPRG1; \ - std r9,area+EX_R13(r13);\ - mfcrr9; \ - clrrdi r12,r13,32; /* get high part of label */ \ - mfmsr r10;\ - /* force 64bit mode */ \ - li r11,5; /* MSR_SF_LG|MSR_ISF_LG */ \ - rldimi r10,r11,61,0; /* insert into top 3 bits */\ - /* done 64bit mode */ \ - mfspr r11,SPRN_SRR0; /* save SRR0 */ \ - LOAD_HANDLER(r12,label) \ - ori r10,r10,MSR_IR|MSR_DR|MSR_RI; \ - mtspr SPRN_SRR0,r12; \ - mfspr r12,SPRN_SRR1; /* and SRR1 */ \ - mtspr SPRN_SRR1,r10; \ - rfid; \ - b . /* prevent speculative execution */ - -#define EXCEPTION_PROLOG_PSERIES(area, label) \ - mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \ - std r9,area+EX_R9(r13); /* save r9 - r12 */ \ - std r10,area+EX_R10(r13); \ - std r11,area+EX_R11(r13);
[PATCH] [POWERPC] Move the iSeries exception vectors
out of head_64.S and into platforms/iseries/exception.S Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/kernel/head_64.S | 136 arch/powerpc/platforms/iseries/exception.S | 136 2 files changed, 136 insertions(+), 136 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index fe6122b..33c4e8c 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -358,142 +358,6 @@ machine_check_fwnmi: mtspr SPRN_SPRG1,r13 /* save r13 */ EXCEPTION_PROLOG_PSERIES_FORCE_64BIT(PACA_EXMC, machine_check_common) -#ifdef CONFIG_PPC_ISERIES -/*** ISeries-LPAR interrupt handlers ***/ - - STD_EXCEPTION_ISERIES(0x200, machine_check, PACA_EXMC) - - .globl data_access_iSeries -data_access_iSeries: - mtspr SPRN_SPRG1,r13 -BEGIN_FTR_SECTION - mtspr SPRN_SPRG2,r12 - mfspr r13,SPRN_DAR - mfspr r12,SPRN_DSISR - srdir13,r13,60 - rlwimi r13,r12,16,0x20 - mfcrr12 - cmpwi r13,0x2c - beq .do_stab_bolted_iSeries - mtcrf 0x80,r12 - mfspr r12,SPRN_SPRG2 -END_FTR_SECTION_IFCLR(CPU_FTR_SLB) - EXCEPTION_PROLOG_ISERIES_1(PACA_EXGEN) - EXCEPTION_PROLOG_ISERIES_2 - b data_access_common - -.do_stab_bolted_iSeries: - mtcrf 0x80,r12 - mfspr r12,SPRN_SPRG2 - EXCEPTION_PROLOG_ISERIES_1(PACA_EXSLB) - EXCEPTION_PROLOG_ISERIES_2 - b .do_stab_bolted - - .globl data_access_slb_iSeries -data_access_slb_iSeries: - mtspr SPRN_SPRG1,r13 /* save r13 */ - mfspr r13,SPRN_SPRG3 /* get paca address into r13 */ - std r3,PACA_EXSLB+EX_R3(r13) - mfspr r3,SPRN_DAR - std r9,PACA_EXSLB+EX_R9(r13) - mfcrr9 -#ifdef __DISABLED__ - cmpdi r3,0 - bge slb_miss_user_iseries -#endif - std r10,PACA_EXSLB+EX_R10(r13) - std r11,PACA_EXSLB+EX_R11(r13) - std r12,PACA_EXSLB+EX_R12(r13) - mfspr r10,SPRN_SPRG1 - std r10,PACA_EXSLB+EX_R13(r13) - ld r12,PACALPPACAPTR(r13) - ld r12,LPPACASRR1(r12) - b .slb_miss_realmode - - STD_EXCEPTION_ISERIES(0x400, instruction_access, PACA_EXGEN) - - .globl instruction_access_slb_iSeries -instruction_access_slb_iSeries: - mtspr SPRN_SPRG1,r13 /* save r13 */ - mfspr r13,SPRN_SPRG3 /* get paca address into r13 */ - std r3,PACA_EXSLB+EX_R3(r13) - ld r3,PACALPPACAPTR(r13) - ld r3,LPPACASRR0(r3) /* get SRR0 value */ - std r9,PACA_EXSLB+EX_R9(r13) - mfcrr9 -#ifdef __DISABLED__ - cmpdi r3,0 - bge .slb_miss_user_iseries -#endif - std r10,PACA_EXSLB+EX_R10(r13) - std r11,PACA_EXSLB+EX_R11(r13) - std r12,PACA_EXSLB+EX_R12(r13) - mfspr r10,SPRN_SPRG1 - std r10,PACA_EXSLB+EX_R13(r13) - ld r12,PACALPPACAPTR(r13) - ld r12,LPPACASRR1(r12) - b .slb_miss_realmode - -#ifdef __DISABLED__ -slb_miss_user_iseries: - std r10,PACA_EXGEN+EX_R10(r13) - std r11,PACA_EXGEN+EX_R11(r13) - std r12,PACA_EXGEN+EX_R12(r13) - mfspr r10,SPRG1 - ld r11,PACA_EXSLB+EX_R9(r13) - ld r12,PACA_EXSLB+EX_R3(r13) - std r10,PACA_EXGEN+EX_R13(r13) - std r11,PACA_EXGEN+EX_R9(r13) - std r12,PACA_EXGEN+EX_R3(r13) - EXCEPTION_PROLOG_ISERIES_2 - b slb_miss_user_common -#endif - - MASKABLE_EXCEPTION_ISERIES(0x500, hardware_interrupt) - STD_EXCEPTION_ISERIES(0x600, alignment, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0x700, program_check, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0x800, fp_unavailable, PACA_EXGEN) - MASKABLE_EXCEPTION_ISERIES(0x900, decrementer) - STD_EXCEPTION_ISERIES(0xa00, trap_0a, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0xb00, trap_0b, PACA_EXGEN) - - .globl system_call_iSeries -system_call_iSeries: - mr r9,r13 - mfspr r13,SPRN_SPRG3 - EXCEPTION_PROLOG_ISERIES_2 - b system_call_common - - STD_EXCEPTION_ISERIES( 0xd00, single_step, PACA_EXGEN) - STD_EXCEPTION_ISERIES( 0xe00, trap_0e, PACA_EXGEN) - STD_EXCEPTION_ISERIES( 0xf00, performance_monitor, PACA_EXGEN) - -decrementer_iSeries_masked: - /* We may not have a valid TOC pointer in here. */ - li r11,1 - ld r12,PACALPPACAPTR(r13) - stb r11,LPPACADECRINT(r12) - LOAD_REG_IMMEDIATE(r12, tb_ticks_per_jiffy) - lwz r12,0(r12) - mtspr SPRN_DEC,r12 - /* fall through */ - -hardware_interrupt_iSeries_masked: - mtcrf 0x80,r9 /* Restore regs */ - ld r12,PACALPPACAPTR(r13) -
[PATCH] [POWERPC] Split out iSeries specific exception macros
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/iseries/exception.S | 15 +++---
arch/powerpc/platforms/iseries/exception.h | 58 ++
include/asm-powerpc/exception.h| 71 +---
3 files changed, 78 insertions(+), 66 deletions(-)
create mode 100644 arch/powerpc/platforms/iseries/exception.h
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/iseries/exception.S
b/arch/powerpc/platforms/iseries/exception.S
index b5f6006..e9a3435 100644
--- a/arch/powerpc/platforms/iseries/exception.S
+++ b/arch/powerpc/platforms/iseries/exception.S
@@ -30,9 +30,10 @@
#include asm/asm-offsets.h
#include asm/thread_info.h
#include asm/ptrace.h
-#include asm/exception.h
#include asm/cputable.h
+#include exception.h
+
.text
.globl system_reset_iSeries
@@ -104,15 +105,15 @@ BEGIN_FTR_SECTION
mtcrf 0x80,r12
mfspr r12,SPRN_SPRG2
END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
- EXCEPTION_PROLOG_ISERIES_1(PACA_EXGEN)
- EXCEPTION_PROLOG_ISERIES_2
+ EXCEPTION_PROLOG_1(PACA_EXGEN)
+ EXCEPTION_PROLOG_ISERIES_1
b data_access_common
.do_stab_bolted_iSeries:
mtcrf 0x80,r12
mfspr r12,SPRN_SPRG2
- EXCEPTION_PROLOG_ISERIES_1(PACA_EXSLB)
- EXCEPTION_PROLOG_ISERIES_2
+ EXCEPTION_PROLOG_1(PACA_EXSLB)
+ EXCEPTION_PROLOG_ISERIES_1
b .do_stab_bolted
.globl data_access_slb_iSeries
@@ -171,7 +172,7 @@ slb_miss_user_iseries:
std r10,PACA_EXGEN+EX_R13(r13)
std r11,PACA_EXGEN+EX_R9(r13)
std r12,PACA_EXGEN+EX_R3(r13)
- EXCEPTION_PROLOG_ISERIES_2
+ EXCEPTION_PROLOG_ISERIES_1
b slb_miss_user_common
#endif
@@ -187,7 +188,7 @@ slb_miss_user_iseries:
system_call_iSeries:
mr r9,r13
mfspr r13,SPRN_SPRG3
- EXCEPTION_PROLOG_ISERIES_2
+ EXCEPTION_PROLOG_ISERIES_1
b system_call_common
STD_EXCEPTION_ISERIES( 0xd00, single_step, PACA_EXGEN)
diff --git a/arch/powerpc/platforms/iseries/exception.h
b/arch/powerpc/platforms/iseries/exception.h
new file mode 100644
index 000..5b3f285
--- /dev/null
+++ b/arch/powerpc/platforms/iseries/exception.h
@@ -0,0 +1,58 @@
+#ifndef _ASM_POWERPC_ISERIES_EXCEPTION_H
+#define _ASM_POWERPC_ISERIES_EXCEPTION_H
+/*
+ * Extracted from head_64.S
+ *
+ * PowerPC version
+ *Copyright (C) 1995-1996 Gary Thomas ([EMAIL PROTECTED])
+ *
+ * Rewritten by Cort Dougan ([EMAIL PROTECTED]) for PReP
+ *Copyright (C) 1996 Cort Dougan [EMAIL PROTECTED]
+ * Adapted for Power Macintosh by Paul Mackerras.
+ * Low-level exception handlers and MMU support
+ * rewritten by Paul Mackerras.
+ *Copyright (C) 1996 Paul Mackerras.
+ *
+ * Adapted for 64bit PowerPC by Dave Engebretsen, Peter Bergner, and
+ *Mike Corrigan {engebret|bergner|[EMAIL PROTECTED]
+ *
+ * This file contains the low-level support and setup for the
+ * PowerPC-64 platform, including trap and interrupt dispatch.
+ *
+ * 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.
+ */
+#include asm/exception.h
+
+#define EXCEPTION_PROLOG_ISERIES_1 \
+ mfmsr r10;\
+ ld r12,PACALPPACAPTR(r13); \
+ ld r11,LPPACASRR0(r12);\
+ ld r12,LPPACASRR1(r12);\
+ ori r10,r10,MSR_RI; \
+ mtmsrd r10,1
+
+#define STD_EXCEPTION_ISERIES(n, label, area) \
+ .globl label##_iSeries; \
+label##_iSeries: \
+ HMT_MEDIUM; \
+ mtspr SPRN_SPRG1,r13; /* save r13 */ \
+ EXCEPTION_PROLOG_1(area); \
+ EXCEPTION_PROLOG_ISERIES_1; \
+ b label##_common
+
+#define MASKABLE_EXCEPTION_ISERIES(n, label) \
+ .globl label##_iSeries; \
+label##_iSeries: \
+ HMT_MEDIUM; \
+ mtspr SPRN_SPRG1,r13; /* save r13 */ \
+ EXCEPTION_PROLOG_1(PACA_EXGEN); \
+ lbz r10,PACASOFTIRQEN(r13); \
+ cmpwi 0,r10,0;
[PATCH] [POWERPC] Exception numbers are not relevent to iSeries
so remove them from the macros. Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/platforms/iseries/exception.S | 24 arch/powerpc/platforms/iseries/exception.h |4 ++-- 2 files changed, 14 insertions(+), 14 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ diff --git a/arch/powerpc/platforms/iseries/exception.S b/arch/powerpc/platforms/iseries/exception.S index e9a3435..5381038 100644 --- a/arch/powerpc/platforms/iseries/exception.S +++ b/arch/powerpc/platforms/iseries/exception.S @@ -88,7 +88,7 @@ iSeries_secondary_smp_loop: /*** ISeries-LPAR interrupt handlers ***/ - STD_EXCEPTION_ISERIES(0x200, machine_check, PACA_EXMC) + STD_EXCEPTION_ISERIES(machine_check, PACA_EXMC) .globl data_access_iSeries data_access_iSeries: @@ -137,7 +137,7 @@ data_access_slb_iSeries: ld r12,LPPACASRR1(r12) b .slb_miss_realmode - STD_EXCEPTION_ISERIES(0x400, instruction_access, PACA_EXGEN) + STD_EXCEPTION_ISERIES(instruction_access, PACA_EXGEN) .globl instruction_access_slb_iSeries instruction_access_slb_iSeries: @@ -176,13 +176,13 @@ slb_miss_user_iseries: b slb_miss_user_common #endif - MASKABLE_EXCEPTION_ISERIES(0x500, hardware_interrupt) - STD_EXCEPTION_ISERIES(0x600, alignment, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0x700, program_check, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0x800, fp_unavailable, PACA_EXGEN) - MASKABLE_EXCEPTION_ISERIES(0x900, decrementer) - STD_EXCEPTION_ISERIES(0xa00, trap_0a, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0xb00, trap_0b, PACA_EXGEN) + MASKABLE_EXCEPTION_ISERIES(hardware_interrupt) + STD_EXCEPTION_ISERIES(alignment, PACA_EXGEN) + STD_EXCEPTION_ISERIES(program_check, PACA_EXGEN) + STD_EXCEPTION_ISERIES(fp_unavailable, PACA_EXGEN) + MASKABLE_EXCEPTION_ISERIES(decrementer) + STD_EXCEPTION_ISERIES(trap_0a, PACA_EXGEN) + STD_EXCEPTION_ISERIES(trap_0b, PACA_EXGEN) .globl system_call_iSeries system_call_iSeries: @@ -191,9 +191,9 @@ system_call_iSeries: EXCEPTION_PROLOG_ISERIES_1 b system_call_common - STD_EXCEPTION_ISERIES( 0xd00, single_step, PACA_EXGEN) - STD_EXCEPTION_ISERIES( 0xe00, trap_0e, PACA_EXGEN) - STD_EXCEPTION_ISERIES( 0xf00, performance_monitor, PACA_EXGEN) + STD_EXCEPTION_ISERIES(single_step, PACA_EXGEN) + STD_EXCEPTION_ISERIES(trap_0e, PACA_EXGEN) + STD_EXCEPTION_ISERIES(performance_monitor, PACA_EXGEN) decrementer_iSeries_masked: /* We may not have a valid TOC pointer in here. */ diff --git a/arch/powerpc/platforms/iseries/exception.h b/arch/powerpc/platforms/iseries/exception.h index 5b3f285..ced45a8 100644 --- a/arch/powerpc/platforms/iseries/exception.h +++ b/arch/powerpc/platforms/iseries/exception.h @@ -34,7 +34,7 @@ ori r10,r10,MSR_RI; \ mtmsrd r10,1 -#define STD_EXCEPTION_ISERIES(n, label, area) \ +#define STD_EXCEPTION_ISERIES(label, area) \ .globl label##_iSeries; \ label##_iSeries: \ HMT_MEDIUM; \ @@ -43,7 +43,7 @@ label##_iSeries: \ EXCEPTION_PROLOG_ISERIES_1; \ b label##_common -#define MASKABLE_EXCEPTION_ISERIES(n, label) \ +#define MASKABLE_EXCEPTION_ISERIES(label) \ .globl label##_iSeries; \ label##_iSeries: \ HMT_MEDIUM; \ -- 1.5.2.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
On Wed, Aug 22, 2007 at 05:29:50AM +0200, Segher Boessenkool wrote:
If this isn't causing any problems maybe there
is some loigic we are overlooking?
The I/O accessor functions enforce the necessary ordering
already I believe.
Ah, it looks like you might be right, IO should appear to go in-order,
in
which case the rmb() would simply need to order cacheable loads.
Interesting
way to do things... are drivers simply not up to scratch enough to
allow
out of order IO?
The powerpc kernel needs to have full sync insns in every I/O
accessor in order to enforce all the ordering rules Linux demands.
It's a bloody shame, but the alternative would be to make the
barriers lots more expensive. A third alternative would be to
Well lots more expensive compared to what you have now. But what
you have now is like having those expensive barriers between
*every* io access.
have barrier ops that do not order everything, but just A vs. B
for various choices of A and B (coherent accesses, MMIO accesses,
etc.)
The non-smp_ variant is supposed to order everything, AFAIK. Maybe
you could get more fancy and have PIO vs MMIO etc etc. but it looks
like this whole area is in a pretty sticky state anyway so let's
not think about that.
Anyway, this raises another question -- if IO accessors have the right
ordering, why is wmb() not an lwsync as well? There appears to be many
more wmb() calls than rmb()...
Input MMIO accessors are {sync, load, stall pipeline until load came
back}.
That's a full ordering on both sides.
Output MMIO on the other hand is done with {sync, store}. Now since
wmb() has to order MMIO writes vs. main memory writes, we need a full
sync here. On some (most, all?) CPUs an eieio is actually enough btw.
The barrier insn could be put at the end of all MMIO write ops too,
but I believe that would be more expensive (in execution time; in code
size it definitely would be, of course).
Ah, that explains why wmb() is a sync. Doesn't seem like a very good
idea though, if the rationale of having fully ordered IO accessors was
because drivers didn't have enough barriers in them.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
On Wed, Aug 22, 2007 at 05:33:16AM +0200, Segher Boessenkool wrote: The I/O accessor functions enforce the necessary ordering already I believe. Hmm, I never followed those discussions last year about IO ordering, and I can't see where (if) it was documented anywhere :( The comments in system.h weren't updated with the last fix, I think. It appears that legacy code is handled by defining the old IO accessors to be completely ordered, and introducing new __raw_ variants that are not (OTOH, it seems like other architectures are implementing __raw prefix as inorder unless there is a _relaxed postfix). __raw_XX() is for platform code only, which can do the needed barriers without having to use the heavy hammer like everything else unfortunately does. [EMAIL PROTECTED]:~/usr/src/linux-2.6/drivers egrep '__raw_(write|read)' -r * | wc -l 685 Drivers are definitely using these __raw_ accessors, and from a quick look, they do appear to be hoping that *mb() is going to order access for them. Which drivers? There are maybe a dozen that use the raw accessors, and use non-smp_ memory barriers. I just looked at drivers/video/tgafb.c, which indeed appears to intermix them. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Check _PAGE_RW and _PAGE_PRESENT on kernel addresses.
On Wed, Aug 22, 2007 at 01:52:49PM +1000, Paul Mackerras wrote: Scott Wood writes: Previously, the TLB miss handlers assumed that pages above KERNELBASE are always present and read/write. This assumption is false in the case of CONFIG_DEBUG_PAGEALLOC. blt+112f + mfspr r2,SPRN_SRR1/* and MSR_PR bit from SRR1 */ + rlwinm r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */ lis r2,[EMAIL PROTECTED]/* if kernel address, use */ addir2,r2,[EMAIL PROTECTED] /* kernel page table */ - mfspr r1,SPRN_SRR1/* and MSR_PR bit from SRR1 */ - rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */ I don't see that just moving those two lines up changes anything. If you turned the rlwinm into an rlwimi (as you did in the DataStoreTLBMiss case) then it might make more sense. Is this just an oversight? Sorry, rlwimi was what I meant... The data store path was what I found the problem and tested with, the others were an apparently botched replication to the other handlers. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
wmb vs mmiowb
Hi, I'm ignorant when it comes to IO access, so I hope this isn't rubbish (if it is, I would appreciate being corrected). It took me more than a glance to see what the difference is supposed to be between wmb() and mmiowb(). I think especially because mmiowb isn't really like a write barrier. wmb is supposed to order all writes coming out of a single CPU, so that's pretty simple. The problem is that writes coming from different CPUs can be seen by the device in a different order from which they were written if coming from different CPUs, even if the order of writes is guaranteed (eg. by a spinlock) and issued in the right order WRT the locking (ie. using wmb()). And this can happen because the writes can get posted away and reordered by the IO fabric (I think). mmiowb ensures the writes are seen by the device in the correct order. It doesn't seem like this primary function of mmiowb has anything to do with a write barrier that we are used to (it may have a seconary semantic of a wmb as well, but let's ignore that for now). A write barrier will never provide you with those semantics (writes from 2 CPUs seen in the same order by a 3rd party). If anything, I think it is closer to being a read barrier issued on behalf of the target device. But even that I think is not much better, because the target is not participating in the synchronisation that the CPUs are, so the read barrier request could still arrive at the device out of order WRT the other CPU's writes. It really seems like it is some completely different concept from a barrier. And it shows, on the platform where it really matters (sn2), where the thing actually spins. I don't know exactly how it should be categorised. On one hand, it is kind of like a critical section, and would work beautifully if we could just hide it inside spin_lock_io/spin_unlock_io. On the other hand, it seems like it is often used separately from locks, where it looks decidedly less like a critical section or release barrier. How can such uses be correct if they are worried about multi-CPU ordering but don't have anything to synchronize the CPUs? Or are they cleverly enforcing CPU ordering some other way? (in which case, maybe an acquire/release API really would make sense?). I don't really have a big point, except that I would like to know whether I'm on the right track, and wish the thing could have a better name/api. Thanks, Nick ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
