* Re: [PATCH 12/16] cell: add temperature to SPU and CPU sysfs entries
From: Heiko Carstens @ 2006-10-25 8:00 UTC (permalink / raw)
To: arnd
Cc: Arnd Bergmann, linux-kernel, linuxppc-dev, paulus,
Christian Krafft, cbe-oss-dev
In-Reply-To: <20061024163816.851732000@arndb.de>
On Tue, Oct 24, 2006 at 06:31:25PM +0200, arnd@arndb.de wrote:
> + * (C) Copyright IBM Deutschland Entwicklung GmbH 2005
IBM Corp. instead of IBM DE? 2006?
> +static int __init thermal_init(void)
> +{
> + init_default_values();
> +
> + spu_add_sysdev_attr_group(&spu_attribute_group);
> + cpu_add_sysdev_attr_group(&ppe_attribute_group);
> +
> + return 0;
> +}
Same here: check for errors on spu_add_sysdev_attr_group and
cpu_add_sysdev_attr_group.
> +static void __exit thermal_exit(void)
> +{
> + spu_remove_sysdev_attr_group(&spu_attribute_group);
> + cpu_remove_sysdev_attr_group(&ppe_attribute_group);
Will crash if cpu_add_sysdev_attr_group failed...
^ permalink raw reply
* Re: MPC7448_HPC2 question
From: Zang Roy-r61911 @ 2006-10-25 9:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Alexandre.Bounine@tundra.com
In-Reply-To: <1161753605.22582.42.camel@localhost.localdomain>
On Wed, 2006-10-25 at 13:20, Benjamin Herrenschmidt wrote:
>
> Cannot be replaced by:
>
> pci_read_irq_line(dev);
When I use pci_read_irq_line(), the pci interrupt number exceeds the
limit of mpic-> irq_count. my mpic->irq_count = 0x18, which is gotten
from on chip register.
mpic_host_map() can not return successful value.
Roy
^ permalink raw reply
* [RFC/PATCH] Maple: Use RTAS power off methods if available
From: Michael Ellerman @ 2006-10-25 10:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Some versions of SLOF have the RTAS power-off/restart methods
implemented, if they're available they should be used in preference
to the nvram based methods.
Not sure what the best way to do this is, this is the easy approach
although it leaves the system unrebootable until the callbacks get
rewired. The other option would be to do the check in maple_restart
etc. when they're called.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/platforms/maple/setup.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
Index: powerpc/arch/powerpc/Kconfig
===================================================================
--- powerpc.orig/arch/powerpc/Kconfig
+++ powerpc/arch/powerpc/Kconfig
@@ -422,6 +422,7 @@ config PPC_MAPLE
select GENERIC_TBSYNC
select PPC_UDBG_16550
select PPC_970_NAP
+ select PPC_RTAS
default n
help
This option enables support for the Maple 970FX Evaluation Board.
Index: powerpc/arch/powerpc/platforms/maple/setup.c
===================================================================
--- powerpc.orig/arch/powerpc/platforms/maple/setup.c
+++ powerpc/arch/powerpc/platforms/maple/setup.c
@@ -61,6 +61,7 @@
#include <asm/lmb.h>
#include <asm/mpic.h>
#include <asm/udbg.h>
+#include <asm/rtas.h>
#include "maple.h"
@@ -185,6 +186,26 @@ void __init maple_setup_arch(void)
printk(KERN_DEBUG "Using native/NAP idle loop\n");
}
+static void __init maple_check_for_rtas_poweroff(void)
+{
+#ifdef CONFIG_PPC_RTAS
+ struct device_node *rtas;
+
+ rtas = of_find_node_by_path("/rtas");
+ if (rtas) {
+ if (get_property(rtas, "system-reboot", NULL))
+ ppc_md.restart = rtas_restart;
+
+ if (get_property(rtas, "power-off", NULL)) {
+ ppc_md.power_off = rtas_power_off;
+ ppc_md.halt = rtas_halt;
+ }
+
+ of_node_put(rtas);
+ }
+#endif
+}
+
/*
* Early initialization.
*/
@@ -192,6 +213,8 @@ static void __init maple_init_early(void
{
DBG(" -> maple_init_early\n");
+ maple_check_for_rtas_poweroff();
+
iommu_init_early_dart();
DBG(" <- maple_init_early\n");
^ permalink raw reply
* [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
From: Li Yang @ 2006-10-25 11:05 UTC (permalink / raw)
To: linuxppc-dev
Remove private physical address mapping routine in qe_lib. Users
of qe_lib should use generic functions like iopa().
The change also addresses a bug found by Timur Tabi that cmd_input
got mapped in qe_issue_cmd(). It should be written to CECDR
unmodified.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/sysdev/qe_lib/qe.c | 3 +--
include/asm-powerpc/immap_qe.h | 9 ---------
2 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 2bae632..e422322 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -122,8 +122,7 @@ int qe_issue_cmd(u32 cmd, u32 device, u8
mcn_shift = QE_CR_MCN_NORMAL_SHIFT;
}
- out_be32(&qe_immr->cp.cecdr,
- immrbar_virt_to_phys((void *)cmd_input));
+ out_be32(&qe_immr->cp.cecdr, cmd_input);
out_be32(&qe_immr->cp.cecr,
(cmd | QE_CR_FLG | ((u32) device << dev_shift) | (u32)
mcn_protocol << mcn_shift));
diff --git a/include/asm-powerpc/immap_qe.h b/include/asm-powerpc/immap_qe.h
index ce12f85..7cccd16 100644
--- a/include/asm-powerpc/immap_qe.h
+++ b/include/asm-powerpc/immap_qe.h
@@ -464,14 +464,5 @@ struct qe_immap {
extern struct qe_immap *qe_immr;
extern phys_addr_t get_qe_base(void);
-static inline unsigned long immrbar_virt_to_phys(volatile void * address)
-{
- if ( ((u32)address >= (u32)qe_immr) &&
- ((u32)address < ((u32)qe_immr + QE_IMMAP_SIZE)) )
- return (unsigned long)(address - (u32)qe_immr +
- (u32)get_qe_base());
- return (unsigned long)virt_to_phys(address);
-}
-
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IMMAP_QE_H */
^ permalink raw reply related
* [PATCH] ucc_geth: change to use generic address mapping routine
From: Li Yang @ 2006-10-25 11:11 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, netdev
Private address mapping routine immrbar_virt_to_phys() is removed
from qe_lib. The patch changes ucc_geth driver to use generic routine
iopa().
Signed-off-by: Li Yang <leoli@freescale.com>
---
drivers/net/ucc_geth.c | 29 ++++++-----------------------
1 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index b378880..8eb1e94 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3062,21 +3062,11 @@ static int ucc_geth_startup(struct ucc_g
endOfRing =
ugeth->p_tx_bd_ring[i] + (ug_info->bdRingLenTx[i] -
1) * sizeof(struct qe_bd);
- if (ugeth->ug_info->uf_info.bd_mem_part == MEM_PART_SYSTEM) {
- out_be32(&ugeth->p_send_q_mem_reg->sqqd[i].bd_ring_base,
- (u32) virt_to_phys(ugeth->p_tx_bd_ring[i]));
- out_be32(&ugeth->p_send_q_mem_reg->sqqd[i].
+ out_be32(&ugeth->p_send_q_mem_reg->sqqd[i].bd_ring_base,
+ iopa((unsigned long)ugeth->p_tx_bd_ring[i]));
+ out_be32(&ugeth->p_send_q_mem_reg->sqqd[i].
last_bd_completed_address,
- (u32) virt_to_phys(endOfRing));
- } else if (ugeth->ug_info->uf_info.bd_mem_part ==
- MEM_PART_MURAM) {
- out_be32(&ugeth->p_send_q_mem_reg->sqqd[i].bd_ring_base,
- (u32) immrbar_virt_to_phys(ugeth->
- p_tx_bd_ring[i]));
- out_be32(&ugeth->p_send_q_mem_reg->sqqd[i].
- last_bd_completed_address,
- (u32) immrbar_virt_to_phys(endOfRing));
- }
+ iopa((unsigned long)endOfRing));
}
/* schedulerbasepointer */
@@ -3328,15 +3318,8 @@ static int ucc_geth_startup(struct ucc_g
/* Setup the table */
/* Assume BD rings are already established */
for (i = 0; i < ug_info->numQueuesRx; i++) {
- if (ugeth->ug_info->uf_info.bd_mem_part == MEM_PART_SYSTEM) {
- out_be32(&ugeth->p_rx_bd_qs_tbl[i].externalbdbaseptr,
- (u32) virt_to_phys(ugeth->p_rx_bd_ring[i]));
- } else if (ugeth->ug_info->uf_info.bd_mem_part ==
- MEM_PART_MURAM) {
- out_be32(&ugeth->p_rx_bd_qs_tbl[i].externalbdbaseptr,
- (u32) immrbar_virt_to_phys(ugeth->
- p_rx_bd_ring[i]));
- }
+ out_be32(&ugeth->p_rx_bd_qs_tbl[i].externalbdbaseptr,
+ iopa((unsigned long)ugeth->p_rx_bd_ring[i]));
/* rest of fields handled by QE */
}
^ permalink raw reply related
* [PATCH 2.6.19-rc3 1/2] ehea: kzalloc GFP_ATOMIC fix
From: Jan-Bernd Themann @ 2006-10-25 11:11 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This patch fixes kzalloc parameters (GFP_ATOMIC instead of GFP_KERNEL)
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index eb7d44d..4538c99 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -586,8 +586,8 @@ int ehea_sense_port_attr(struct ehea_por
u64 hret;
struct hcp_ehea_port_cb0 *cb0;
- cb0 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
- if (!cb0) {
+ cb0 = kzalloc(H_CB_ALIGNMENT, GFP_ATOMIC); /* May be called via */
+ if (!cb0) { /* ehea_neq_tasklet() */
ehea_error("no mem for cb0");
ret = -ENOMEM;
goto out;
@@ -765,8 +765,7 @@ static void ehea_parse_eqe(struct ehea_a
if (EHEA_BMASK_GET(NEQE_PORT_UP, eqe)) {
if (!netif_carrier_ok(port->netdev)) {
- ret = ehea_sense_port_attr(
- port);
+ ret = ehea_sense_port_attr(port);
if (ret) {
ehea_error("failed resensing port "
"attributes");
@@ -1502,7 +1501,7 @@ static void ehea_promiscuous(struct net_
if ((enable && port->promisc) || (!enable && !port->promisc))
return;
- cb7 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
+ cb7 = kzalloc(H_CB_ALIGNMENT, GFP_ATOMIC);
if (!cb7) {
ehea_error("no mem for cb7");
goto out;
@@ -1606,7 +1605,7 @@ static void ehea_add_multicast_entry(str
struct ehea_mc_list *ehea_mcl_entry;
u64 hret;
- ehea_mcl_entry = kzalloc(sizeof(*ehea_mcl_entry), GFP_KERNEL);
+ ehea_mcl_entry = kzalloc(sizeof(*ehea_mcl_entry), GFP_ATOMIC);
if (!ehea_mcl_entry) {
ehea_error("no mem for mcl_entry");
return;
^ permalink raw reply related
* [PATCH 2.6.19-rc3 2/2] ehea: 64K page support fix
From: Jan-Bernd Themann @ 2006-10-25 11:12 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This patch fixes the 64K page support
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_phyp.h | 14 +++++++++++++-
drivers/net/ehea/ehea_qmr.c | 13 +++++++------
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index b40724f..cd412b5 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@ #include <asm/abs_addr.h>
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0034"
+#define DRV_VERSION "EHEA_0040"
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_phyp.h b/drivers/net/ehea/ehea_phyp.h
index fa51e3b..59ab646 100644
--- a/drivers/net/ehea/ehea_phyp.h
+++ b/drivers/net/ehea/ehea_phyp.h
@@ -81,15 +81,27 @@ #define NELR_PORTSTATE_CHG EHEA_BMASK_IB
static inline void hcp_epas_ctor(struct h_epas *epas, u64 paddr_kernel,
u64 paddr_user)
{
+#ifdef CONFIG_PPC_64K_PAGES
+ /* To support 64k pages we must round to 64k page boundary */
+ epas->kernel.addr =
+ ioremap((paddr_kernel & 0xFFFFFFFFFFFF0000), PAGE_SIZE) +
+ (paddr_kernel & 0xFFFF);
+#else
epas->kernel.addr = ioremap(paddr_kernel, PAGE_SIZE);
+#endif
epas->user.addr = paddr_user;
}
static inline void hcp_epas_dtor(struct h_epas *epas)
{
+#ifdef CONFIG_PPC_64K_PAGES
+ if (epas->kernel.addr)
+ iounmap((void __iomem*)((u64)epas->kernel.addr &
+ 0xFFFFFFFFFFFF0000));
+#else
if (epas->kernel.addr)
iounmap(epas->kernel.addr);
-
+#endif
epas->user.addr = 0;
epas->kernel.addr = 0;
}
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index 3e18623..3daedfa 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -512,7 +512,7 @@ int ehea_reg_mr_adapter(struct ehea_adap
start = KERNELBASE;
end = (u64)high_memory;
- nr_pages = (end - start) / PAGE_SIZE;
+ nr_pages = (end - start) / EHEA_PAGESIZE;
pt = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!pt) {
@@ -538,9 +538,9 @@ int ehea_reg_mr_adapter(struct ehea_adap
if (nr_pages > 1) {
u64 num_pages = min(nr_pages, (u64)512);
for (i = 0; i < num_pages; i++)
- pt[i] = virt_to_abs((void*)(((u64)start)
- + ((k++) *
- PAGE_SIZE)));
+ pt[i] = virt_to_abs((void*)(((u64)start) +
+ ((k++) *
+ EHEA_PAGESIZE)));
hret = ehea_h_register_rpage_mr(adapter->handle,
adapter->mr.handle, 0,
@@ -548,8 +548,9 @@ int ehea_reg_mr_adapter(struct ehea_adap
num_pages);
nr_pages -= num_pages;
} else {
- u64 abs_adr = virt_to_abs((void*)(((u64)start)
- + (k * PAGE_SIZE)));
+ u64 abs_adr = virt_to_abs((void*)(((u64)start) +
+ (k * EHEA_PAGESIZE)));
+
hret = ehea_h_register_rpage_mr(adapter->handle,
adapter->mr.handle, 0,
0, abs_adr,1);
^ permalink raw reply related
* Re: [PATCH 11/16] sysfs: add support for adding/removing spu sysfs attributes
From: Arnd Bergmann @ 2006-10-25 12:27 UTC (permalink / raw)
To: Heiko Carstens
Cc: linuxppc-dev, paulus, cbe-oss-dev, Christian Krafft, linux-kernel
In-Reply-To: <20061025075238.GA7090@osiris.boeblingen.de.ibm.com>
On Wednesday 25 October 2006 09:52, Heiko Carstens wrote:
> You probably should check for errors on sysdev_create_file, clean up and
> return an error number instead of always 0.
> This is true for all the new functions here.
Right, thanks for the review.
Christian or I will take care of this.
Arnd <><
^ permalink raw reply
* RE: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
From: KRONSTORFER Horst @ 2006-10-25 12:47 UTC (permalink / raw)
To: Andy Fleming, Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <95309226-07A8-43E0-A03B-7D7E828D4429@freescale.com>
andy, dan, thanks for your replies!=20
> Look at the driver in drivers/net/phy/fixed.c.
i did that w/o luck. the results are 100% the same compared to the
'remove phy/mdio support' approach. i therefore assume that the source
of the problem must be something else.
debugging around gfar_start_xmit() i made the following observations:
1) dumping skb->data i see correct frame data.
2) dumping txbdp->bufPtr (using a bdi) i sometimes see correct frame =
data,
sometimes the corrupted frame data as i see it on the wire.
3) regardless of 2) the data of these frames is always corrupted on the=20
wire.
on the 1st look this seems to be some kind of caching effect, but then =
...
thanks
-h
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]=20
> Sent: Dienstag, 24. Oktober 2006 20:15
> To: KRONSTORFER Horst
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
>=20
> Look at the driver in drivers/net/phy/fixed.c. It probably=20
> needs some documentation, and Vitaly implied it needed a=20
> little tweaking, but it provides the basics of what you need=20
> (and what Dan mentioned). Essentially, you need to fake the=20
> PHY. However, if you wanted, you could also get smarter and=20
> write a new mdiobus driver, which handles configuring and=20
> using the switch.
>=20
> I'm not quite sure why your approach isn't working, but I=20
> agree with Dan's suspicions that removing the PHY code=20
> doesn't just work.
>=20
> One thing to check is the adjust_link() function. You need=20
> to make sure that you have the carrier on, and that the MAC=20
> is set to MII mode, rather than GMII mode.
>=20
> Andy
>=20
> On Oct 24, 2006, at 04:16, KRONSTORFER Horst wrote:
>=20
> > hi!
> >
> > in our design we use an mpc8343 with the 2 tsecs connected to a=20
> > zarlink zl50411 eth switch in mii mode. the 2 ports of the=20
> switch are=20
> > running in phy mode (reverse mii) w/o mdio. we're currently running=20
> > kernel 2.6.17.13.
> >
> > i therefore 'simply' removed the mdio bus and phy support=20
> and tested=20
> > with ping over tsec0. result: i can see arp requests which=20
> are some-=20
> > what malformed (dest mac addr is not bcast, source ip addr is=20
> > incorrect, etc ...) btw: i used the same approach in u-boot and it=20
> > works fine.
> >
> > i then checked the content of the sk_buff handed over to=20
> > gfar_start_xmit which is correct (mac addrs, ip addrs, ...)
> >
> > i'm currently out of ideas, any kind of help is appreciated!
> >
> > thanks
> > -h
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Using WindRiver Probe JTAG
From: Michael Zagalsky @ 2006-10-25 12:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]
Hi guys.
I'd like to know if anybody had an experience using Wind River Probe JTAG
with PowerPC architecture in general, and with PowerQuicc iii family in
particular.
We're using WR workbench, but I am not sure whether to use their JTAG or the
popular BDI2000.
Does anybody know if WR Probe uses GDB, or something proprietary to WR?
Can it be attached to gdb/ddd/eclipse, or only to WR workbench IDE?
For kernel debugging with symbolic information - can it use any binary
compiled with -g, or it has to be compiled under WR workbench environment
that has some add-ons (I know, it sounds strange - but I actually heard some
vague saying of this kind from WR representative).
I know those are questions that should be addressed to Wind River , which I
did, but I didn't get clear enough answers - so your (good/bad) field
experience could be very helpful.
Thanks a lot,
Michael
[-- Attachment #2: Type: text/html, Size: 1018 bytes --]
^ permalink raw reply
* Re: Using WindRiver Probe JTAG
From: Steven Hein @ 2006-10-25 13:00 UTC (permalink / raw)
To: Michael Zagalsky; +Cc: linuxppc-embedded
In-Reply-To: <1ea6be8e0610250554l5f9a431cr26f03a99574f68d9@mail.gmail.com>
[-- Attachment #1: Type: text/html, Size: 3083 bytes --]
^ permalink raw reply
* Re: MPC7448_HPC2 question
From: Benjamin Herrenschmidt @ 2006-10-25 13:45 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Alexandre.Bounine@tundra.com
In-Reply-To: <1161768688.17597.8.camel@localhost.localdomain>
On Wed, 2006-10-25 at 17:31 +0800, Zang Roy-r61911 wrote:
> On Wed, 2006-10-25 at 13:20, Benjamin Herrenschmidt wrote:
>
> >
> > Cannot be replaced by:
> >
> > pci_read_irq_line(dev);
>
> When I use pci_read_irq_line(), the pci interrupt number exceeds the
> limit of mpic-> irq_count. my mpic->irq_count = 0x18, which is gotten
> from on chip register.
>
> mpic_host_map() can not return successful value.
That is not normal... Something must be wrong with your code or your
DT... can you get more details about what precisely is happening in both
cases ?
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] Maple: Use RTAS power off methods if available
From: Nathan Lynch @ 2006-10-25 13:58 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20061025102823.CF83667BBC@ozlabs.org>
Michael Ellerman wrote:
>
> Index: powerpc/arch/powerpc/Kconfig
> ===================================================================
> --- powerpc.orig/arch/powerpc/Kconfig
> +++ powerpc/arch/powerpc/Kconfig
> @@ -422,6 +422,7 @@ config PPC_MAPLE
> select GENERIC_TBSYNC
> select PPC_UDBG_16550
> select PPC_970_NAP
> + select PPC_RTAS
> default n
> help
> This option enables support for the Maple 970FX Evaluation Board.
> Index: powerpc/arch/powerpc/platforms/maple/setup.c
> ===================================================================
> --- powerpc.orig/arch/powerpc/platforms/maple/setup.c
> +++ powerpc/arch/powerpc/platforms/maple/setup.c
> @@ -61,6 +61,7 @@
> #include <asm/lmb.h>
> #include <asm/mpic.h>
> #include <asm/udbg.h>
> +#include <asm/rtas.h>
>
> #include "maple.h"
>
> @@ -185,6 +186,26 @@ void __init maple_setup_arch(void)
> printk(KERN_DEBUG "Using native/NAP idle loop\n");
> }
>
> +static void __init maple_check_for_rtas_poweroff(void)
> +{
> +#ifdef CONFIG_PPC_RTAS
> + struct device_node *rtas;
> +
> + rtas = of_find_node_by_path("/rtas");
> + if (rtas) {
> + if (get_property(rtas, "system-reboot", NULL))
> + ppc_md.restart = rtas_restart;
> +
> + if (get_property(rtas, "power-off", NULL)) {
> + ppc_md.power_off = rtas_power_off;
> + ppc_md.halt = rtas_halt;
> + }
> +
> + of_node_put(rtas);
> + }
> +#endif
PPC_RTAS is selected in Kconfig, the ifdef isn't necessary.
^ permalink raw reply
* Re: MPC8343: PCI resource allocation questions
From: Kumar Gala @ 2006-10-25 14:06 UTC (permalink / raw)
To: Luong Ngo; +Cc: linuxppc-dev list
In-Reply-To: <1b2aacd80610250016q4bcc5f9bm467ef09022ce1285@mail.gmail.com>
On Oct 25, 2006, at 2:16 AM, Luong Ngo wrote:
>
> Would you mind explain me the last question in previous email?
>
>
> You are not leaving any memory space for any of the onchip devices,
> the error messages are because the regions of memory that the devices
> are expected to be at are already occupied by the PCI space.
>
> Isn't it the PCI IO and PCI MEM space are separated from local
> memory space? I think I see the global IO resource and MEM resource
> have the range of 0x0 - 0xFFFFFFFF.
PCI MEM space mapped into the processors physical address space, so
you can't easily have access to all 4G of PCI MEM space. Instead we
usually just allocate 256M or 512M or physical address space for PCI
MEM. (the same is roughly true for PCI IO).
- kumar
>
> Thanks,
> Luong Ngo
>
> On 10/24/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> > I'm a bit confused here. If the host bridge is ignored/excluded,
> > then the region size in BARs will not be allocated corresponding
> > resource by the PCI subsystem, then how would other PCI devices in
> > the slots could be allocated in the BAR's range? If I understand
> > correctly, the PCI devices's resources are allocated based on the
> > bridge resource, which is assigned statically by PCI subsystem
> > using hose->mem_space and hose->io_space instead of reading it from
> > the BARs. Maybe you are saying in the case the CPU is in agent mode
> > and its PCI host bridge is functioning as a PCI-PCI bridge?
>
> The problem is the host bridge shouldn't be included in BAR
> assignment since its the host bridge. The problem is FSL devices
> show up when they scan themselves and the kernel then tries to
> allocate resources to them as if they were any other device.
>
> you are correct, the pci subsystem is setup via the hose structure
> and not by trying to read BARs on the host controller itself.
>
> - kumar
>
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Kumar Gala @ 2006-10-25 14:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, torvalds
In-Reply-To: <17727.901.368752.68802@cargo.ozlabs.ibm.com>
On Oct 25, 2006, at 1:26 AM, Paul Mackerras wrote:
> Linus,
>
> Please do:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> to get some more PowerPC bugfixes, as listed below. There is also a
> defconfig update and the addition of a new processor type (970GX) to
> the cpu table. The first 4 listed under Ben H.'s name aren't strictly
> bugfixes in themselves, but are needed for the Cell timebase hardware
> bug workaround (the bug is that reads from the timebase may
> occasionally not return monotonically increasing values, as they
> implemented the timebase as two 32-bit counters).
Can you hold off on the this. The following patch is still under
discussion and the problem exists on more than just PPC.
[snip]
> Scott Wood:
> [POWERPC] IPIC: Fix spinlock recursion in set_irq_handler
- kumar
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Olof Johansson @ 2006-10-25 14:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, torvalds
In-Reply-To: <17727.901.368752.68802@cargo.ozlabs.ibm.com>
On Wed, 25 Oct 2006 16:26:13 +1000 Paul Mackerras <paulus@samba.org> wrote:
> Jake Moilanen:
> [POWERPC] Add 970GX cputable entry
I didn't see them fix the head_64.S issue with this patch.
-Olof
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Matt Sealey @ 2006-10-25 14:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17726.39780.732843.150044@cargo.ozlabs.ibm.com>
It supports the original processors, G3, G4 etc. as well. Maybe not
the 601? I'm not sure. All the PowerPC ISA Books are in there and
information only seems to have been ADDED (or moved to another
book or been given a new book).
If a processor is not supported it was probably designed and
end-of-lined well before they made the original "Book" specs :D
Have you even looked at it? Even the dumb 'evolution' picture
on Power.org's site makes this quite, quite clear. Most of the
spec is identical, to the letter, over vast amounts of pages.
There are change bars in front of everything that changed and
those that have; it seems they are just lifted and reworked
from Freescale's AltiVec/SPE documentation, reworded in Book E
so you can have a Book E with AltiVec, or has it's own new
book (VLE, which is an IBM-ified copy of the e200 Core
Reference Manual Addendum)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Paul Mackerras wrote:
> Matt Sealey writes:
>
>> http://www.power.org/news/articles/new_brand/#isa
>>
>> I'm talking about the one they consolidated from all the different specs
>> Freescale, AMCC and IBM had about what makes a PowerPC processor. Since
>> POWER is part of it and it's all Power.org now.. they seem to have changed
>> the name.
>
> So, are you proposing we drop support for all the PowerPC processors
> that don't conform to the recently-published V2.03 ISA? You don't
> want 6xx, 7xx, 7xxx, 52xx, etc. supported any more? :) (joke :)
>
> Seriously, the v2.03 ISA covers only IBM's latest POWER processors
> (i.e. not POWER3, POWER4, or even POWER5), and Book E processors. We
> support a lot more than that.
>
> Paul.
^ permalink raw reply
* Re: Using WindRiver Probe JTAG
From: Michael Zagalsky @ 2006-10-25 14:49 UTC (permalink / raw)
To: Steven Hein; +Cc: linuxppc-embedded
In-Reply-To: <453F5FF2.6010307@sgi.com>
[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]
Thanks, Steven. It does help.
On 10/25/06, Steven Hein <ssh@sgi.com> wrote:
>
> Hi Michael,
>
> We just went through this same selection process for a new project
> (MPC83xx based), and we ended up choosing the BDI2000.
> I asked WindRiver folks the same question, regarding the WR ICE
> interaction with GDB. They told me that they do not play together,
> WR ICE uses WR proprietary communication to the debugger SW.
>
> If you're already using WR workbench, I think your only option
> is to use the WR ice. (When we evaluated WR tools for our project,
> it seemed like going with WR is an all-or-nothing deal--and we already
> had experience with the GCC toolchains, GDB debugger, etc. So, we
> chose the GCC/GDB/BDI2000 approach).
>
> Hope this helps.
>
> Steve
>
>
> Michael Zagalsky wrote:
>
> Hi guys.
> I'd like to know if anybody had an experience using Wind River Probe JTAG
> with PowerPC architecture in general, and with PowerQuicc iii family in
> particular.
> We're using WR workbench, but I am not sure whether to use their JTAG or
> the popular BDI2000.
> Does anybody know if WR Probe uses GDB, or something proprietary to WR?
> Can it be attached to gdb/ddd/eclipse, or only to WR workbench IDE?
> For kernel debugging with symbolic information - can it use any binary
> compiled with -g, or it has to be compiled under WR workbench environment
> that has some add-ons (I know, it sounds strange - but I actually heard some
> vague saying of this kind from WR representative).
>
> I know those are questions that should be addressed to Wind River , which
> I did, but I didn't get clear enough answers - so your (good/bad) field
> experience could be very helpful.
>
> Thanks a lot,
> Michael
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing listLinuxppc-embedded@ozlabs.orghttps://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Steve Hein (ssh@sgi.com) Engineering Diagnostics/Software
> Silicon Graphics, Inc.
> 1168 Industrial Blvd. Phone: (715) 726-8410
> Chippewa Falls, WI 54729 Fax: (715) 726-6715
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
[-- Attachment #2: Type: text/html, Size: 3332 bytes --]
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Kumar Gala @ 2006-10-25 14:50 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <453F7832.2020305@genesi-usa.com>
On Oct 25, 2006, at 9:44 AM, Matt Sealey wrote:
> It supports the original processors, G3, G4 etc. as well. Maybe not
> the 601? I'm not sure. All the PowerPC ISA Books are in there and
> information only seems to have been ADDED (or moved to another
> book or been given a new book).
>
> If a processor is not supported it was probably designed and
> end-of-lined well before they made the original "Book" specs :D
>
> Have you even looked at it? Even the dumb 'evolution' picture
> on Power.org's site makes this quite, quite clear. Most of the
> spec is identical, to the letter, over vast amounts of pages.
> There are change bars in front of everything that changed and
> those that have; it seems they are just lifted and reworked
> from Freescale's AltiVec/SPE documentation, reworded in Book E
> so you can have a Book E with AltiVec, or has it's own new
> book (VLE, which is an IBM-ified copy of the e200 Core
> Reference Manual Addendum)
There is far more new in the 2.03 spec than just merging of various
existing specs as you are stating. Please be more careful with
general statements like this. The Book III-E has some significant
changes from Book-E 1.0.
- k
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Matt Sealey @ 2006-10-25 14:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <0728ABEB-7D51-4694-9AB9-EE631DE8453E@kernel.crashing.org>
Kumar Gala wrote:
>
>> so you can have a Book E with AltiVec, or has it's own new
>> book (VLE, which is an IBM-ified copy of the e200 Core
>> Reference Manual Addendum)
>
> There is far more new in the 2.03 spec than just merging of various
> existing specs as you are stating. Please be more careful with general
> statements like this. The Book III-E has some significant changes from
> Book-E 1.0.
I don't think any of it suddenly makes a billion existing processors
completely incompatible.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Grant Likely @ 2006-10-25 14:57 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <453F7832.2020305@genesi-usa.com>
On 10/25/06, Matt Sealey <matt@genesi-usa.com> wrote:
> It supports the original processors, G3, G4 etc. as well. Maybe not
> the 601? I'm not sure. All the PowerPC ISA Books are in there and
> information only seems to have been ADDED (or moved to another
> book or been given a new book).
Why are we still talking about this? None of it matters.
Who cares if the new ISA spec incorporates all of the old ones? The
old specs cannot be unpublished. powerpc is a sufficient name for
kernel source purposes and it will continue to have meaning in the
minds of developers. Marketing glossies can (and do) use the name de
jour, but we don't have to.
As a side note; The move from ppc/ppc64->powerpc was a *technical*
decision, not a marketing one. It was done so there would be only one
code base. The choice of arch/powerpc was almost arbitrary.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Matt Sealey @ 2006-10-25 16:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <528646bc0610250757i3754fc96uccddd8109f3a712@mail.gmail.com>
Arbitrary naming is fine.
Thinking up a bunch of excuses like "we refuse to bow to our corporate
marketing overlords" and "but it's definitely called PowerPC ISA, and
anyway, that new one which has a new name, I didn't read anyway, but it
undefines every processor we support" is just.. well I dunno. Making
excuses I guess.
I'm fine with the name I was just curious (see first line of the original
email) about how these things ARE named. It lead to a query I am still
wondering about the answer to; Genesi/bplan could have a new G5 platform
and whatever support code is required submitted to the tree soon. Since
it will have a fairly-PAPR-compliant firmware, this makes it logical to
put it in the CHRP platform for us. But CHRP doesn't include LPAR, this is
a pSeries platform feature. Segher suggested we use the Maple tree (!!)
as this runs SLOF.
What platform do you think a 970MP box with a CHRP-compliant (well, let
us say, Pegasos-compatible) firmware go, if we eventually want to support
LPAR, especially without code duplication and MBs of "pull this out of
pSeries and drop it into CHRP, even though CHRP technically doesn't
support any of this" stuff? Especially since Ben is being quite strict
about what goes into CHRP nowadays.
Is it time for a PAPR platform? Or is that against the Linux
anti-marketing-name lobby we have in here?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Grant Likely wrote:
> On 10/25/06, Matt Sealey <matt@genesi-usa.com> wrote:
>> It supports the original processors, G3, G4 etc. as well. Maybe not
>> the 601? I'm not sure. All the PowerPC ISA Books are in there and
>> information only seems to have been ADDED (or moved to another
>> book or been given a new book).
>
> Why are we still talking about this? None of it matters.
>
> Who cares if the new ISA spec incorporates all of the old ones? The
> old specs cannot be unpublished. powerpc is a sufficient name for
> kernel source purposes and it will continue to have meaning in the
> minds of developers. Marketing glossies can (and do) use the name de
> jour, but we don't have to.
>
> As a side note; The move from ppc/ppc64->powerpc was a *technical*
> decision, not a marketing one. It was done so there would be only one
> code base. The choice of arch/powerpc was almost arbitrary.
>
> Cheers,
> g.
>
^ permalink raw reply
* Re: [PATCH 2.6.19-rc3 2/2] ehea: 64K page support fix
From: Anton Blanchard @ 2006-10-25 16:21 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <200610251312.01235.ossthema@de.ibm.com>
Hi,
> +#ifdef CONFIG_PPC_64K_PAGES
> + /* To support 64k pages we must round to 64k page boundary */
> + epas->kernel.addr =
> + ioremap((paddr_kernel & 0xFFFFFFFFFFFF0000), PAGE_SIZE) +
> + (paddr_kernel & 0xFFFF);
> +#else
> epas->kernel.addr = ioremap(paddr_kernel, PAGE_SIZE);
> +#endif
Cant you just use PAGE_MASK, ~PAGE_MASK and remove the ifdefs
completely?
Anton
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Olof Johansson @ 2006-10-25 17:08 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Paul, Mackerras
In-Reply-To: <453F8E63.7090907@genesi-usa.com>
On Wed, 25 Oct 2006 18:18:43 +0200 Matt Sealey <matt@genesi-usa.com> wrote:
> Is it time for a PAPR platform?
There is a PAPR platform in the tree already, it's named pseries.
-Olof
^ permalink raw reply
* [PATCH] General CHRP/MPC5K2 platform support patch
From: Nicolas DET @ 2006-10-25 19:05 UTC (permalink / raw)
To: linuxppc-dev, sl, akpm, Benjamin Herrenschmidt, Sylvain Munaut,
grant.likely, linuxppc-embedded, sha
[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]
This patch add support for MPC52xx/CHRP/OFW platform.
It contains the minimal changes required: platform/chrp/ and the
interrupt controller code.
This one is slightly different than the one I submitted previously.
http://ozlabs.org/pipermail/linuxppc-dev/2006-October/027133.html
* /proc/ppc64/rtas/ I left it for now. It's not really the concern of
this patch.
* mpc5k2_bestcomm.c (& helpers): I've been in contact with others people
using bestcomm and please to see the development was still active. I'm
already using latest code on my board but this is not include in this
patch. Indeed, it needs some changes for ARCH=powerpc. Moreover, we have
a different approach for the tasks. I'll be pleased to work with the
bestcomm folks.
* mpc5k2.c: As far as I understood, using of_platform_device will allow
'smart' of tree parsing. I did not implement it yet.
* mpc5k2_pic.c : The thingy ;-). I moved it into arch/powerpc/sysdev as
suggested. This code is 99% copy/paste from the ARCH=ppc. I added an
irq_host with the appropriate xlate and co. However, I have not done
more as this code has been written by others. I think we should work
together to move to new Linux style irq. I stay ready to test or code
upcoming revision/
* arch/powerpc/platform/*. Here, only small changes has been made. I
added _CHRP_E5K2 (in asm/processor.h), an entry in chrp_names() and the
correct detection in arch/powerpc/platform/setup.c / chrp_setup_arch().
in chrp_init_IRQ(), I set ppc_md.get_irq to mpc52xx_get_irq and call
mpc52xx_init_irq().
* fec driver: I did not wrote it and just made small modification to
make it works with our bestcomm API. However, we will soon you the same.
I think this is out of topic for his patch.
* serial stuff / IBP Freq. As this frequency is MPC52xx specific. I
think it would make sense to add a new func mpc52xx_getipbfreq(void).
The way it would be implemented may depend of the architecture. Our
firmware contains an 'ipb-freq' property in '/builtin/'.
Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
Signed-off-by: Sven Luther <sl@bplan-gmbh.de>
[-- Attachment #2: chrpmpc52xx_2.6.19-rc3.patch --]
[-- Type: text/plain, Size: 15074 bytes --]
diff -uprN a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
--- a/arch/powerpc/platforms/chrp/setup.c 2006-10-25 19:07:23.000000000 +0200
+++ b/arch/powerpc/platforms/chrp/setup.c 2006-10-25 19:10:18.000000000 +0200
@@ -51,6 +51,7 @@
#include <asm/mpic.h>
#include <asm/rtas.h>
#include <asm/xmon.h>
+#include <asm/mpc52xx.h>
#include "chrp.h"
@@ -101,7 +102,8 @@ static const char *chrp_names[] = {
"Motorola",
"IBM or Longtrail",
"Genesi Pegasos",
- "Total Impact Briq"
+ "Total Impact Briq",
+ "bPlan Efika"
};
void chrp_show_cpuinfo(struct seq_file *m)
@@ -260,6 +262,8 @@ void __init chrp_setup_arch(void)
machine = get_property(root, "model", NULL);
if (machine && strncmp(machine, "Pegasos", 7) == 0) {
_chrp_type = _CHRP_Pegasos;
+ } else if (machine && strncmp(machine, "EFIKA5K2", 8) == 0) {
+ _chrp_type =_CHRP_E5K2;
} else if (machine && strncmp(machine, "IBM", 3) == 0) {
_chrp_type = _CHRP_IBM;
} else if (machine && strncmp(machine, "MOT", 3) == 0) {
@@ -494,6 +498,12 @@ void __init chrp_init_IRQ(void)
#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
struct device_node *kbd;
#endif
+ if (_chrp_type == _CHRP_E5K2) {
+ ppc_md.get_irq = mpc52xx_get_irq;
+ mpc52xx_init_irq();
+ return;
+ }
+
chrp_find_openpic();
chrp_find_8259();
@@ -530,6 +540,9 @@ chrp_init2(void)
chrp_nvram_init();
#endif
+ if (_chrp_type == _CHRP_E5K2)
+ return;
+
request_region(0x20,0x20,"pic1");
request_region(0xa0,0x20,"pic2");
request_region(0x00,0x20,"dma1");
diff -uprN a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h
--- a/include/asm-powerpc/processor.h 2006-10-25 19:07:48.000000000 +0200
+++ b/include/asm-powerpc/processor.h 2006-10-25 19:11:54.000000000 +0200
@@ -33,6 +33,7 @@
#define _CHRP_IBM 0x05 /* IBM chrp, the longtrail and longtrail 2 */
#define _CHRP_Pegasos 0x06 /* Genesi/bplan's Pegasos and Pegasos2 */
#define _CHRP_briq 0x07 /* TotalImpact's briQ */
+#define _CHRP_E5K2 0x08 /* bPlan's Efika 5k2*/
#if defined(__KERNEL__) && defined(CONFIG_PPC32)
diff -uprN a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h
--- a/include/asm-ppc/mpc52xx.h 2006-10-25 19:07:48.000000000 +0200
+++ b/include/asm-ppc/mpc52xx.h 2006-10-25 19:11:55.000000000 +0200
@@ -119,7 +119,7 @@ enum ppc_sys_devices {
#define MPC52xx_SDMA_IRQ_NUM 17
#define MPC52xx_PERP_IRQ_NUM 23
-#define MPC52xx_CRIT_IRQ_BASE 1
+#define MPC52xx_CRIT_IRQ_BASE 0
#define MPC52xx_MAIN_IRQ_BASE (MPC52xx_CRIT_IRQ_BASE + MPC52xx_CRIT_IRQ_NUM)
#define MPC52xx_SDMA_IRQ_BASE (MPC52xx_MAIN_IRQ_BASE + MPC52xx_MAIN_IRQ_NUM)
#define MPC52xx_PERP_IRQ_BASE (MPC52xx_SDMA_IRQ_BASE + MPC52xx_SDMA_IRQ_NUM)
@@ -415,7 +415,7 @@ struct mpc52xx_cdm {
#ifndef __ASSEMBLY__
extern void mpc52xx_init_irq(void);
-extern int mpc52xx_get_irq(void);
+extern unsigned int mpc52xx_get_irq(void);
extern unsigned long mpc52xx_find_end_of_memory(void);
extern void mpc52xx_set_bat(void);
--- a/arch/powerpc/sysdev/mpc52xx_pic.c 1970-01-01 01:00:00.000000000 +0100
+++ b/arch/powerpc/sysdev/mpc52xx_pic.c 2006-10-25 19:17:48.000000000 +0200
@@ -0,0 +1,375 @@
+/*
+ * arch/powerpc/platforms/mpc5k2_pic.c
+ *
+ * Programmable Interrupt Controller functions for the Freescale MPC52xx
+ * embedded CPU.
+ * Modified for CHRP Efika 5K2
+ *
+ * Maintainer : Sylvain Munaut <tnt@246tNt.com>
+ *
+ * Based on (well, mostly copied from) the code from the 2.4 kernel by
+ * Dale Farnsworth <dfarnsworth@mvista.com> and Kent Borg.
+ *
+ * Copyright (C) 2004 Sylvain Munaut <tnt@246tNt.com>
+ * Copyright (C) 2003 Montavista Software, Inc
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+//#define DEBUG
+
+#include <linux/stddef.h>
+#include <linux/init.h>
+#include <linux/sched.h>
+#include <linux/signal.h>
+#include <linux/stddef.h>
+#include <linux/delay.h>
+#include <linux/irq.h>
+
+#include <asm/io.h>
+#include <asm/processor.h>
+#include <asm/system.h>
+#include <asm/irq.h>
+#include <asm/prom.h>
+
+#include <asm/mpc52xx.h>
+
+static struct mpc52xx_intr __iomem *intr;
+static struct mpc52xx_sdma __iomem *sdma;
+
+
+static struct irq_host *mpc52xx_irqhost = NULL;
+
+static void
+mpc52xx_ic_disable(unsigned int virq)
+{
+ u32 val;
+ int irq;
+
+ irq = irq_map[virq].hwirq;
+
+ pr_debug("%s: irq=%d\n", __func__, irq);
+
+ if (irq == MPC52xx_IRQ0) {
+ val = in_be32(&intr->ctrl);
+ val &= ~(1 << 11);
+ out_be32(&intr->ctrl, val);
+ } else if (irq < MPC52xx_IRQ1) {
+ BUG();
+ } else if (irq <= MPC52xx_IRQ3) {
+ val = in_be32(&intr->ctrl);
+ val &= ~(1 << (10 - (irq - MPC52xx_IRQ1)));
+ out_be32(&intr->ctrl, val);
+ } else if (irq < MPC52xx_SDMA_IRQ_BASE) {
+ val = in_be32(&intr->main_mask);
+ val |= 1 << (16 - (irq - MPC52xx_MAIN_IRQ_BASE));
+ out_be32(&intr->main_mask, val);
+ } else if (irq < MPC52xx_PERP_IRQ_BASE) {
+ val = in_be32(&sdma->IntMask);
+ val |= 1 << (irq - MPC52xx_SDMA_IRQ_BASE);
+ out_be32(&sdma->IntMask, val);
+ } else {
+ val = in_be32(&intr->per_mask);
+ val |= 1 << (31 - (irq - MPC52xx_PERP_IRQ_BASE));
+ out_be32(&intr->per_mask, val);
+ }
+}
+
+static void
+mpc52xx_ic_enable(unsigned int virq)
+{
+ u32 val;
+ int irq;
+
+ irq = irq_map[virq].hwirq;
+
+ pr_debug("%s: irq=%d\n", __func__, irq);
+
+ if (irq == MPC52xx_IRQ0) {
+ val = in_be32(&intr->ctrl);
+ val |= 1 << 11;
+ out_be32(&intr->ctrl, val);
+ } else if (irq < MPC52xx_IRQ1) {
+ BUG();
+ } else if (irq <= MPC52xx_IRQ3) {
+ val = in_be32(&intr->ctrl);
+ val |= 1 << (10 - (irq - MPC52xx_IRQ1));
+ out_be32(&intr->ctrl, val);
+ } else if (irq < MPC52xx_SDMA_IRQ_BASE) {
+ val = in_be32(&intr->main_mask);
+ val &= ~(1 << (16 - (irq - MPC52xx_MAIN_IRQ_BASE)));
+ out_be32(&intr->main_mask, val);
+ } else if (irq < MPC52xx_PERP_IRQ_BASE) {
+ val = in_be32(&sdma->IntMask);
+ val &= ~(1 << (irq - MPC52xx_SDMA_IRQ_BASE));
+ out_be32(&sdma->IntMask, val);
+ } else {
+ val = in_be32(&intr->per_mask);
+ val &= ~(1 << (31 - (irq - MPC52xx_PERP_IRQ_BASE)));
+ out_be32(&intr->per_mask, val);
+ }
+}
+
+static void
+mpc52xx_ic_ack(unsigned int virq)
+{
+ u32 val;
+ int irq;
+
+ irq = irq_map[virq].hwirq;
+
+ pr_debug("%s: irq=%d\n", __func__, irq);
+
+ /*
+ * Only some irqs are reset here, others in interrupting hardware.
+ */
+
+ switch (irq) {
+ case MPC52xx_IRQ0:
+ val = in_be32(&intr->ctrl);
+ val |= 0x08000000;
+ out_be32(&intr->ctrl, val);
+ break;
+ case MPC52xx_CCS_IRQ:
+ val = in_be32(&intr->enc_status);
+ val |= 0x00000400;
+ out_be32(&intr->enc_status, val);
+ break;
+ case MPC52xx_IRQ1:
+ val = in_be32(&intr->ctrl);
+ val |= 0x04000000;
+ out_be32(&intr->ctrl, val);
+ break;
+ case MPC52xx_IRQ2:
+ val = in_be32(&intr->ctrl);
+ val |= 0x02000000;
+ out_be32(&intr->ctrl, val);
+ break;
+ case MPC52xx_IRQ3:
+ val = in_be32(&intr->ctrl);
+ val |= 0x01000000;
+ out_be32(&intr->ctrl, val);
+ break;
+ default:
+ if (irq >= MPC52xx_SDMA_IRQ_BASE
+ && irq < (MPC52xx_SDMA_IRQ_BASE + MPC52xx_SDMA_IRQ_NUM)) {
+ out_be32(&sdma->IntPend,
+ 1 << (irq - MPC52xx_SDMA_IRQ_BASE));
+ }
+
+ break;
+ }
+
+}
+
+static void
+mpc52xx_ic_disable_and_ack(unsigned int irq)
+{
+ mpc52xx_ic_disable(irq);
+ mpc52xx_ic_ack(irq);
+}
+
+static void
+mpc52xx_ic_end(unsigned int irq)
+{
+ if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
+ mpc52xx_ic_enable(irq);
+}
+
+static struct irq_chip mpc52xx_irqchip = {
+ .name = " MPC52xx ",
+ .enable = mpc52xx_ic_enable,
+ .disable = mpc52xx_ic_disable,
+ .ack = mpc52xx_ic_disable_and_ack,
+ .end = mpc52xx_ic_end,
+};
+
+static int mpc52xx_irqhost_match(struct irq_host *h, struct device_node *node)
+{
+ pr_debug("%s: node=%p\n", __func__, node);
+
+ if ( device_is_compatible(node, "mpc52xx-pic") )
+ return 1;
+
+ return device_is_compatible(node, "mpc5200-pic");
+}
+
+
+static int mpc52xx_irqhost_xlate(struct irq_host *h, struct device_node *ct,
+ u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq, unsigned int *out_flags)
+{
+ static unsigned char map_senses[4] = {
+ IRQ_TYPE_LEVEL_HIGH,
+ IRQ_TYPE_EDGE_FALLING,
+ IRQ_TYPE_EDGE_RISING,
+ IRQ_TYPE_LEVEL_LOW,
+ };
+
+ int intrvect_l1;
+ int intrvect_l2;
+ int intrvect_type;
+ int intrvect_linux;
+
+ pr_debug("%s:\n", __func__);
+
+ if (intsize!=3)
+ return -1;
+
+ intrvect_l1 = (int) intspec[0];
+ intrvect_l2 = (int) intspec[1];
+ intrvect_type = (int) intspec[2];
+
+ pr_debug("l1=%d, l2=%d, type=%d\n", intrvect_l1, intrvect_l2, intrvect_type );
+
+ switch(intrvect_l1) {
+ case 0: /* Critical */
+ intrvect_linux = MPC52xx_CRIT_IRQ_BASE;
+ break;
+
+ case 1: /* Main */
+ intrvect_linux = MPC52xx_MAIN_IRQ_BASE;
+ break;
+
+ case 2: /* Periph */
+ intrvect_linux = MPC52xx_PERP_IRQ_BASE;
+ break;
+
+ case 3: /* Bestcomm */
+ intrvect_linux = MPC52xx_SDMA_IRQ_BASE;
+ break;
+
+ default:
+ if ( printk_ratelimit() )
+ printk(KERN_ERR "Wrong L1 interrupt vector (%d)\n", intrvect_l1);
+
+ return -1;
+ }
+
+ intrvect_linux += intrvect_l2;
+
+ pr_debug("return %d\n", intrvect_linux);
+
+ *out_hwirq = intrvect_linux;
+ *out_flags = map_senses[intrvect_type];
+
+ return 0;
+
+}
+
+int mpc52xx_irqhost_map(struct irq_host *h, unsigned int virq, irq_hw_number_t hw)
+{
+ pr_debug("%s: v=%d, hw=%d\n", __func__, virq, (int) hw);
+
+ return 0;
+}
+
+void mpc52xx_irqhost_unmap(struct irq_host *h, unsigned int virq)
+{
+ pr_debug("%s: v=%d\n", __func__, virq);
+}
+
+static struct irq_host_ops mpc52xx_irqhost_ops = {
+ .match = mpc52xx_irqhost_match,
+ .xlate = mpc52xx_irqhost_xlate,
+ .map = mpc52xx_irqhost_map,
+ .unmap = mpc52xx_irqhost_unmap,
+};
+
+void __init
+mpc52xx_init_irq(void)
+{
+ int i;
+ u32 intr_ctrl;
+
+
+ /* Remap the necessary zones */
+ intr = ioremap(MPC52xx_PA(MPC52xx_INTR_OFFSET), MPC52xx_INTR_SIZE);
+ sdma = ioremap(MPC52xx_PA(MPC52xx_SDMA_OFFSET), MPC52xx_SDMA_SIZE);
+
+ if ((intr==NULL) || (sdma==NULL))
+ panic("Can't ioremap PIC/SDMA register or init_irq !");
+
+ /* Disable all interrupt sources. */
+ out_be32(&sdma->IntPend, 0xffffffff); /* 1 means clear pending */
+ out_be32(&sdma->IntMask, 0xffffffff); /* 1 means disabled */
+ out_be32(&intr->per_mask, 0x7ffffc00); /* 1 means disabled */
+ out_be32(&intr->main_mask, 0x00010fff); /* 1 means disabled */
+ intr_ctrl = in_be32(&intr->ctrl);
+ intr_ctrl &= 0x00ff0000; /* Keeps IRQ[0-3] config */
+ intr_ctrl |= 0x0f000000 | /* clear IRQ 0-3 */
+ 0x00001000 | /* MEE master external enable */
+ 0x00000000 | /* 0 means disable IRQ 0-3 */
+ 0x00000001; /* CEb route critical normally */
+ out_be32(&intr->ctrl, intr_ctrl);
+
+ /* Zero a bunch of the priority settings. */
+ out_be32(&intr->per_pri1, 0);
+ out_be32(&intr->per_pri2, 0);
+ out_be32(&intr->per_pri3, 0);
+ out_be32(&intr->main_pri1, 0);
+ out_be32(&intr->main_pri2, 0);
+ /* Initialize irq_desc[i].handler's with mpc52xx_ic. */
+ for (i = 0; i < NR_IRQS; i++) {
+ irq_desc[i].chip = &mpc52xx_irqchip;
+ irq_desc[i].status = IRQ_LEVEL;
+
+ }
+
+#define IRQn_MODE(intr_ctrl,irq) (((intr_ctrl) >> (22-(i<<1))) & 0x03)
+ for (i=0 ; i<4 ; i++) {
+ int mode;
+ mode = IRQn_MODE(intr_ctrl,i);
+ if ((mode == 0x1) || (mode == 0x2))
+ irq_desc[i?MPC52xx_IRQ1+i-1:MPC52xx_IRQ0].status = 0;
+ }
+
+ /*
+ * As last step, add an irq host to translate the real
+ * hw irq information provided by the ofw to linux virq
+ */
+
+ mpc52xx_irqhost = irq_alloc_host(IRQ_HOST_MAP_LINEAR, 0, &mpc52xx_irqhost_ops, -1);
+ pr_debug("%s: mpc52xx_irqhost =%p\n", __func__, mpc52xx_irqhost );
+}
+
+unsigned int
+mpc52xx_get_irq(void)
+{
+ u32 status;
+ int virq;
+ int irq = NO_IRQ_IGNORE;
+
+ status = in_be32(&intr->enc_status);
+ if (status & 0x00000400)
+ { /* critical */
+ irq = (status >> 8) & 0x3;
+ if (irq == 2) /* high priority peripheral */
+ goto peripheral;
+ irq += MPC52xx_CRIT_IRQ_BASE;
+ } else if (status & 0x00200000)
+ { /* main */
+ irq = (status >> 16) & 0x1f;
+ if (irq == 4) /* low priority peripheral */
+ goto peripheral;
+ irq += MPC52xx_MAIN_IRQ_BASE;
+ } else if (status & 0x20000000)
+ { /* peripheral */
+peripheral:
+ irq = (status >> 24) & 0x1f;
+ if (irq == 0) { /* bestcomm */
+ status = in_be32(&sdma->IntPend);
+ irq = ffs(status) + MPC52xx_SDMA_IRQ_BASE-1;
+ } else
+ irq += MPC52xx_PERP_IRQ_BASE;
+
+ }
+
+ virq = irq_linear_revmap(mpc52xx_irqhost, irq);
+ pr_debug("%s: irq=%d -> %d\n", __func__, irq, virq);
+
+ return virq;
+}
+
--- a/arch/powerpc/sysdev/Makefile 2006-10-25 19:07:24.000000000 +0200
+++ b/arch/powerpc/sysdev/Makefile 2006-10-25 20:33:32.000000000 +0200
@@ -13,6 +13,7 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_PPC_TODC) += todc.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
+obj-$(CONFIG_PPC_CHRP) += mpc52xx_pic.o
ifeq ($(CONFIG_PPC_MERGE),y)
obj-$(CONFIG_PPC_I8259) += i8259.o
[-- Attachment #3: nd.vcf --]
[-- Type: text/x-vcard, Size: 249 bytes --]
begin:vcard
fn:Nicolas DET ( bplan GmbH )
n:DET;Nicolas
org:bplan GmbH
adr:;;;;;;Germany
email;internet:nd@bplan-gmbh.de
title:Software Entwicklung
tel;work:+49 6171 9187 - 31
x-mozilla-html:FALSE
url:http://www.bplan-gmbh.de
version:2.1
end:vcard
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox