[patch 1/2] powerpc: Print progress of ibm, client-architecture method
The ibm,client-architecture method will often cause a reconfiguration reboot.
When this happens the last thing we see is:
Hypertas detected, assuming LPAR !
Which doesn't explain what just happened. Wrap the ibm,client-architecture
so it's clear what is going on:
Calling ibm,client-architecture... done
In order to maintain the law of conservation of screen real estate, downgrade
two other messages to debug.
Signed-off-by: Anton Blanchard an...@samba.org
---
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 7f1b33d..d5414fe 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -732,15 +732,17 @@ static void __init prom_send_capabilities(void)
root = call_prom(open, 1, 1, ADDR(/));
if (root != 0) {
/* try calling the ibm,client-architecture-support method */
+ prom_printf(Calling ibm,client-architecture...);
if (call_prom_ret(call-method, 3, 2, ret,
ADDR(ibm,client-architecture-support),
root,
ADDR(ibm_architecture_vec)) == 0) {
/* the call exists... */
if (ret)
- prom_printf(WARNING: ibm,client-architecture
+ prom_printf(\nWARNING: ibm,client-architecture
-support call FAILED!\n);
call_prom(close, 1, 0, root);
+ prom_printf( done\n);
return;
}
call_prom(close, 1, 0, root);
@@ -1495,7 +1497,7 @@ static int __init prom_find_machine_type(void)
return PLATFORM_GENERIC;
x = prom_getproplen(rtas, ibm,hypertas-functions);
if (x != PROM_ERROR) {
- prom_printf(Hypertas detected, assuming LPAR !\n);
+ prom_debug(Hypertas detected, assuming LPAR !\n);
return PLATFORM_PSERIES_LPAR;
}
return PLATFORM_PSERIES;
@@ -1544,7 +1546,7 @@ static void __init prom_check_displays(void)
};
const unsigned char *clut;
- prom_printf(Looking for displays\n);
+ prom_debug(Looking for displays\n);
for (node = 0; prom_next_node(node); ) {
memset(type, 0, sizeof(type));
prom_getprop(node, device_type, type, sizeof(type));
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/2] Some prom_init cleanups
Some patches to make the ibm,client-architecture behaviour more obvious as well as small formatting fixes. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/2] powerpc: Clean up some prom printouts
Make all messages consistent, some have spaces before the ..., some do not.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: linux-2.6/arch/powerpc/kernel/prom_init.c
===
--- linux-2.6.orig/arch/powerpc/kernel/prom_init.c 2009-04-01
16:19:01.0 +1100
+++ linux-2.6/arch/powerpc/kernel/prom_init.c 2009-04-01 16:19:03.0
+1100
@@ -1085,7 +1085,7 @@
return;
}
- prom_printf(instantiating rtas at 0x%x ..., base);
+ prom_printf(instantiating rtas at 0x%x..., base);
if (call_prom_ret(call-method, 3, 2, entry,
ADDR(instantiate-rtas),
@@ -1564,7 +1564,7 @@
if (call_prom(package-to-path, 3, 1, node, path,
PROM_SCRATCH_SIZE-10) == PROM_ERROR)
continue;
- prom_printf(found display : %s, opening ... , path);
+ prom_printf(found display : %s, opening... , path);
ih = call_prom(open, 1, 1, path);
if (ih == 0) {
@@ -2389,7 +2389,7 @@
/*
* Now finally create the flattened device-tree
*/
- prom_printf(copying OF device tree ...\n);
+ prom_printf(copying OF device tree...\n);
flatten_device_tree();
/*
@@ -2404,7 +2404,7 @@
* Call OF quiesce method to shut down pending DMA's from
* devices etc...
*/
- prom_printf(Calling quiesce ...\n);
+ prom_printf(Calling quiesce...\n);
call_prom(quiesce, 0, 0);
/*
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc: Enable relay in pseries_defconfig
Enable relay in pseries config, ppc64_defconfig had it enabled but pseries did not. Signed-off-by: Anton Blanchard an...@samba.org --- diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index 61b1008..f1889ab 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -95,7 +95,7 @@ CONFIG_CGROUP_CPUACCT=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_RELAY is not set +CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc: Fix ibm,client-architecture comment
We specify a 64MB RMO, but the comment says 128MB.
Signed-off-by: Anton Blanchard an...@samba.org
---
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 7f1b33d..ddd9561 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -614,7 +614,7 @@ static unsigned char ibm_architecture_vec[] = {
W(0x), /* virt_base */
W(0x), /* virt_size */
W(0x), /* load_base */
- W(64), /* 128MB min RMA */
+ W(64), /* 64MB min RMA */
W(0x), /* full client load */
0, /* min RMA percentage of total RAM */
48, /* max log_2(hash table size) */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc: Scan for all events in rtasd
Instead of checking for known events, pass in all 1s so we handle future
event types. We were currently missing the IO event type.
Signed-off-by: Anton Blanchard an...@samba.org
---
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 0aa0315..01c1233 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -68,7 +68,8 @@ struct rtas_t {
#define RTAS_EPOW_WARNING 0x4000 /* set bit 1 */
#define RTAS_POWERMGM_EVENTS 0x2000 /* set bit 2 */
#define RTAS_HOTPLUG_EVENTS0x1000 /* set bit 3 */
-#define RTAS_EVENT_SCAN_ALL_EVENTS 0xf000
+#define RTAS_IO_EVENTS 0x0800 /* set bit 4 */
+#define RTAS_EVENT_SCAN_ALL_EVENTS 0x
/* RTAS event severity */
#define RTAS_SEVERITY_FATAL0x5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc: Add dispatch diversion statistics
PHYP tells us how often a shared processor dispatch changed physical cpus.
This can highlight performance problems caused by the hypervisor.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: linux-2.6/arch/powerpc/include/asm/lppaca.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/lppaca.h2009-02-28
18:37:02.0 +1100
+++ linux-2.6/arch/powerpc/include/asm/lppaca.h 2009-02-28 18:37:07.0
+1100
@@ -125,7 +125,7 @@
// NOTE: This value will ALWAYS be zero for dedicated processors and
// will NEVER be zero for shared processors (ie, initialized to a 1).
volatile u32 yield_count; // PLIC increments each dispatchx00-x03
- u32 reserved6;
+ volatile u32 dispersion_count; // dispatch changed phys cpux04-x07
volatile u64 cmo_faults;// CMO page fault count x08-x0F
volatile u64 cmo_fault_time;// CMO page fault time x10-x17
u8 reserved7[104]; // Reserved x18-x7F
Index: linux-2.6/arch/powerpc/kernel/lparcfg.c
===
--- linux-2.6.orig/arch/powerpc/kernel/lparcfg.c2009-02-28
18:37:02.0 +1100
+++ linux-2.6/arch/powerpc/kernel/lparcfg.c 2009-02-28 18:38:50.0
+1100
@@ -434,6 +434,21 @@
seq_printf(m, cmo_page_size=%lu\n, cmo_get_page_size());
}
+static void splpar_dispatch_data(struct seq_file *m)
+{
+ int cpu;
+ unsigned long dispatches = 0;
+ unsigned long dispatch_dispersions = 0;
+
+ for_each_possible_cpu(cpu) {
+ dispatches += lppaca[cpu].yield_count;
+ dispatch_dispersions += lppaca[cpu].dispersion_count;
+ }
+
+ seq_printf(m, dispatches=%lu\n, dispatches);
+ seq_printf(m, dispatch_dispersions=%lu\n, dispatch_dispersions);
+}
+
static int pseries_lparcfg_data(struct seq_file *m, void *v)
{
int partition_potential_processors;
@@ -460,6 +475,7 @@
parse_ppp_data(m);
parse_mpp_data(m);
pseries_cmo_data(m);
+ splpar_dispatch_data(m);
seq_printf(m, purr=%ld\n, get_purr());
} else {/* non SPLPAR case */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3] Series short description
Hi David, Here are the fec_mpc52xx patches which should be picked up for 2.6.29. Patch #1 fixes a dma related BUG_ON() discovered after the merge window opened. #2 #3 were original a single patch posted prior to the merge window, but not having a s-o-b line from the original author held them up. In the end I rewrote it from scratch as two patches just so I can get them merged. #2 makes the driver use net_device_ops, and #3 fixes a NULL dereference. I've tested these patches on several MPC5200 platforms. drivers/net/fec_mpc52xx.c | 77 +--- 1 files changed, 44 insertions(+), 33 deletions(-) Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] net/fec_mpc52xx: fix BUG on missing dma_ops
From: Grant Likely grant.lik...@secretlab.ca
The driver triggers a BUG_ON() when allocating DMA buffers because the
arch/powerpc dma_ops aren't in the net_device's struct device. This
patch fixes the problem by using the parent of_device which does have
the correct dma_ops set.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Reviewed-by: Becky Bruce bec...@kernel.crashing.org
---
drivers/net/fec_mpc52xx.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 049b0a7..f99463f 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -129,7 +129,8 @@ static void mpc52xx_fec_free_rx_buffers(struct net_device
*dev, struct bcom_task
struct sk_buff *skb;
skb = bcom_retrieve_buffer(s, NULL, (struct bcom_bd **)bd);
- dma_unmap_single(dev-dev, bd-skb_pa, skb-len,
DMA_FROM_DEVICE);
+ dma_unmap_single(dev-dev.parent, bd-skb_pa, skb-len,
+DMA_FROM_DEVICE);
kfree_skb(skb);
}
}
@@ -150,7 +151,7 @@ static int mpc52xx_fec_alloc_rx_buffers(struct net_device
*dev, struct bcom_task
bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
bd-status = FEC_RX_BUFFER_SIZE;
- bd-skb_pa = dma_map_single(dev-dev, skb-data,
+ bd-skb_pa = dma_map_single(dev-dev.parent, skb-data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(rxtsk, skb);
@@ -388,7 +389,8 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb,
struct net_device *d
bcom_prepare_next_buffer(priv-tx_dmatsk);
bd-status = skb-len | BCOM_FEC_TX_BD_TFD | BCOM_FEC_TX_BD_TC;
- bd-skb_pa = dma_map_single(dev-dev, skb-data, skb-len,
DMA_TO_DEVICE);
+ bd-skb_pa = dma_map_single(dev-dev.parent, skb-data, skb-len,
+ DMA_TO_DEVICE);
bcom_submit_next_buffer(priv-tx_dmatsk, skb);
@@ -430,7 +432,8 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void
*dev_id)
struct bcom_fec_bd *bd;
skb = bcom_retrieve_buffer(priv-tx_dmatsk, NULL,
(struct bcom_bd **)bd);
- dma_unmap_single(dev-dev, bd-skb_pa, skb-len,
DMA_TO_DEVICE);
+ dma_unmap_single(dev-dev.parent, bd-skb_pa, skb-len,
+DMA_TO_DEVICE);
dev_kfree_skb_irq(skb);
}
@@ -455,7 +458,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void
*dev_id)
rskb = bcom_retrieve_buffer(priv-rx_dmatsk, status,
(struct bcom_bd **)bd);
- dma_unmap_single(dev-dev, bd-skb_pa, rskb-len,
DMA_FROM_DEVICE);
+ dma_unmap_single(dev-dev.parent, bd-skb_pa, rskb-len,
+DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status BCOM_FEC_RX_BD_ERRORS) {
@@ -464,7 +468,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void
*dev_id)
bcom_prepare_next_buffer(priv-rx_dmatsk);
bd-status = FEC_RX_BUFFER_SIZE;
- bd-skb_pa = dma_map_single(dev-dev, rskb-data,
+ bd-skb_pa = dma_map_single(dev-dev.parent,
+ rskb-data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv-rx_dmatsk, rskb);
@@ -499,7 +504,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void
*dev_id)
bcom_prepare_next_buffer(priv-rx_dmatsk);
bd-status = FEC_RX_BUFFER_SIZE;
- bd-skb_pa = dma_map_single(dev-dev, skb-data,
+ bd-skb_pa = dma_map_single(dev-dev.parent, skb-data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv-rx_dmatsk, skb);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] net/fec_mpc52xx: Migrate to net_device_ops.
From: Henk Stegeman henk.stege...@gmail.com
Since not using net_device_ops gets you shunned out the cool crowd,
this patch modifies the fec_mpc52xx Ethernet driver to provide the
management hooks via a struct net_device_ops.
Reported-by: Henk Stegeman henk.stege...@gmail.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/fec_mpc52xx.c | 36
1 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index f99463f..e4355d4 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -371,7 +371,7 @@ static int mpc52xx_fec_close(struct net_device *dev)
* invariant will hold if you make sure that the netif_*_queue()
* calls are done at the proper times.
*/
-static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb, struct net_device
*dev)
+static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
struct bcom_fec_bd *bd;
@@ -379,7 +379,7 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb,
struct net_device *d
if (bcom_queue_full(priv-tx_dmatsk)) {
if (net_ratelimit())
dev_err(dev-dev, transmit queue overrun\n);
- return 1;
+ return NETDEV_TX_BUSY;
}
spin_lock_irq(priv-lock);
@@ -400,7 +400,7 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb,
struct net_device *d
spin_unlock_irq(priv-lock);
- return 0;
+ return NETDEV_TX_OK;
}
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -890,6 +890,22 @@ static int mpc52xx_fec_ioctl(struct net_device *dev,
struct ifreq *rq, int cmd)
return mpc52xx_fec_phy_mii_ioctl(priv, if_mii(rq), cmd);
}
+static const struct net_device_ops mpc52xx_fec_netdev_ops = {
+ .ndo_open = mpc52xx_fec_open,
+ .ndo_stop = mpc52xx_fec_close,
+ .ndo_start_xmit = mpc52xx_fec_start_xmit,
+ .ndo_set_multicast_list = mpc52xx_fec_set_multicast_list,
+ .ndo_set_mac_address = mpc52xx_fec_set_mac_address,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_do_ioctl = mpc52xx_fec_ioctl,
+ .ndo_change_mtu = eth_change_mtu,
+ .ndo_tx_timeout = mpc52xx_fec_tx_timeout,
+ .ndo_get_stats = mpc52xx_fec_get_stats,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = mpc52xx_fec_poll_controller,
+#endif
+};
+
/* */
/* OF Driver*/
/* */
@@ -934,22 +950,10 @@ mpc52xx_fec_probe(struct of_device *op, const struct
of_device_id *match)
return -EBUSY;
/* Init ether ndev with what we have */
- ndev-open = mpc52xx_fec_open;
- ndev-stop = mpc52xx_fec_close;
- ndev-hard_start_xmit = mpc52xx_fec_hard_start_xmit;
- ndev-do_ioctl = mpc52xx_fec_ioctl;
+ ndev-netdev_ops= mpc52xx_fec_netdev_ops;
ndev-ethtool_ops = mpc52xx_fec_ethtool_ops;
- ndev-get_stats = mpc52xx_fec_get_stats;
- ndev-set_mac_address = mpc52xx_fec_set_mac_address;
- ndev-set_multicast_list = mpc52xx_fec_set_multicast_list;
- ndev-tx_timeout= mpc52xx_fec_tx_timeout;
ndev-watchdog_timeo= FEC_WATCHDOG_TIMEOUT;
ndev-base_addr = mem.start;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- ndev-poll_controller = mpc52xx_fec_poll_controller;
-#endif
-
- priv-t_irq = priv-r_irq = ndev-irq = NO_IRQ; /* IRQ are free for now
*/
spin_lock_init(priv-lock);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] net/fec_mpc52xx: Don't dereference phy_device if it is NULL
From: Grant Likely grant.lik...@secretlab.ca
The FEC Ethernet device isn't always attached to a phy. Be careful
not to dereference phy_device if it is NULL. Also eliminates an
unnecessary extra function from the ioctl path.
Reported-by: Henk Stegeman henk.stege...@gmail.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/fec_mpc52xx.c | 22 --
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index e4355d4..8bbe7f6 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -271,15 +271,6 @@ static void mpc52xx_fec_phy_stop(struct net_device *dev)
phy_write(priv-phydev, MII_BMCR, BMCR_PDOWN);
}
-static int mpc52xx_fec_phy_mii_ioctl(struct mpc52xx_fec_priv *priv,
- struct mii_ioctl_data *mii_data, int cmd)
-{
- if (!priv-phydev)
- return -ENOTSUPP;
-
- return phy_mii_ioctl(priv-phydev, mii_data, cmd);
-}
-
static void mpc52xx_fec_phy_hw_init(struct mpc52xx_fec_priv *priv)
{
struct mpc52xx_fec __iomem *fec = priv-fec;
@@ -852,12 +843,20 @@ static void mpc52xx_fec_get_drvinfo(struct net_device
*dev,
static int mpc52xx_fec_get_settings(struct net_device *dev, struct ethtool_cmd
*cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv-phydev)
+ return -ENODEV;
+
return phy_ethtool_gset(priv-phydev, cmd);
}
static int mpc52xx_fec_set_settings(struct net_device *dev, struct ethtool_cmd
*cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv-phydev)
+ return -ENODEV;
+
return phy_ethtool_sset(priv-phydev, cmd);
}
@@ -887,7 +886,10 @@ static int mpc52xx_fec_ioctl(struct net_device *dev,
struct ifreq *rq, int cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
- return mpc52xx_fec_phy_mii_ioctl(priv, if_mii(rq), cmd);
+ if (!priv-phydev)
+ return -ENOTSUPP;
+
+ return phy_mii_ioctl(priv-phydev, if_mii(rq), cmd);
}
static const struct net_device_ops mpc52xx_fec_netdev_ops = {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ppc64] 2.6.29-git7 : offlining a cpu causes an exception
Benjamin Herrenschmidt wrote: On Tue, 2009-03-31 at 14:57 +0530, Sachin Sant wrote: While executing CPU HotPlug[1] tests i observed that during every cpu offline process an exception is thrown. Looks like a BUG_ON() to me... can you look at what other messages just before that ? I don't get any other messages when the problem occurs. Infact if i don't have xmon enabled the machine just hangs without any messages on the console. I extracted the dmesg log (attached in my previous mail) through xmon. Here are last few related messages from 2.6.29-git8 kernel during problem recreation. 4IRQ 18 affinity broken off cpu 2 4cpu 2 (hwid 2) Ready to die 7CPU0 attaching NULL sched-domain.. 7CPU1 attaching NULL sched-domain.. 7CPU2 attaching NULL sched-domain.. 7CPU3 attaching NULL sched-domain.. 7CPU0 attaching sched-domain:. 7 domain 0: span 0-1 level SIBLING. 7 groups: 0 1. 7 domain 1: span 0-1,3 level CPU. 7 groups: 0-1 3. 7 domain 2: span 0-1,3 level NODE 7groups: 0-1,3. 7CPU1 attaching sched-domain:. 7 domain 0: span 0-1 level SIBLING. 7 groups: 1 0. 7 domain 1: span 0-1,3 level CPU. 7 groups: 0-1 3. 7 domain 2: span 0-1,3 level NODE. 7groups: 0-1,3. 7CPU3 attaching sched-domain:. 7 domain 0: span 0-1,3 level CPU. 7 groups: 3 0-1. 7 domain 1: span 0-1,3 level NODE. 7 groups: 0-1,3... That or lookup where the PC and LR values are in System.map and maybe get us a backtrace from xmon ? (You seem to have no symbols, have you built with kallsyms ?) I have kallsyms and debug info options enabled. CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_DEBUG_INFO=y Here is the related information from 2.6.29-git8 kernel. llm62 login: cpu 0x2: Vector: 700 (Program Check) at [c74c7ca0] pc: 007b6640 lr: 0079ddc0 sp: c74c7f20 msr: 80081002 current = 0xc000fe1c8580 paca= 0xc0ab2800 pid = 0, comm = swapper enter ? for help [c74c7f20] 00018694 (unreliable) [c74c7f90] 8278 SP (4f0003) is in userspace 2:mon la %pc 007b6640 2:mon la c07b6640 c07b6640: .kmem_cache_init+0x2d8/0x528 2:mon la %lr 0079ddc0 2:mon la c079ddc0 c079ddc0: .mem_init+0x150/0x22c 2:mon Regards -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
Hi David,
this patch went out by mistake, sorry.
David Gibson wrote:
On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts2009-03-31
13:24:38.078719288 +0200
+++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:47:56.986720719 +0200
@@ -52,6 +52,7 @@
soc8...@e000 {
#address-cells = 1;
#size-cells = 1;
+device_type = soc;
You should not be adding device_type to a new board's dts. You
*especially* shouldn't be doing that with no patch comment explaining
why.
In the final patch I have removed the device_type = soc, but it makes
trouble as some mpc85xx rely on it. Removing it would also break U-Boot
compatibility. Is it worth that? The issue is discussed on the thread
http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070020.html.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
Anton Vorontsov wrote:
On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
[...]
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
Drop device_type here too.
Grrr, I just realized that removing the devices type soc has broken
fsl_get_sys_freq(). See:
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
We need a quick fix and we could take the occasion to establish a common
function for the MPC52xx as well, but it's not obvious to me how to find
the SOC node without the device type property.
SoC node should have a compatible property, just like everything else.
compatible = fsl,mpc8544-immr; (immr == Internally Memory Mapped
Registers)
Many other boards already do this.
Yes, it does, but searching for the SOC node is not straight-forward
because there is no common compatibility string but many CPU-specific
compatibility strings, e.g. fsl,mpc8560-immr, etc. Have I missed
something?
Choose a new value (fsl,mpc-immr perhaps?), document exactly what it
means, and add add it to the end of the compatible list.
As Scott Wood once pointed out, IMMR does not exists for MPC85xx
parts. There it's called CCSR.
See this thread:
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
I still think that
fsl,mpc83NN-immr, fsl,soc, simple-bus for 83xx
and
fsl,mpc85NN-ccsr, fsl,soc, simple-bus for 85xx
would be OK, at least to start with. We can always deprecate fsl,soc
compatible in favour of something more elegant, but fsl,soc should be
just fine to replace device_type = soc.
Also, there is another good thing about fsl,soc -- U-Boot already
finds it for 83xx CPUs. ;-)
Ugh! I just realize the full impact of removing device type soc. It
will break compatibility with U-Boot for many boards. Is it worth it?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: i2c-mpc: preserve I2C clocking
David Gibson wrote: On Tue, Mar 31, 2009 at 02:43:39PM +0200, Wolfgang Grandegger wrote: The I2c node property fsl,preserve-clocking allows to overtake the clock settings from the boot loader and avoids the hard-coded setting. Hrm. This is dubious. The device tree should generally describe hardware, not OS/driver behaviour which is what this appears to be doing. There are exceptions, but you need to justify them. I think the purpose of this property is clear. How would you provide that functionality instead? I suggested that a clock-frequency = 0 property should do the trick but Grant preferred to be more explicit. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable
Grant Likely wrote:
On Tue, Mar 31, 2009 at 6:37 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
This patch makes the I2C bus speed configurable by using the I2C node
property clock-frequency. If the property is not defined, the old
fixed clock settings will be used for backward comptibility.
The generic I2C clock properties, especially the CPU-specific source
clock pre-scaler are defined via the OF match table:
static const struct of_device_id mpc_i2c_of_match[] = {
{.compatible = fsl,mpc5200b-i2c,
.data = (void *)FSL_I2C_DEV_CLOCK_5200, },
{.compatible = fsl,mpc5200-i2c,
.data = (void *)FSL_I2C_DEV_CLOCK_5200, },
{.compatible = fsl,mpc8313-i2c,
.data = (void *)FSL_I2C_DEV_SEPARATE_DFSRR, },
{.compatible = fsl,mpc8543-i2c,
.data = (void *)(FSL_I2C_DEV_SEPARATE_DFSRR |
FSL_I2C_DEV_CLOCK_DIV2), },
{.compatible = fsl,mpc8544-i2c,
.data = (void *)(FSL_I2C_DEV_SEPARATE_DFSRR |
FSL_I2C_DEV_CLOCK_DIV23), },
/* Backward compatibility */
{.compatible = fsl-i2c, },
{},
};
Instead passing in a flag (and using an ugly cast to do it) which is
then checked inside the mpc_i2c_setclock(), you should do this
instead:
struct fsl_i2c_match_data {
int static void *(setclock)(struct device_node *node, struct
mpc_i2c *i2c, u32 clock);
int flags;
/* Other stuff can go here */
};
static const struct of_device_id mpc_i2c_of_match[] = {
{.compatible = fsl,mpc5200b-i2c,
.data = (struct fsl_i2c_match_data[]) { .setclock =
mpc_i2c_setclock_mpc5200, },
},
{.compatible = fsl,mpc5200-i2c,
.data = (struct fsl_i2c_match_data[]) { .setclock =
mpc_i2c_setclock_mpc5200, },
},
{.compatible = fsl,mpc8313-i2c,
.data = (struct fsl_i2c_match_data[]) { .setclock =
mpc_i2c_setclock_separate_dfsrr, },
},
{.compatible = fsl,mpc8543-i2c,
.data = (struct fsl_i2c_match_data[]) { .setclock =
mpc_i2c_setclock_separate_dfsrr, },
.flags = FSL_I2C_DEV_CLOCK_DIV2,
},
{.compatible = fsl,mpc8544-i2c,
.data = (struct fsl_i2c_match_data[]) { .setclock =
mpc_i2c_setclock_separate_dfsrr, },
.flags = FSL_I2C_DEV_CLOCK_DIV23,
},
/* Backward compatibility */
{.compatible = fsl-i2c,
.data = (struct fsl_i2c_match_data[]) { .setclock =
mpc_i2c_setclock, },
},
{},
};
The table definition is more verbose this way, but I think it results
in more understandable and easier to extend code. It also adds lets
the compiler do more type checking for you.
OK but I don't like the callback function to do the settings. We need
backward compatibility with old DTS files including the ugly dfsrr
property, right? Then it seems consequent to continue using i2c-flags
for that purpose and not to introduce another method. If we don't need
backward compatibility, we could drop the flags completely and just use
callback functions.
Also, this ...
--- linux-2.6.orig/arch/powerpc/sysdev/fsl_soc.c2009-03-31
13:25:08.0 +0200
+++ linux-2.6/arch/powerpc/sysdev/fsl_soc.c 2009-03-31
13:34:40.531721011 +0200
+int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32 i2c_flags)
+{
[...]
+}
+EXPORT_SYMBOL(fsl_i2c_get_fdr);
... and this ...
--- linux-2.6.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31
13:25:08.0 +0200
+++ linux-2.6/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31
13:28:54.309718526 +0200
+int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32 i2c_flags)
+{
[...]
+}
+EXPORT_SYMBOL(fsl_i2c_get_fdr);
does not work on a multiplatform kernel. Both 8xxx and 52xx support
can be selected at the same time.
OK, then we need different functions including stubs.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: PPC_CELL_NATIVE should select PCI
PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI, causing build failures if PCI is not set. Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com --- arch/powerpc/platforms/cell/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig index 40e24c3..33f534f 100644 --- a/arch/powerpc/platforms/cell/Kconfig +++ b/arch/powerpc/platforms/cell/Kconfig @@ -14,6 +14,7 @@ config PPC_CELL_NATIVE bool select PPC_CELL_COMMON select PPC_OF_PLATFORM_PCI + select PCI select MPIC select IBM_NEW_EMAC_EMAC4 select IBM_NEW_EMAC_RGMII -- 1.6.0.4 With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: USB does not work on mpc8347
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org]
On Behalf Of 山崎 精二
Sent: Wednesday, April 01, 2009 5:14 PM
To: linuxppc-dev@ozlabs.org
Subject: USB does not work on mpc8347
Hi all,
I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
I have some problem.
One is USB does not work on mpc8347.
platform_driver_probe(udc_driver, fsl_udc_probe) is failed.
struct is
static struct platform_driver udc_driver = {
.probe = fsl_udc_probe,
.remove = __exit_p(fsl_udc_remove),
/* these suspend and resume are not usb suspend and resume */
.suspend = fsl_udc_suspend,
.resume = fsl_udc_resume,
.driver = {
//.name = (char *)driver_name,
.name = fsl-usb2-mph,
Why are you changing this? Mph module can only be host, not the device mode
supported by this driver.
.owner = THIS_MODULE,
},
};
I do not know why it fails.
Do i have to do something ?
So what function did you try to test? Host or device? For host mode, you
should look into the drivers/usb/host/ehci-fsl.c file.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote: PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI, causing build failures if PCI is not set. Maybe it should only select it if PCI is enabled ? Is qpace using PCI ? Cheers, Ben. Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com --- arch/powerpc/platforms/cell/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig index 40e24c3..33f534f 100644 --- a/arch/powerpc/platforms/cell/Kconfig +++ b/arch/powerpc/platforms/cell/Kconfig @@ -14,6 +14,7 @@ config PPC_CELL_NATIVE bool select PPC_CELL_COMMON select PPC_OF_PLATFORM_PCI + select PCI select MPIC select IBM_NEW_EMAC_EMAC4 select IBM_NEW_EMAC_RGMII ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Patch next] powerpc: pseries/dtl.c should include asm/firmware.h
randconfig build on powerpc failed with : arch/powerpc/platforms/pseries/dtl.c: In function ‘dtl_init’: arch/powerpc/platforms/pseries/dtl.c:238: error: implicit declaration of function ‘firmware_has_feature’ arch/powerpc/platforms/pseries/dtl.c:238: error: ‘FW_FEATURE_SPLPAR’ undeclared (first use in this function) arch/powerpc/platforms/pseries/dtl.c:238: error: (Each undeclared identifier is reported only once arch/powerpc/platforms/pseries/dtl.c:238: error: for each function it appears in.) Signed-off-by : Sachin Sant sach...@in.ibm.com --- * Fixes the following build error * * arch/powerpc/platforms/pseries/dtl.c: In function âdtl_initâ: * arch/powerpc/platforms/pseries/dtl.c:238: * error: implicit declaration of function âfirmware_has_featureâ * arch/powerpc/platforms/pseries/dtl.c:238: * error: âFW_FEATURE_SPLPARâ undeclared (first use in this function) * arch/powerpc/platforms/pseries/dtl.c:238: *error: (Each undeclared identifier is reported only once * arch/powerpc/platforms/pseries/dtl.c:238: *error: for each function it appears in.) Signed-off-by : Sachin Sant sach...@in.ibm.com --- diff -Naurp a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c --- a/arch/powerpc/platforms/pseries/dtl.c 2009-04-01 15:46:59.0 +0530 +++ b/arch/powerpc/platforms/pseries/dtl.c 2009-04-01 15:47:58.0 +0530 @@ -25,6 +25,7 @@ #include asm/smp.h #include asm/system.h #include asm/uaccess.h +#include asm/firmware.h #include plpar_wrappers.h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB does not work on mpc8347
Hi all,
I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
I have some problem.
One is USB does not work on mpc8347.
platform_driver_probe(udc_driver, fsl_udc_probe) is failed.
struct is
static struct platform_driver udc_driver = {
.probe = fsl_udc_probe,
.remove = __exit_p(fsl_udc_remove),
/* these suspend and resume are not usb suspend and resume */
.suspend = fsl_udc_suspend,
.resume = fsl_udc_resume,
.driver = {
// .name = (char *)driver_name,
.name = fsl-usb2-mph,
.owner = THIS_MODULE,
},
};
I do not know why it fails.
Do i have to do something ?
-Seiji
--
yamazaki seiji yamazaki.se...@kk.jp.panasonic.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote: On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote: PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI, causing build failures if PCI is not set. Maybe it should only select it if PCI is enabled ? Is qpace using PCI ? No, QPACE does not have any PCI devices whatsoever. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
On Wed, 2009-04-01 at 12:45 +0200, Arnd Bergmann wrote: On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote: On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote: PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI, causing build failures if PCI is not set. Maybe it should only select it if PCI is enabled ? Is qpace using PCI ? No, QPACE does not have any PCI devices whatsoever. so something like select PPC_OF_PLATFORM_PCI if PCI would work you think ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with module_init?
On Tue, Mar 31, 2009 at 11:11:53PM -0400, Sean MacLennan wrote: 8d1cf34e7ad5c7738ce20d20bd7f002f562cb8b5 is first bad commit commit 8d1cf34e7ad5c7738ce20d20bd7f002f562cb8b5 Author: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Thu Mar 19 19:34:08 2009 + powerpc/mm: Tweak PTE bit combination definitions This patch tweaks the way some PTE bit combinations are defined, in such a way that the 32 and 64-bit variant become almost identical and that will make it easier to bring in a new common pte-* file for the new variant of the Book3-E support. The combination of bits defining access to kernel pages are now clearly separated from the combination used by userspace and the core VM. The resulting generated code should remain identical unless I made a mistake. Note: While at it, I removed a non-sensical statement related to CONFIG_KGDB in ppc_mmu_32.c which could cause kernel mappings to be user accessible when that option is enabled. Probably something that bitrot. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org :04 04 c105fb9641b078f1a8a60c2a7900ca2dd088b364 e90678246962d7a455aa27ba12814c11cd9b3c22 M arch I'm assuming this is the result of a git-bisect run? Can I also assume you were loading the module on your Warp board? Ben, have you tested module loads on 4xx since you redid this? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RFC ML510 Linux support
Hi,
This is a draft version of my patch to add Linux support for the Xilinx ML510.
The patch adds support for the board and a pci implementation which allows you
to use onboard pci devices (usb, ide, audio) and pci slots (only slot 3 and 5
for now).
This is an intial version of my work. There is some ide hack in which I need to
submit to the ide list and I guess that I need to make my pci driver OF aware.
Regards,
Roderick Colenbrander
--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
--- linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts 1970-01-01 01:00:00.0 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts 2009-04-01 13:18:50.0 +0200
@@ -0,0 +1,452 @@
+/*
+ * Xilinx ML510 Reference Design support
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains two bugs which prevent PCI from working which
+ * should be fixed by the user:
+ * - the MPLB output of the soft-core should be connected to plbv46_plb_1 which
+ * corresponds to SPLB0 of the ppc440 to allow the soft-core to access system
+ * memory
+ * - C_IPIFBAR2PCIBAR_0 of the soft-core should be set to 0x8000 in order to
+ * reserve 0x8000-0x (PCI) for memory mapped i/o and the lower addresses
+ * can be used by PCI devices to access system memory (DMA).
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = xlnx,ml510-ref-design;
+ dcr-parent = ppc440_0;
+ model = testing;
+ DDR2_SDRAM_DIMM0: mem...@0 {
+ device_type = memory;
+ reg = 0x0 0x2000 ;
+ } ;
+ chosen {
+ bootargs = console=ttyS0 root=/dev/xsa2 init=/etc/preinit;
+ linux,stdout-path = /p...@0/ser...@83e0;
+ } ;
+ cpus {
+ #address-cells = 1;
+ #cpus = 0x1;
+ #size-cells = 0;
+ ppc440_0: c...@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ clock-frequency = 3;
+ compatible = PowerPC,440, ibm,ppc440;
+ d-cache-line-size = 0x20;
+ d-cache-size = 0x8000;
+ dcr-access-method = native;
+ dcr-controller ;
+ device_type = cpu;
+ i-cache-line-size = 0x20;
+ i-cache-size = 0x8000;
+ model = PowerPC,440;
+ reg = 0;
+ timebase-frequency = 3;
+ xlnx,apu-control = 0x2000;
+ xlnx,apu-udi-0 = 0x0;
+ xlnx,apu-udi-1 = 0x0;
+ xlnx,apu-udi-10 = 0x0;
+ xlnx,apu-udi-11 = 0x0;
+ xlnx,apu-udi-12 = 0x0;
+ xlnx,apu-udi-13 = 0x0;
+ xlnx,apu-udi-14 = 0x0;
+ xlnx,apu-udi-15 = 0x0;
+ xlnx,apu-udi-2 = 0x0;
+ xlnx,apu-udi-3 = 0x0;
+ xlnx,apu-udi-4 = 0x0;
+ xlnx,apu-udi-5 = 0x0;
+ xlnx,apu-udi-6 = 0x0;
+ xlnx,apu-udi-7 = 0x0;
+ xlnx,apu-udi-8 = 0x0;
+ xlnx,apu-udi-9 = 0x0;
+ xlnx,dcr-autolock-enable = 0x1;
+ xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
+ xlnx,dcu-rd-noncache-plb-prio = 0x0;
+ xlnx,dcu-rd-touch-plb-prio = 0x0;
+ xlnx,dcu-rd-urgent-plb-prio = 0x0;
+ xlnx,dcu-wr-flush-plb-prio = 0x0;
+ xlnx,dcu-wr-store-plb-prio = 0x0;
+ xlnx,dcu-wr-urgent-plb-prio = 0x0;
+ xlnx,dma0-control = 0x0;
+ xlnx,dma0-plb-prio = 0x0;
+ xlnx,dma0-rxchannelctrl = 0x101;
+ xlnx,dma0-rxirqtimer = 0x3ff;
+ xlnx,dma0-txchannelctrl = 0x101;
+ xlnx,dma0-txirqtimer = 0x3ff;
+ xlnx,dma1-control = 0x0;
+ xlnx,dma1-plb-prio = 0x0;
+ xlnx,dma1-rxchannelctrl = 0x101;
+ xlnx,dma1-rxirqtimer = 0x3ff;
+ xlnx,dma1-txchannelctrl = 0x101;
+ xlnx,dma1-txirqtimer = 0x3ff;
+ xlnx,dma2-control = 0x0;
+ xlnx,dma2-plb-prio = 0x0;
+ xlnx,dma2-rxchannelctrl = 0x101;
+ xlnx,dma2-rxirqtimer = 0x3ff;
+ xlnx,dma2-txchannelctrl = 0x101;
+ xlnx,dma2-txirqtimer = 0x3ff;
+ xlnx,dma3-control = 0x0;
+ xlnx,dma3-plb-prio = 0x0;
+ xlnx,dma3-rxchannelctrl = 0x101;
+ xlnx,dma3-rxirqtimer = 0x3ff;
+ xlnx,dma3-txchannelctrl = 0x101;
+ xlnx,dma3-txirqtimer = 0x3ff;
+ xlnx,endian-reset = 0x0;
+ xlnx,generate-plb-timespecs = 0x1;
+ xlnx,icu-rd-fetch-plb-prio = 0x0;
+ xlnx,icu-rd-spec-plb-prio = 0x0;
+ xlnx,icu-rd-touch-plb-prio = 0x0;
+ xlnx,interconnect-imask = 0x;
+ xlnx,mplb-allow-lock-xfer = 0x1;
+ xlnx,mplb-arb-mode = 0x0;
+ xlnx,mplb-awidth = 0x20;
+ xlnx,mplb-counter = 0x500;
+ xlnx,mplb-dwidth = 0x80;
+ xlnx,mplb-max-burst = 0x8;
+ xlnx,mplb-native-dwidth = 0x80;
+ xlnx,mplb-p2p = 0x0;
+ xlnx,mplb-prio-dcur = 0x2;
+ xlnx,mplb-prio-dcuw = 0x3;
+ xlnx,mplb-prio-icu = 0x4;
+ xlnx,mplb-prio-splb0 = 0x1;
+ xlnx,mplb-prio-splb1 = 0x0;
+ xlnx,mplb-read-pipe-enable = 0x1;
+ xlnx,mplb-sync-tattribute = 0x0;
+ xlnx,mplb-wdog-enable = 0x1;
+ xlnx,mplb-write-pipe-enable = 0x1;
+ xlnx,mplb-write-post-enable = 0x1;
+ xlnx,num-dma = 0x0;
+ xlnx,pir = 0xf;
+
Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
Hi David,
this patch went out by mistake, sorry.
David Gibson wrote:
On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:24:38.078719288 +0200
+++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:47:56.986720719 +0200
@@ -52,6 +52,7 @@
soc8...@e000 {
#address-cells = 1;
#size-cells = 1;
+ device_type = soc;
You should not be adding device_type to a new board's dts. You
*especially* shouldn't be doing that with no patch comment explaining
why.
In the final patch I have removed the device_type = soc, but it makes
trouble as some mpc85xx rely on it.
Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
don't see how something that affects some mpc85xx is relevant.
--
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
/dev/random on PPC40EXr
Hi, On my custom board based on 405EXr /dev/random produces no output at all, and /dev/urandom is not random enough for our purposes. Saving entropy pool between reboots doesn't help much. What can be done to increase the entropy of the system ? I was thinking of adding IRQF_SAMPLE_RANDOM to network driver, but since not too many drivers implement it, I don't know whether it's a good idea or not. Is there any work in progress to develop hw_random driver for 4xx TRNG ? Thanks a lot. Felix. -- View this message in context: http://www.nabble.com/-dev-random-on-PPC40EXr-tp22824979p22824979.html 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: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote: On Wed, 2009-04-01 at 12:45 +0200, Arnd Bergmann wrote: No, QPACE does not have any PCI devices whatsoever. so something like select PPC_OF_PLATFORM_PCI if PCI would work you think ? Yes, that sounds good. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
David Gibson wrote:
On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
Hi David,
this patch went out by mistake, sorry.
David Gibson wrote:
On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:24:38.078719288 +0200
+++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:47:56.986720719 +0200
@@ -52,6 +52,7 @@
soc8...@e000 {
#address-cells = 1;
#size-cells = 1;
+ device_type = soc;
You should not be adding device_type to a new board's dts. You
*especially* shouldn't be doing that with no patch comment explaining
why.
In the final patch I have removed the device_type = soc, but it makes
trouble as some mpc85xx rely on it.
Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
don't see how something that affects some mpc85xx is relevant.
Well, to be more precise, it affects all boards using CONFIG_FSL_SOC
because they use functions searching for the device type soc, e.g.
fsl_get_sys_freq():
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
This needs to be fixed before the line 'device_type = soc' can be removed.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
On Wed, Apr 01, 2009 at 10:09:55PM +1100, David Gibson wrote:
On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
Hi David,
this patch went out by mistake, sorry.
David Gibson wrote:
On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts2009-03-31
13:24:38.078719288 +0200
+++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:47:56.986720719 +0200
@@ -52,6 +52,7 @@
soc8...@e000 {
#address-cells = 1;
#size-cells = 1;
+device_type = soc;
You should not be adding device_type to a new board's dts. You
*especially* shouldn't be doing that with no patch comment explaining
why.
In the final patch I have removed the device_type = soc, but it makes
trouble as some mpc85xx rely on it.
Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
don't see how something that affects some mpc85xx is relevant.
Not some, but *all* mpc85xx. The thing is that U-Boot is searching
for device_type = soc to fixup some properties (for example,
bus-frequency) for all mpc85xx parts, so you can't easily remove
the device_type w/o breaking boot for firmwares that customers have
pre-programmed in their products.
Note that upgrading firmware without JTAG is dangerous, so it's not
an option to force everybody to upgrade their firmware just
because we want to remove some cruft from the device tree.
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger w...@grandegger.com wrote:
Anton Vorontsov wrote:
On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
[...]
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
Drop device_type here too.
Grrr, I just realized that removing the devices type soc has broken
fsl_get_sys_freq(). See:
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
We need a quick fix and we could take the occasion to establish a common
function for the MPC52xx as well, but it's not obvious to me how to find
the SOC node without the device type property.
SoC node should have a compatible property, just like everything else.
compatible = fsl,mpc8544-immr; (immr == Internally Memory Mapped
Registers)
Many other boards already do this.
Yes, it does, but searching for the SOC node is not straight-forward
because there is no common compatibility string but many CPU-specific
compatibility strings, e.g. fsl,mpc8560-immr, etc. Have I missed
something?
Choose a new value (fsl,mpc-immr perhaps?), document exactly what it
means, and add add it to the end of the compatible list.
As Scott Wood once pointed out, IMMR does not exists for MPC85xx
parts. There it's called CCSR.
See this thread:
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
I still think that
fsl,mpc83NN-immr, fsl,soc, simple-bus for 83xx
and
fsl,mpc85NN-ccsr, fsl,soc, simple-bus for 85xx
would be OK, at least to start with. We can always deprecate fsl,soc
compatible in favour of something more elegant, but fsl,soc should be
just fine to replace device_type = soc.
Also, there is another good thing about fsl,soc -- U-Boot already
finds it for 83xx CPUs. ;-)
Ugh! I just realize the full impact of removing device type soc. It
will break compatibility with U-Boot for many boards. Is it worth it?
Yes, I know this. I'm not asking you to fix all the other boards, but
make sure that it is not required for the new board.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: tracing/powerpc tree build failure
* Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, This patch is now applicable to the tracing tree after merging with Linus' tree. Thanks, that's useful info. There's the skb tracepoints related merge fixlet needed too. Anything else in this context you are aware of? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: tracing/powerpc tree build failure
Hi Ingo, [Its midnight, so this is just a quick reply.] On Wed, 1 Apr 2009 14:51:48 +0200 Ingo Molnar mi...@elte.hu wrote: * Stephen Rothwell s...@canb.auug.org.au wrote: This patch is now applicable to the tracing tree after merging with Linus' tree. Thanks, that's useful info. There's the skb tracepoints related merge fixlet needed too. Anything else in this context you are aware of? They are the only two build fixes I have at the moment. On top of that these are the only conflicts I get when merging the tip trees: Merging tip-core/auto-core-next CONFLICT (content): Merge conflict in include/linux/netfilter/xt_limit.h CONFLICT (content): Merge conflict in include/linux/netfilter/xt_statistic.h CONFLICT (content): Merge conflict in lib/Kconfig.debug Merging cpus4096/auto-cpus4096-next CONFLICT (content): Merge conflict in arch/x86/include/asm/topology.h CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/common.c CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/intel_cacheinfo.c CONFLICT (content): Merge conflict in drivers/oprofile/buffer_sync.c Merging tracing/auto-tracing-next CONFLICT (add/add): Merge conflict in arch/parisc/include/asm/ftrace.h CONFLICT (content): Merge conflict in include/linux/slub_def.h CONFLICT (content): Merge conflict in kernel/extable.c CONFLICT (content): Merge conflict in mm/slob.c CONFLICT (content): Merge conflict in mm/slub.c I think these are mostly trivial (except the parisc one you commented on before). Some are caused by the same commit being in two trees and further work in one of them. Anything non-tivial will have been reported previously. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpgXZnFVyCbY.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
Grant Likely wrote:
On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
Anton Vorontsov wrote:
On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
[...]
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
Drop device_type here too.
Grrr, I just realized that removing the devices type soc has broken
fsl_get_sys_freq(). See:
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
We need a quick fix and we could take the occasion to establish a common
function for the MPC52xx as well, but it's not obvious to me how to find
the SOC node without the device type property.
SoC node should have a compatible property, just like everything else.
compatible = fsl,mpc8544-immr; (immr == Internally Memory Mapped
Registers)
Many other boards already do this.
Yes, it does, but searching for the SOC node is not straight-forward
because there is no common compatibility string but many CPU-specific
compatibility strings, e.g. fsl,mpc8560-immr, etc. Have I missed
something?
Choose a new value (fsl,mpc-immr perhaps?), document exactly what it
means, and add add it to the end of the compatible list.
As Scott Wood once pointed out, IMMR does not exists for MPC85xx
parts. There it's called CCSR.
See this thread:
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
I still think that
fsl,mpc83NN-immr, fsl,soc, simple-bus for 83xx
and
fsl,mpc85NN-ccsr, fsl,soc, simple-bus for 85xx
would be OK, at least to start with. We can always deprecate fsl,soc
compatible in favour of something more elegant, but fsl,soc should be
just fine to replace device_type = soc.
Also, there is another good thing about fsl,soc -- U-Boot already
finds it for 83xx CPUs. ;-)
Ugh! I just realize the full impact of removing device type soc. It
will break compatibility with U-Boot for many boards. Is it worth it?
Yes, I know this. I'm not asking you to fix all the other boards, but
make sure that it is not required for the new board.
Hm, I'm confused, if we want to fix this issue we need first to
- fix all functions in fsl_soc.c searching for the compatible string
fsl,soc instead of the device type soc (or both for backward
compatibility).
- fix U-Boot to find the SOC node by looking for fsl,soc to insert the
proper bus-frequency, at least.
That affects *all* boards using CONFIG_FSL_SOC and requires an
up-to-date version of U-Boot for new kernels :-(. If that is fixed, I
can remove the device_type = soc; from socrates.dts (and may more),
but not right now. Or have I missed something?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: i2c-mpc: make I2C bus speed configurable
This patch makes the I2C bus speed configurable by using the I2C node
property clock-frequency. If the property is not defined, the old
fixed clock settings will be used for backward compatibility.
The generic I2C clock properties, especially the CPU-specific source
clock pre-scaler are defined via the OF match table:
static const struct of_device_id mpc_i2c_of_match[] = {
...
{.compatible = fsl,mpc8543-i2c,
.data = (struct fsl_i2c_match_data) {
.setclock = mpc_i2c_setclock_8xxx,
.prescaler = 2,
},
},
The data field defines the relevant I2C setclock function and the
relevant prescaler for the I2C source clock frequency.
It uses arch-specific tables and functions to determine resonable
Freqency Divider Register (fdr) values for MPC83xx, MPC85xx, MPC86xx,
MPC5200 and MPC5200B.
The i2c-flags field and the corresponding FSL_I2C_DEV_* definitions
have been removed as they are obsolete.
Furthermore dev_dbg() and dev_info() are now used to profit from a more
comprehensive output.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
Documentation/powerpc/dts-bindings/fsl/i2c.txt | 43 +--
arch/powerpc/include/asm/mpc52xx.h | 11 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 57 ++
arch/powerpc/sysdev/fsl_soc.c | 90
arch/powerpc/sysdev/fsl_soc.h | 12 ++
drivers/i2c/busses/i2c-mpc.c | 138 ++---
include/linux/fsl_devices.h|9 -
7 files changed, 302 insertions(+), 58 deletions(-)
Index: linux-2.6/drivers/i2c/busses/i2c-mpc.c
===
--- linux-2.6.orig/drivers/i2c/busses/i2c-mpc.c 2009-03-31 21:29:21.0
+0200
+++ linux-2.6/drivers/i2c/busses/i2c-mpc.c 2009-04-01 14:56:43.824970544
+0200
@@ -20,12 +20,15 @@
#include linux/of_platform.h
#include linux/of_i2c.h
-#include asm/io.h
+#include linux/io.h
#include linux/fsl_devices.h
#include linux/i2c.h
#include linux/interrupt.h
#include linux/delay.h
+#include asm/mpc52xx.h
+#include sysdev/fsl_soc.h
+
#define DRV_NAME mpc-i2c
#define MPC_I2C_FDR0x04
@@ -50,12 +53,19 @@
#define CSR_RXAK 0x01
struct mpc_i2c {
+ struct device *dev;
void __iomem *base;
u32 interrupt;
wait_queue_head_t queue;
struct i2c_adapter adap;
int irq;
- u32 flags;
+};
+
+struct fsl_i2c_match_data {
+ void (*setclock)(struct device_node *node,
+struct mpc_i2c *i2c,
+u32 clock, u32 prescaler);
+ u32 prescaler;
};
static __inline__ void writeccr(struct mpc_i2c *i2c, u32 x)
@@ -105,7 +115,7 @@
while (!(readb(i2c-base + MPC_I2C_SR) CSR_MIF)) {
schedule();
if (time_after(jiffies, orig_jiffies + timeout)) {
- pr_debug(I2C: timeout\n);
+ dev_dbg(i2c-dev, timeout\n);
writeccr(i2c, 0);
result = -EIO;
break;
@@ -119,10 +129,10 @@
(i2c-interrupt CSR_MIF), timeout * HZ);
if (unlikely(result 0)) {
- pr_debug(I2C: wait interrupted\n);
+ dev_dbg(i2c-dev, wait interrupted\n);
writeccr(i2c, 0);
} else if (unlikely(!(i2c-interrupt CSR_MIF))) {
- pr_debug(I2C: wait timeout\n);
+ dev_dbg(i2c-dev, wait timeout\n);
writeccr(i2c, 0);
result = -ETIMEDOUT;
}
@@ -135,17 +145,17 @@
return result;
if (!(x CSR_MCF)) {
- pr_debug(I2C: unfinished\n);
+ dev_dbg(i2c-dev, unfinished\n);
return -EIO;
}
if (x CSR_MAL) {
- pr_debug(I2C: MAL\n);
+ dev_dbg(i2c-dev, MAL\n);
return -EIO;
}
if (writing (x CSR_RXAK)) {
- pr_debug(I2C: No RXAK\n);
+ dev_dbg(i2c-dev, No RXAK\n);
/* generate stop */
writeccr(i2c, CCR_MEN);
return -EIO;
@@ -153,16 +163,30 @@
return 0;
}
-static void mpc_i2c_setclock(struct mpc_i2c *i2c)
-{
- /* Set clock and filters */
- if (i2c-flags FSL_I2C_DEV_SEPARATE_DFSRR) {
- writeb(0x31, i2c-base + MPC_I2C_FDR);
- writeb(0x10, i2c-base + MPC_I2C_DFSRR);
- } else if (i2c-flags FSL_I2C_DEV_CLOCK_5200)
- writeb(0x3f, i2c-base + MPC_I2C_FDR);
- else
- writel(0x1031, i2c-base + MPC_I2C_FDR);
+static void mpc_i2c_setclock_52xx(struct device_node *node,
+ struct
Re: Broken CONFIG_HIGHPTE
On Apr 1, 2009, at 12:38 AM, Benjamin Herrenschmidt wrote: Hi ! Just noticed... And I'll be travelling for a while so with no much time to look at it. Your changes to use the PTE page free batch via RCU on ppc32 broke CONFIG_HIGHPTE for hash32... You rely on passing a page_address() of the PTE page down to the freeing layer. That doesn't work for highmem pages. That needs to be changes to a struct page * on 32-bit (not on 64-bit where we are using slabs though) I can look into this, how does this show up? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Apr 1, 2009, at 8:10 AM, Wolfgang Grandegger wrote:
Grant Likely wrote:
On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
Anton Vorontsov wrote:
On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
[...]
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
Drop device_type here too.
Grrr, I just realized that removing the devices type soc
has broken
fsl_get_sys_freq(). See:
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
We need a quick fix and we could take the occasion to
establish a common
function for the MPC52xx as well, but it's not obvious to me
how to find
the SOC node without the device type property.
SoC node should have a compatible property, just like
everything else.
compatible = fsl,mpc8544-immr; (immr == Internally Memory
Mapped Registers)
Many other boards already do this.
Yes, it does, but searching for the SOC node is not straight-
forward
because there is no common compatibility string but many CPU-
specific
compatibility strings, e.g. fsl,mpc8560-immr, etc. Have I
missed
something?
Choose a new value (fsl,mpc-immr perhaps?), document exactly
what it
means, and add add it to the end of the compatible list.
As Scott Wood once pointed out, IMMR does not exists for MPC85xx
parts. There it's called CCSR.
See this thread:
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
I still think that
fsl,mpc83NN-immr, fsl,soc, simple-bus for 83xx
and
fsl,mpc85NN-ccsr, fsl,soc, simple-bus for 85xx
would be OK, at least to start with. We can always deprecate
fsl,soc
compatible in favour of something more elegant, but fsl,soc
should be
just fine to replace device_type = soc.
Also, there is another good thing about fsl,soc -- U-Boot already
finds it for 83xx CPUs. ;-)
Ugh! I just realize the full impact of removing device type soc.
It
will break compatibility with U-Boot for many boards. Is it worth
it?
Yes, I know this. I'm not asking you to fix all the other boards,
but
make sure that it is not required for the new board.
Hm, I'm confused, if we want to fix this issue we need first to
- fix all functions in fsl_soc.c searching for the compatible string
fsl,soc instead of the device type soc (or both for backward
compatibility).
- fix U-Boot to find the SOC node by looking for fsl,soc to insert
the
proper bus-frequency, at least.
That affects *all* boards using CONFIG_FSL_SOC and requires an
up-to-date version of U-Boot for new kernels :-(. If that is fixed, I
can remove the device_type = soc; from socrates.dts (and may
more),
but not right now. Or have I missed something?
I presume the intent is not to break old u-boots w/new kernels, but to
make it so new .dts don't require device_type = soc in them if using
new kernels.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable
On Wed, Apr 1, 2009 at 1:51 AM, Wolfgang Grandegger w...@grandegger.com wrote:
Grant Likely wrote:
The table definition is more verbose this way, but I think it results
in more understandable and easier to extend code. It also adds lets
the compiler do more type checking for you.
OK but I don't like the callback function to do the settings. We need
backward compatibility with old DTS files including the ugly dfsrr
property, right? Then it seems consequent to continue using i2c-flags
for that purpose and not to introduce another method. If we don't need
backward compatibility, we could drop the flags completely and just use
callback functions.
I don't understand why you don't like it. It's an elegant solution
and it simplifies the code somewhat. After grabbing the callback
pointer the compatibility code can simply override it. But I won't
belabor the point or oppose the patch if you stick with the flags
pointer.
--- linux-2.6.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31
13:25:08.0 +0200
+++ linux-2.6/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31
13:28:54.309718526 +0200
+int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32 i2c_flags)
+{
[...]
+}
+EXPORT_SYMBOL(fsl_i2c_get_fdr);
does not work on a multiplatform kernel. Both 8xxx and 52xx support
can be selected at the same time.
OK, then we need different functions including stubs.
I've been thinking about this more. These tables are only ever going
to be used by the i2c_mpc driver and so really they are a part of the
i2c_mpc driver itself. Putting them into common code doesn't make any
sense because it is not common code. I will not merge a patch that
puts them into mpc5200 common code.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8641D with linux 2.6.29 did'n show second cpu
Hi, Am Mittwoch 01 April 2009 06:10:36 schrieb Kumar Gala: On Mar 31, 2009, at 10:06 AM, Eduard Fuchs wrote: Hi, Am Dienstag 31 März 2009 15:20:21 schrieb Kumar Gala: On Mar 31, 2009, at 5:15 AM, Eduard Fuchs wrote: Hi, I'm testing the evaluation board from freescale (MPC8641DHPCN) with the latest linux kernel (2.6.29) and the second core seems disabled. CONFIG_SPM is enabled but the /proc/cpuinfo shows only one cpu. With original 2.6.27 kernel both cpu cores appears in /proc/cpuinfo. Has anyone an idea how can i enable the second core? Are you using u-boot? I can't remember if you need a newer u-boot to deal with changes in how we bring up the second core. Yes. My u-boot version is 2009.03. Are there some additional config keys for SMP support in u-boot? It appears we introduced a bug in v2009.03 of u-boot. I never thought that the problem could be in u-boot. I tested the board with u-boot v2009.01 and it works well. Best regard Eduard Fuchs ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable
Grant Likely wrote:
On Wed, Apr 1, 2009 at 1:51 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
Grant Likely wrote:
The table definition is more verbose this way, but I think it results
in more understandable and easier to extend code. It also adds lets
the compiler do more type checking for you.
OK but I don't like the callback function to do the settings. We need
backward compatibility with old DTS files including the ugly dfsrr
property, right? Then it seems consequent to continue using i2c-flags
for that purpose and not to introduce another method. If we don't need
backward compatibility, we could drop the flags completely and just use
callback functions.
I don't understand why you don't like it. It's an elegant solution
and it simplifies the code somewhat. After grabbing the callback
pointer the compatibility code can simply override it. But I won't
belabor the point or oppose the patch if you stick with the flags
pointer.
I changed my mind ;-). Have a look to PATCH v2 I sent out a few minutes ago.
--- linux-2.6.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31
13:25:08.0 +0200
+++ linux-2.6/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31
13:28:54.309718526 +0200
+int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32
i2c_flags)
+{
[...]
+}
+EXPORT_SYMBOL(fsl_i2c_get_fdr);
does not work on a multiplatform kernel. Both 8xxx and 52xx support
can be selected at the same time.
OK, then we need different functions including stubs.
I've been thinking about this more. These tables are only ever going
to be used by the i2c_mpc driver and so really they are a part of the
i2c_mpc driver itself. Putting them into common code doesn't make any
sense because it is not common code. I will not merge a patch that
puts them into mpc5200 common code.
It's not common code, I agree. How about putting it into mpc52xx_i2c.c
and use:
$ cat Makefile
obj-$(CONFIG_I2C_MPC) += mpc52xx_i2c.o
Or it could be moved back to the i2c_mpc driver and we add stubs for the
functions to get the bus frequency, or use #ifdef's.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: i2c-mpc: make I2C bus speed configurable
On Wed, Apr 1, 2009 at 7:13 AM, Wolfgang Grandegger w...@grandegger.com wrote:
This patch makes the I2C bus speed configurable by using the I2C node
property clock-frequency. If the property is not defined, the old
fixed clock settings will be used for backward compatibility.
The generic I2C clock properties, especially the CPU-specific source
clock pre-scaler are defined via the OF match table:
static const struct of_device_id mpc_i2c_of_match[] = {
...
{.compatible = fsl,mpc8543-i2c,
.data = (struct fsl_i2c_match_data) {
.setclock = mpc_i2c_setclock_8xxx,
.prescaler = 2,
},
},
The data field defines the relevant I2C setclock function and the
relevant prescaler for the I2C source clock frequency.
It uses arch-specific tables and functions to determine resonable
Freqency Divider Register (fdr) values for MPC83xx, MPC85xx, MPC86xx,
MPC5200 and MPC5200B.
The i2c-flags field and the corresponding FSL_I2C_DEV_* definitions
have been removed as they are obsolete.
Furthermore dev_dbg() and dev_info() are now used to profit from a more
comprehensive output.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
arch/powerpc/include/asm/mpc52xx.h | 11 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 57 ++
arch/powerpc/sysdev/fsl_soc.c | 90
arch/powerpc/sysdev/fsl_soc.h | 12 ++
^
I mostly like this patch. However, as I mentioned in my other reply,
I'm going to NAK it because the divisor tables are not common code and
do not belong in common code files.
Other than that, I like this version of the patch and I think it is
almost finished. More comments below.
-static void mpc_i2c_setclock(struct mpc_i2c *i2c)
-{
- /* Set clock and filters */
- if (i2c-flags FSL_I2C_DEV_SEPARATE_DFSRR) {
- writeb(0x31, i2c-base + MPC_I2C_FDR);
- writeb(0x10, i2c-base + MPC_I2C_DFSRR);
- } else if (i2c-flags FSL_I2C_DEV_CLOCK_5200)
- writeb(0x3f, i2c-base + MPC_I2C_FDR);
- else
- writel(0x1031, i2c-base + MPC_I2C_FDR);
+static void mpc_i2c_setclock_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ int fdr = mpc52xx_i2c_get_fdr(node, clock, prescaler);
+
+ if (fdr 0)
+ fdr = 0x3f; /* backward compatibility */
+ writeb(fdr 0xff, i2c-base + MPC_I2C_FDR);
+ dev_info(i2c-dev, clock %d Hz (fdr=%d)\n, clock, fdr);
+}
+
+static void mpc_i2c_setclock_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ int fdr = fsl_i2c_get_fdr(node, clock, prescaler);
+
+ if (fdr 0)
+ fdr = 0x1031; /* backward compatibility */
+ writeb(fdr 0xff, i2c-base + MPC_I2C_FDR);
+ writeb((fdr 8) 0xff, i2c-base + MPC_I2C_DFSRR);
+ dev_info(i2c-dev, clock %d Hz (dfsrr=%d fdr=%d)\n,
+ clock, fdr 8, fdr 0xff);
}
Very neat and tidy indeed. I like this.
Index: linux-2.6/arch/powerpc/sysdev/fsl_soc.c
===
--- linux-2.6.orig/arch/powerpc/sysdev/fsl_soc.c 2009-03-31
21:27:52.0 +0200
+++ linux-2.6/arch/powerpc/sysdev/fsl_soc.c 2009-04-01 12:09:18.796719327
+0200
@@ -39,7 +39,7 @@
#include sysdev/fsl_soc.h
#include mm/mmu_decl.h
#include asm/cpm2.h
-
+#define DEBUG
^^^ oops?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: i2c-mpc: make I2C bus speed configurable
On Wed, Apr 1, 2009 at 7:44 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Wed, Apr 1, 2009 at 7:13 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
This patch makes the I2C bus speed configurable by using the I2C node
property clock-frequency. If the property is not defined, the old
fixed clock settings will be used for backward compatibility.
I mostly like this patch. However, as I mentioned in my other reply,
I'm going to NAK it because the divisor tables are not common code and
do not belong in common code files.
Other than that, I like this version of the patch and I think it is
almost finished. More comments below.
Oh, and you should look in MAINTAINERS and cc this patch to Ben Dooks
and the linux-...@vger.kernel.org mailing list.
g.
-static void mpc_i2c_setclock(struct mpc_i2c *i2c)
-{
- /* Set clock and filters */
- if (i2c-flags FSL_I2C_DEV_SEPARATE_DFSRR) {
- writeb(0x31, i2c-base + MPC_I2C_FDR);
- writeb(0x10, i2c-base + MPC_I2C_DFSRR);
- } else if (i2c-flags FSL_I2C_DEV_CLOCK_5200)
- writeb(0x3f, i2c-base + MPC_I2C_FDR);
- else
- writel(0x1031, i2c-base + MPC_I2C_FDR);
+static void mpc_i2c_setclock_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ int fdr = mpc52xx_i2c_get_fdr(node, clock, prescaler);
+
+ if (fdr 0)
+ fdr = 0x3f; /* backward compatibility */
+ writeb(fdr 0xff, i2c-base + MPC_I2C_FDR);
+ dev_info(i2c-dev, clock %d Hz (fdr=%d)\n, clock, fdr);
+}
+
+static void mpc_i2c_setclock_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ int fdr = fsl_i2c_get_fdr(node, clock, prescaler);
+
+ if (fdr 0)
+ fdr = 0x1031; /* backward compatibility */
+ writeb(fdr 0xff, i2c-base + MPC_I2C_FDR);
+ writeb((fdr 8) 0xff, i2c-base + MPC_I2C_DFSRR);
+ dev_info(i2c-dev, clock %d Hz (dfsrr=%d fdr=%d)\n,
+ clock, fdr 8, fdr 0xff);
}
Very neat and tidy indeed. I like this.
Index: linux-2.6/arch/powerpc/sysdev/fsl_soc.c
===
--- linux-2.6.orig/arch/powerpc/sysdev/fsl_soc.c 2009-03-31
21:27:52.0 +0200
+++ linux-2.6/arch/powerpc/sysdev/fsl_soc.c 2009-04-01
12:09:18.796719327 +0200
@@ -39,7 +39,7 @@
#include sysdev/fsl_soc.h
#include mm/mmu_decl.h
#include asm/cpm2.h
-
+#define DEBUG
^^^ oops?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8641D with linux 2.6.29 did'n show second cpu
On Apr 1, 2009, at 8:36 AM, Eduard Fuchs wrote: Hi, Am Mittwoch 01 April 2009 06:10:36 schrieb Kumar Gala: On Mar 31, 2009, at 10:06 AM, Eduard Fuchs wrote: Hi, Am Dienstag 31 März 2009 15:20:21 schrieb Kumar Gala: On Mar 31, 2009, at 5:15 AM, Eduard Fuchs wrote: Hi, I'm testing the evaluation board from freescale (MPC8641DHPCN) with the latest linux kernel (2.6.29) and the second core seems disabled. CONFIG_SPM is enabled but the /proc/cpuinfo shows only one cpu. With original 2.6.27 kernel both cpu cores appears in /proc/cpuinfo. Has anyone an idea how can i enable the second core? Are you using u-boot? I can't remember if you need a newer u- boot to deal with changes in how we bring up the second core. Yes. My u-boot version is 2009.03. Are there some additional config keys for SMP support in u-boot? It appears we introduced a bug in v2009.03 of u-boot. I never thought that the problem could be in u-boot. I tested the board with u-boot v2009.01 and it works well. the u-boot bug is that we are over-writting the page of code we need to bring up the second core. Thus when the kernel releases the 2nd core it goes off in the weeds. I've sent some patches to the u-boot list that should fix the problem by making sure that u-boot avoids using the page of memory we need for the 2nd core. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable
Wolfgang Grandegger wrote:
Grant Likely wrote:
On Wed, Apr 1, 2009 at 1:51 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
Grant Likely wrote:
The table definition is more verbose this way, but I think it results
in more understandable and easier to extend code. It also adds lets
the compiler do more type checking for you.
OK but I don't like the callback function to do the settings. We need
backward compatibility with old DTS files including the ugly dfsrr
property, right? Then it seems consequent to continue using i2c-flags
for that purpose and not to introduce another method. If we don't need
backward compatibility, we could drop the flags completely and just use
callback functions.
I don't understand why you don't like it. It's an elegant solution
and it simplifies the code somewhat. After grabbing the callback
pointer the compatibility code can simply override it. But I won't
belabor the point or oppose the patch if you stick with the flags
pointer.
I changed my mind ;-). Have a look to PATCH v2 I sent out a few minutes ago.
--- linux-2.6.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c
2009-03-31 13:25:08.0 +0200
+++ linux-2.6/arch/powerpc/platforms/52xx/mpc52xx_common.c
2009-03-31 13:28:54.309718526 +0200
+int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32
i2c_flags)
+{
[...]
+}
+EXPORT_SYMBOL(fsl_i2c_get_fdr);
does not work on a multiplatform kernel. Both 8xxx and 52xx support
can be selected at the same time.
OK, then we need different functions including stubs.
I've been thinking about this more. These tables are only ever going
to be used by the i2c_mpc driver and so really they are a part of the
i2c_mpc driver itself. Putting them into common code doesn't make any
sense because it is not common code. I will not merge a patch that
puts them into mpc5200 common code.
It's not common code, I agree. How about putting it into mpc52xx_i2c.c
and use:
$ cat Makefile
obj-$(CONFIG_I2C_MPC) += mpc52xx_i2c.o
That not a good idea either. I just checked the I2C interface of the
MPC512x and it can use the same table then the MPC5200B.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable
On Wed, Apr 1, 2009 at 7:41 AM, Wolfgang Grandegger w...@grandegger.com wrote: Grant Likely wrote: On Wed, Apr 1, 2009 at 1:51 AM, Wolfgang Grandegger w...@grandegger.com wrote: Grant Likely wrote: The table definition is more verbose this way, but I think it results in more understandable and easier to extend code. It also adds lets the compiler do more type checking for you. OK but I don't like the callback function to do the settings. We need backward compatibility with old DTS files including the ugly dfsrr property, right? Then it seems consequent to continue using i2c-flags for that purpose and not to introduce another method. If we don't need backward compatibility, we could drop the flags completely and just use callback functions. I don't understand why you don't like it. It's an elegant solution and it simplifies the code somewhat. After grabbing the callback pointer the compatibility code can simply override it. But I won't belabor the point or oppose the patch if you stick with the flags pointer. I changed my mind ;-). Have a look to PATCH v2 I sent out a few minutes ago. I saw and I like. :-) I've been thinking about this more. These tables are only ever going to be used by the i2c_mpc driver and so really they are a part of the i2c_mpc driver itself. Putting them into common code doesn't make any sense because it is not common code. I will not merge a patch that puts them into mpc5200 common code. It's not common code, I agree. How about putting it into mpc52xx_i2c.c and use: $ cat Makefile obj-$(CONFIG_I2C_MPC) += mpc52xx_i2c.o Or it could be moved back to the i2c_mpc driver and we add stubs for the functions to get the bus frequency, or use #ifdef's. I'm happy with either as long as it lives in the same directory as the i2c_mpc driver, and as long as the i2c maintainers are okay with it. Oh, and if you use a separate file it should be statically linked into the i2c_mpc module using the i2c_mpc-$(CONFIG_WHATEVER) trick. No EXPORT_SYMBOLS should be needed. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with module_init?
On Wed, 1 Apr 2009 07:27:56 -0400 Josh Boyer jwbo...@linux.vnet.ibm.com wrote: I'm assuming this is the result of a git-bisect run? Correct. Can I also assume you were loading the module on your Warp board? Correct again. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: issue at the beginning of kernel booting
thanks Scott! That is very old code; you're more likely to get help when running something up-to-date. i have a latest u-boot-2009.03 updated instead of mine, and kernel version is instead of 2.6.24.5 This alternative was listed as text/plain. nbsp is not plaintext. Please fix your mailer (and better yet, don't send HTML at all). yeah, it is my fault. i am a newer of mail lists , i will be careful next time. I doubt that it is actually halting here; more likely, you're just hitting a spot in the boot sequence where it's not safe to access your LEDs or other I/O, because you have the MMU off and the cache enabled. You'll typically be much better off leaving the very early code alone (it's almost never the culprit), except to ensure that you have a BAT mapping (cache-inhibited and guarded) for the I/O you want to use for debugging. Then, only touch that I/O device *after* the MMU is on and your mapping is in place. according to your point, i have moved the codes used for debuging to the place where after mmu being on, then there is nothing happened. it indicated that proforming had halt before this. i dont think there may be likely had some wrong in kernel source. but actually it halt there in early code. first i guess the reason that before i boot kernel without fdt. it still halt after wiht fdt. now i show my early code with debug code, please check it what fault is more likely. early code /* initialize LEDs, used by Port B */ lis r8, (0x00FF)@h ori r8, r8, (0x00FF)@l lis r9, (M8247_IOP_PDIRB(0xF000))@h //define 0x10D20 as M8247_IOP_PDIRB(Port B dir) lis r9, r9, (M8247_IOP_PDIRB(0xF000))@l //define 0x10D30 as M8247_IOP_PDATB(Port B dat) stw r8, 0(r9) /* turn D1 , successful */ lis r8, (0xFFFE)@h ori r8, r8, (0xFFFE)@l lis r9, (M8247_IOP_PDATB(0xF000))@h lis r9, r9, (M8247_IOP_PDATB(0xF000))@l stw r8, 0(r9) bl early_init /* here : mmu off: */ addir4, r3, __after_mmu_off - _start mfmsr r3 andi. r0,r3,MSR_DR|MSR_IR /* MMU enabled? */ beqlr andcr3,r3,r0 mtspr SPRN_SRR0,r4 mtspr SPRN_SRR1,r3 sync RFI __after_mmu_off: /* here : clear_bats: */ li r10,0 mfspr r9,SPRN_PVR rlwinm r9,r9,16,16,31 /* r9 = 1 for 601, 4 for 604 */ cmpwi r9, 1 beq 1f // my core is 603e, so both DBATx and IBATx should be initialized. mtspr SPRN_DBAT0U,r10 . . . mtspr SPRN_DBAT3L,r10 1: mtspr SPRN_IBAT0U,r10 . . . mtspr SPRN_IBAT3L,r10 BEGIN_FTR_SECTION // CPU_FTR_HAS_HIGH_BATS is default feature for G2_LE core mtspr SPRN_DBAT4U,r10 . . . mtspr SPRN_IBAT7L,r10 END_FTR_SECTION_IFSET(CPU_FTR_HAS_HIGH_BATS) blr /* here: flush_tlbs: */ lis r10, 0x40 1: addic. r10, r10, -0x1000 tlbie r10 blt 1b sync blr /* here : initial_bats: */ lis r11,kernelb...@h mfspr r9,SPRN_PVR rlwinm r9,r9,16,16,31 /* r9 = 1 for 601, 4 for 604 */ cmpwi 0,r9,1 bne 4f 4: tophys(r8,r11) ori r8,r8,2 /* R/W access */ ori r11,r11,BL_16M2|0x2 /* set up BAT registers for 604 */ mtspr SPRN_DBAT0L,r8 /* N.B. 6xx (not 601) have valid */ mtspr SPRN_DBAT0U,r11 /* bit in upper BAT register */ mtspr SPRN_IBAT0L,r8 mtspr SPRN_IBAT0U,r11 isync blr bl reloc_offset li r24,0 /* cpu# */ bl call_setup_cpu /* Call setup_cpu for this CPU */ here jump to call_setup_cpu, actually invoked setup_common_caches. setup_common_caches: /* turn D1 and D2 , successful */ lis r15, (0xFFFC)@h ori r15, r15, (0xFFFC)@l lis r16, (M8247_IOP_PDATB(0xF000))@h lis r16, r16, (M8247_IOP_PDATB(0xF000))@l stw r15, 0(r16) mfspr r11,SPRN_HID0 andi. r0,r11,HID0_DCE ori r11,r11,HID0_ICE|HID0_DCE ori r8,r11,HID0_ICFI bne 1f /* don't invalidate the D-cache */ ori r8,r8,HID0_DCI /* unless it wasn't enabled */ 1: sync mtspr SPRN_HID0,r8/* enable and invalidate caches */ /* turn D1,D2 and D3 , fault */ lis r15, (0xFFF8)@h ori r15, r15, (0xFFF8)@l lis r16,
Re: [PATCH v2] powerpc: i2c-mpc: make I2C bus speed configurable
Grant Likely wrote:
On Wed, Apr 1, 2009 at 7:44 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Wed, Apr 1, 2009 at 7:13 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
This patch makes the I2C bus speed configurable by using the I2C node
property clock-frequency. If the property is not defined, the old
fixed clock settings will be used for backward compatibility.
I mostly like this patch. However, as I mentioned in my other reply,
I'm going to NAK it because the divisor tables are not common code and
do not belong in common code files.
Other than that, I like this version of the patch and I think it is
almost finished. More comments below.
Looks good now, indeed.
Oh, and you should look in MAINTAINERS and cc this patch to Ben Dooks
and the linux-...@vger.kernel.org mailing list.
Right, and I need to separate I2C and PowerPC related patches. And it
will require another round but some acked-by lines will help.
-static void mpc_i2c_setclock(struct mpc_i2c *i2c)
-{
- /* Set clock and filters */
- if (i2c-flags FSL_I2C_DEV_SEPARATE_DFSRR) {
- writeb(0x31, i2c-base + MPC_I2C_FDR);
- writeb(0x10, i2c-base + MPC_I2C_DFSRR);
- } else if (i2c-flags FSL_I2C_DEV_CLOCK_5200)
- writeb(0x3f, i2c-base + MPC_I2C_FDR);
- else
- writel(0x1031, i2c-base + MPC_I2C_FDR);
+static void mpc_i2c_setclock_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ int fdr = mpc52xx_i2c_get_fdr(node, clock, prescaler);
+
+ if (fdr 0)
+ fdr = 0x3f; /* backward compatibility */
+ writeb(fdr 0xff, i2c-base + MPC_I2C_FDR);
+ dev_info(i2c-dev, clock %d Hz (fdr=%d)\n, clock, fdr);
+}
+
+static void mpc_i2c_setclock_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ int fdr = fsl_i2c_get_fdr(node, clock, prescaler);
+
+ if (fdr 0)
+ fdr = 0x1031; /* backward compatibility */
+ writeb(fdr 0xff, i2c-base + MPC_I2C_FDR);
+ writeb((fdr 8) 0xff, i2c-base + MPC_I2C_DFSRR);
+ dev_info(i2c-dev, clock %d Hz (dfsrr=%d fdr=%d)\n,
+clock, fdr 8, fdr 0xff);
}
Very neat and tidy indeed. I like this.
Yep.
Index: linux-2.6/arch/powerpc/sysdev/fsl_soc.c
===
--- linux-2.6.orig/arch/powerpc/sysdev/fsl_soc.c2009-03-31
21:27:52.0 +0200
+++ linux-2.6/arch/powerpc/sysdev/fsl_soc.c 2009-04-01
12:09:18.796719327 +0200
@@ -39,7 +39,7 @@
#include sysdev/fsl_soc.h
#include mm/mmu_decl.h
#include asm/cpm2.h
-
+#define DEBUG
^^^ oops?
Will fix.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: /dev/random on PPC40EXr
There is PKA/TRNG driver for sure. Let me check if it was accepted in opensource yet. Otherwise I will forward you the driver which may not be there in opensource yet. -Original Message- From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of Felix Radensky Sent: Wednesday, April 01, 2009 5:00 AM To: linuxppc-dev@ozlabs.org Subject: /dev/random on PPC40EXr Hi, On my custom board based on 405EXr /dev/random produces no output at all, and /dev/urandom is not random enough for our purposes. Saving entropy pool between reboots doesn't help much. What can be done to increase the entropy of the system ? I was thinking of adding IRQF_SAMPLE_RANDOM to network driver, but since not too many drivers implement it, I don't know whether it's a good idea or not. Is there any work in progress to develop hw_random driver for 4xx TRNG ? Thanks a lot. Felix. -- View this message in context: http://www.nabble.com/-dev-random-on-PPC40EXr-tp22824979p22824979.html 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB drivers
I have a custom board based on the MPC8313ERDB and have communications capabilities over Ethernet using internet sockets. Basically, just data transfer from the host (my board) to a client (a PC). I want to be able to perform similar transactions across USB. I have done some cursory reading but am a little unclear on how I should approach this. Am I going to have to write a host driver for my custom board, and also write a gadget driver for any client machine? Also, since I am desiring to do simple data transfers only, which drivers could I use as a point of reference for my application? Thanks in advance for any tips and suggestions. Ron ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: /dev/random on PPC40EXr
On Wed, Apr 01, 2009 at 10:05:00AM -0700, Tirumala Reddy Marri wrote: There is PKA/TRNG driver for sure. Let me check if it was accepted in opensource yet. Otherwise I will forward you the driver which may not be there in opensource yet. You could just send it to the list instead. That way everyone would have it... josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Support for kernels with large (10MB+) initramfs images
I'm trying to embed the open source XORP routing stack in 85xx based embedded system. XORP's original design didn't consider the possibility of an embedded deployment, so just getting it all to fit within the 32MB flash of our target has been a challenge all by itself. The BSP/SDK from the ODM that used a separate kernel and initrd, with a 2MB region reserved for the kernel and a 16MB region reserved for the initrd. However, I'm investigating whether it would be possible to use a kernel with everything in a initramfs. This currently gives us a 12MB image, and I'd be able to have two complete firmware images on the system (the remaining space would be used for a small jffs2 filesystem and u-boot itself). Unfortunately, I haven't been able to get this large kernel booting. The first problem I ran into was that the zImage wrapper was linked with a load address of 4MB, so the image couldn't be relocated without overwriting itself. Changing zImage.lds.S to use a 32MB load address fixed this problem. I had hoped that that would be enough, but the kernel still does not start. I have not yet attempted to trace kernel bring up (with a BDI3000), so I'm not quite sure what's gone wrong. I've done a bit of web browsing this morning, and saw some suggestions to change u-boot's CFG_BOOTMAPSZ from 820 to 1620; but that hasn't helped either. I'll continue to poke at this on my own, but I'd appreciate if anyone can point me in the right direction. Many thanks, --jtc ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC83xx console : no output after handover
It turned out that the normally-initialized 8250 driver was getting stomped on by my device tree's serial driver (which is also an 8250) - apparently CONFIG_SERIAL_8250[_CONSOLE] and CONFIG_SERIAL_OF_PLATFORM don't play well together. Disabling the latter fixed my problem. Thanks for the help, and sorry for the noise. -- Matthew L. Creech ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Draft version of ML510 Linux patch (patch inlined)
Hi,
As requested by Grant Likely here the same patch but now inlined.
Regards,
Roderick Colenbrander
diff -urN -X linux-2.6.29/Documentation/dontdiff
linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
--- linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts 1970-01-01
01:00:00.0 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
2009-04-01 13:18:50.0 +0200
@@ -0,0 +1,452 @@
+/*
+ * Xilinx ML510 Reference Design support
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference
design.
+ * The reference design contains two bugs which prevent PCI from
working which
+ * should be fixed by the user:
+ * - the MPLB output of the soft-core should be connected to
plbv46_plb_1 which
+ * corresponds to SPLB0 of the ppc440 to allow the soft-core to
access system
+ * memory
+ * - C_IPIFBAR2PCIBAR_0 of the soft-core should be set to 0x8000 in
order to
+ * reserve 0x8000-0x (PCI) for memory mapped i/o and the
lower addresses
+ * can be used by PCI devices to access system memory (DMA).
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = xlnx,ml510-ref-design;
+ dcr-parent = ppc440_0;
+ model = testing;
+ DDR2_SDRAM_DIMM0: mem...@0 {
+ device_type = memory;
+ reg = 0x0 0x2000 ;
+ } ;
+ chosen {
+ bootargs = console=ttyS0 root=/dev/xsa2 init=/etc/preinit;
+ linux,stdout-path = /p...@0/ser...@83e0;
+ } ;
+ cpus {
+ #address-cells = 1;
+ #cpus = 0x1;
+ #size-cells = 0;
+ ppc440_0: c...@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ clock-frequency = 3;
+ compatible = PowerPC,440, ibm,ppc440;
+ d-cache-line-size = 0x20;
+ d-cache-size = 0x8000;
+ dcr-access-method = native;
+ dcr-controller ;
+ device_type = cpu;
+ i-cache-line-size = 0x20;
+ i-cache-size = 0x8000;
+ model = PowerPC,440;
+ reg = 0;
+ timebase-frequency = 3;
+ xlnx,apu-control = 0x2000;
+ xlnx,apu-udi-0 = 0x0;
+ xlnx,apu-udi-1 = 0x0;
+ xlnx,apu-udi-10 = 0x0;
+ xlnx,apu-udi-11 = 0x0;
+ xlnx,apu-udi-12 = 0x0;
+ xlnx,apu-udi-13 = 0x0;
+ xlnx,apu-udi-14 = 0x0;
+ xlnx,apu-udi-15 = 0x0;
+ xlnx,apu-udi-2 = 0x0;
+ xlnx,apu-udi-3 = 0x0;
+ xlnx,apu-udi-4 = 0x0;
+ xlnx,apu-udi-5 = 0x0;
+ xlnx,apu-udi-6 = 0x0;
+ xlnx,apu-udi-7 = 0x0;
+ xlnx,apu-udi-8 = 0x0;
+ xlnx,apu-udi-9 = 0x0;
+ xlnx,dcr-autolock-enable = 0x1;
+ xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
+ xlnx,dcu-rd-noncache-plb-prio = 0x0;
+ xlnx,dcu-rd-touch-plb-prio = 0x0;
+ xlnx,dcu-rd-urgent-plb-prio = 0x0;
+ xlnx,dcu-wr-flush-plb-prio = 0x0;
+ xlnx,dcu-wr-store-plb-prio = 0x0;
+ xlnx,dcu-wr-urgent-plb-prio = 0x0;
+ xlnx,dma0-control = 0x0;
+ xlnx,dma0-plb-prio = 0x0;
+ xlnx,dma0-rxchannelctrl = 0x101;
+ xlnx,dma0-rxirqtimer = 0x3ff;
+ xlnx,dma0-txchannelctrl = 0x101;
+ xlnx,dma0-txirqtimer = 0x3ff;
+ xlnx,dma1-control = 0x0;
+ xlnx,dma1-plb-prio = 0x0;
+ xlnx,dma1-rxchannelctrl = 0x101;
+ xlnx,dma1-rxirqtimer = 0x3ff;
+ xlnx,dma1-txchannelctrl = 0x101;
+ xlnx,dma1-txirqtimer = 0x3ff;
+ xlnx,dma2-control = 0x0;
+ xlnx,dma2-plb-prio = 0x0;
+ xlnx,dma2-rxchannelctrl = 0x101;
+ xlnx,dma2-rxirqtimer = 0x3ff;
+ xlnx,dma2-txchannelctrl = 0x101;
+ xlnx,dma2-txirqtimer = 0x3ff;
+ xlnx,dma3-control = 0x0;
+ xlnx,dma3-plb-prio = 0x0;
+ xlnx,dma3-rxchannelctrl = 0x101;
+ xlnx,dma3-rxirqtimer = 0x3ff;
+ xlnx,dma3-txchannelctrl = 0x101;
+
[PATCH] Fix highmem build failure
The following commit breaks PPC builds with CONFIG_HIGHMEM=y
commit f4112de6b679d84bd9b9681c7504be7bdfb7c7d5
Author: Akinobu Mita akinobu.m...@gmail.com
Date: Tue Mar 31 15:23:25 2009 -0700
mm: introduce debug_kmap_atomic
We get:
CC init/main.o
In file included from include/linux/highmem.h:25,
from include/linux/pagemap.h:11,
from include/linux/mempolicy.h:63,
from init/main.c:53:
linux-2.6/arch/powerpc/include/asm/highmem.h: In function 'kmap_atomic_prot':
linux-2.6/arch/powerpc/include/asm/highmem.h:98: error: implicit declaration of
function 'debug_kmap_atomic'
In file included from include/linux/pagemap.h:11,
from include/linux/mempolicy.h:63,
from init/main.c:53:
include/linux/highmem.h: At top level:
include/linux/highmem.h:196: warning: conflicting types for 'debug_kmap_atomic'
include/linux/highmem.h:196: error: static declaration of 'debug_kmap_atomic'
follows non-static declaration
linux-2.6/include/asm/highmem.h:98: error: previous implicit declaration of
'debug_kmap_atomic' was here
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
include/linux/highmem.h | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 7ff5c55..577b53d 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -20,6 +20,19 @@ static inline void flush_kernel_dcache_page(struct page
*page)
#endif
#ifdef CONFIG_HIGHMEM
+#include asm/kmap_types.h
+
+#if defined(CONFIG_DEBUG_HIGHMEM) defined(CONFIG_TRACE_IRQFLAGS_SUPPORT)
+
+void debug_kmap_atomic(enum km_type type);
+
+#else
+
+static inline void debug_kmap_atomic(enum km_type type)
+{
+}
+
+#endif
#include asm/highmem.h
@@ -187,16 +200,4 @@ static inline void copy_highpage(struct page *to, struct
page *from)
kunmap_atomic(vto, KM_USER1);
}
-#if defined(CONFIG_DEBUG_HIGHMEM) defined(CONFIG_TRACE_IRQFLAGS_SUPPORT)
-
-void debug_kmap_atomic(enum km_type type);
-
-#else
-
-static inline void debug_kmap_atomic(enum km_type type)
-{
-}
-
-#endif
-
#endif /* _LINUX_HIGHMEM_H */
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc ptrace block-step
Maynard asked about user_enable_block_step() support on powerpc.
This is the old patch I've posted before. I haven't even tried
to compile it lately, but it rebased cleanly.
AFAIK the only reason this didn't go in several months ago was waiting
for someone to decide what the right arch_has_block_step() condition was,
i.e. if it needs to check some cpu_feature or chip identifier bits.
I had hoped that I had passed the buck then to ppc folks to figure that out
and make it so. But it does not appear to have happened.
Note you can drop the #define PTRACE_SINGLEBLOCK if you want to be
conservative and not touch the user (ptrace) ABI yet. Then Maynard
could beat on it with internal uses (utrace) before you worry about
whether userland expects the new ptrace request macro to exist.
Thanks,
Roland
---
From 2482ed1a0ced9caf964275889ea2315916e84ada Mon Sep 17 00:00:00 2001
From: Roland McGrath rol...@redhat.com
Date: Thu, 1 May 2008 23:40:58 -0700
Subject: [PATCH] powerpc ptrace block-step
This adds block-step support on powerpc,
including a PTRACE_SINGLEBLOCK request for ptrace.
Signed-off-by: Roland McGrath rol...@redhat.com
---
arch/powerpc/include/asm/ptrace.h |4
arch/powerpc/kernel/ptrace.c | 19 ++-
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h
b/arch/powerpc/include/asm/ptrace.h
index c9c678f..d7692b8 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -135,7 +135,9 @@ do {
\
* These are defined as per linux/ptrace.h, which see.
*/
#define arch_has_single_step() (1)
+#define arch_has_block_step() (1)
extern void user_enable_single_step(struct task_struct *);
+extern void user_enable_block_step(struct task_struct *);
extern void user_disable_single_step(struct task_struct *);
#endif /* __ASSEMBLY__ */
@@ -288,4 +290,6 @@ extern void user_disable_single_step(struct task_struct *);
#define PPC_PTRACE_PEEKUSR_3264 0x91
#define PPC_PTRACE_POKEUSR_3264 0x90
+#define PTRACE_SINGLEBLOCK 0x100 /* resume execution until next branch */
+
#endif /* _ASM_POWERPC_PTRACE_H */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 3635be6..656fea2 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -707,12 +707,29 @@ void user_enable_single_step(struct task_struct *task)
task-thread.dbcr0 |= DBCR0_IDM | DBCR0_IC;
regs-msr |= MSR_DE;
#else
+ regs-msr = ~MSR_BE;
regs-msr |= MSR_SE;
#endif
}
set_tsk_thread_flag(task, TIF_SINGLESTEP);
}
+void user_enable_block_step(struct task_struct *task)
+{
+ struct pt_regs *regs = task-thread.regs;
+
+ if (regs != NULL) {
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ task-thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
+ regs-msr |= MSR_DE;
+#else
+ regs-msr = ~MSR_SE;
+ regs-msr |= MSR_BE;
+#endif
+ }
+ set_tsk_thread_flag(task, TIF_SINGLESTEP);
+}
+
void user_disable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task-thread.regs;
@@ -729,7 +746,7 @@ void user_disable_single_step(struct task_struct *task)
task-thread.dbcr0 = ~(DBCR0_IC | DBCR0_IDM);
regs-msr = ~MSR_DE;
#else
- regs-msr = ~MSR_SE;
+ regs-msr = ~(MSR_SE | MSR_BE);
#endif
}
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with module_init?
On Wed, 2009-04-01 at 07:27 -0400, Josh Boyer wrote: I'm assuming this is the result of a git-bisect run? Can I also assume you were loading the module on your Warp board? Ben, have you tested module loads on 4xx since you redid this? I must shamefully admit almost never testing modules ... I always netboot zImages with all the drivers I need built-in. I suspect I just screwed up the definition of PAGE_KERNEL_EXEC or something like that. I'll have a look. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Resend: /proc/pid/maps offset output broken in 2.6.29
Resending due to lack of response to original post. I was validating some code dealing with /proc/pid/maps on 2.6.29 and was surprised when it failed. It turns out that at least on my ppc64 G5 machine the offset value for the last entry is strange--it shows up as a 64-bit value even though the process itself is only 32-bit. This behaviour also shows up in 2.6.25, but doesn't in 2.6.14. I haven't yet tested anything else in between. [cfrie...@localhost cfriesen]$ cat /proc/self/maps 0010-00103000 r-xp 0010 00:00 0 [vdso] 0fe7-0ffbf000 r-xp 08:03 4312393 /lib/tls/libc-2.3.3.so 0ffbf000-0ffc ---p 0014f000 08:03 4312393 /lib/tls/libc-2.3.3.so 0ffc-0ffc2000 r--p 0015 08:03 4312393 /lib/tls/libc-2.3.3.so 0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393 /lib/tls/libc-2.3.3.so 0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0 0ffd-0ffec000 r-xp 08:03 4309011 /lib/ld-2.3.3.so 0fff-0fff1000 r--p 0002 08:03 4309011 /lib/ld-2.3.3.so 0fff1000-0fff2000 rwxp 00021000 08:03 4309011 /lib/ld-2.3.3.so 1000-10004000 r-xp 08:03 917536/bin/cat 10013000-10015000 rwxp 3000 08:03 917536/bin/cat 10015000-10036000 rwxp 10015000 00:00 0 [heap] f7deb000-f7feb000 r--p 08:03 2560322 /usr/lib/locale/locale-archive f7feb000-f7fec000 rw-p f7feb000 00:00 0 ffe6d000-ffe82000 rw-p ffeb000 00:00 0 [stack] I'm at a loss to explain what's going on here. Anyone got any ideas? Thanks, Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
On Wed, Apr 01, 2009 at 01:59:36PM +0200, Wolfgang Grandegger wrote:
David Gibson wrote:
On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
Hi David,
this patch went out by mistake, sorry.
David Gibson wrote:
On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts2009-03-31
13:24:38.078719288 +0200
+++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:47:56.986720719 +0200
@@ -52,6 +52,7 @@
soc8...@e000 {
#address-cells = 1;
#size-cells = 1;
+device_type = soc;
You should not be adding device_type to a new board's dts. You
*especially* shouldn't be doing that with no patch comment explaining
why.
In the final patch I have removed the device_type = soc, but it makes
trouble as some mpc85xx rely on it.
Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
don't see how something that affects some mpc85xx is relevant.
Well, to be more precise, it affects all boards using CONFIG_FSL_SOC
because they use functions searching for the device type soc, e.g.
fsl_get_sys_freq():
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
This needs to be fixed before the line 'device_type = soc' can be removed.
Gah. I had been under the impression that had been fixed already.
Kumar! Get your house in order!
Ok, I guess it will have to stay for now, just as long as the new
style marker in compatible is there as well.
--
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 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
On Wed, Apr 01, 2009 at 04:30:29PM +0400, Anton Vorontsov wrote:
On Wed, Apr 01, 2009 at 10:09:55PM +1100, David Gibson wrote:
On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
Hi David,
this patch went out by mistake, sorry.
David Gibson wrote:
On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:24:38.078719288 +0200
+++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31
13:47:56.986720719 +0200
@@ -52,6 +52,7 @@
soc8...@e000 {
#address-cells = 1;
#size-cells = 1;
+ device_type = soc;
You should not be adding device_type to a new board's dts. You
*especially* shouldn't be doing that with no patch comment explaining
why.
In the final patch I have removed the device_type = soc, but it makes
trouble as some mpc85xx rely on it.
Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
don't see how something that affects some mpc85xx is relevant.
Not some, but *all* mpc85xx. The thing is that U-Boot is searching
for device_type = soc to fixup some properties (for example,
bus-frequency) for all mpc85xx parts, so you can't easily remove
the device_type w/o breaking boot for firmwares that customers have
pre-programmed in their products.
I thought that was fixed in current u-boot versions.
Note that upgrading firmware without JTAG is dangerous, so it's not
an option to force everybody to upgrade their firmware just
because we want to remove some cruft from the device tree.
I realise that, but again this is a *new board*, which presumably can
use an up-to-date u-boot version.
--
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: i2c-mpc: preserve I2C clocking
On Wed, Apr 01, 2009 at 09:40:13AM +0200, Wolfgang Grandegger wrote: David Gibson wrote: On Tue, Mar 31, 2009 at 02:43:39PM +0200, Wolfgang Grandegger wrote: The I2c node property fsl,preserve-clocking allows to overtake the clock settings from the boot loader and avoids the hard-coded setting. Hrm. This is dubious. The device tree should generally describe hardware, not OS/driver behaviour which is what this appears to be doing. There are exceptions, but you need to justify them. I think the purpose of this property is clear. How would you provide that functionality instead? I suggested that a clock-frequency = 0 property should do the trick but Grant preferred to be more explicit. I'm not saying the meaning is unclear, I'm saying it's describing something that the device tree isn't meant to describe. AFAICT it's telling the driver what to do with the device, not a property of the device itself. Now, there are cases where it's acceptable to put this sort of information in the device tree, because it's the least nasty available solution (flash partition information for example). But you need to justify it, if that's so. -- 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 next] powerpc: pseries/dtl.c should include asm/firmware.h
randconfig build on powerpc failed with : arch/powerpc/platforms/pseries/dtl.c: In function dtl_init: arch/powerpc/platforms/pseries/dtl.c:238: error: implicit declaration of func tion firmware_has_feature arch/powerpc/platforms/pseries/dtl.c:238: error: FW_FEATURE_SPLPAR undeclared (first use in this function) arch/powerpc/platforms/pseries/dtl.c:238: error: (Each undeclared identifier is reported only once arch/powerpc/platforms/pseries/dtl.c:238: error: for each function it appears in.) Signed-off-by : Sachin Sant sach...@in.ibm.com --- It's great that you're sending patches to fix these issues but it's not quite formatted as the maintainers like. The patch needs to be included inline in the message, rather than as an attachment. You can see it as an attachment here: http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070122.html .. as opposed to the required inline format like this patch: http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070120.html Adding a diffstat would also be nice. Mikey --050404090408000502010008 Content-Type: text/x-patch; name=fix-dtl-build-break.patch Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename=fix-dtl-build-break.patch * Fixes the following build error * * arch/powerpc/platforms/pseries/dtl.c: In function ‘dtl_init’: * arch/powerpc/platforms/pseries/dtl.c:238: * error: implicit declaration of function ‘firmware_has_feature’ * arch/powerpc/platforms/pseries/dtl.c:238: * error: ‘FW_FEATURE_SPLPAR’ undeclared (first use in this function) * arch/powerpc/platforms/pseries/dtl.c:238: *error: (Each undeclared identifier is reported only once * arch/powerpc/platforms/pseries/dtl.c:238: *error: for each function it appears in.) Signed-off-by : Sachin Sant sach...@in.ibm.com --- diff -Naurp a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/p series/dtl.c --- a/arch/powerpc/platforms/pseries/dtl.c2009-04-01 15:46:59.0 + 0530 +++ b/arch/powerpc/platforms/pseries/dtl.c2009-04-01 15:47:58.0 + 0530 @@ -25,6 +25,7 @@ #include asm/smp.h #include asm/system.h #include asm/uaccess.h +#include asm/firmware.h #include plpar_wrappers.h --050404090408000502010008 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev --050404090408000502010008-- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: issue at the beginning of kernel booting
thanks Scott
Another thing that would generally be good is to keep replies on the
list rather than taking it to private e-mail as soon as someone replies.
Someone else may have something helpful to say based on your followup,
or may have the same problem and be helped by the conclusion.
ok~ excuse for my mistake, thank you for your words. i will do it like you
say from now on. it surely be better.
I don't see where you set up a BAT that covers 0xf000.
if i have to set up a BAT that cover 0xF000. i had a debug with LEDs
like that in u-boot code. everything is //normal. 0xF is the value
of CFG_IMMR(CONFIG_SYS_IMMR) that memory map register, it is the phy address
and //base //address of all internal regishters, isnt? you mean that if i
set BATs, i should not get the phy address like in the //front ?
Do you have a correct fdt, that matches a platform that is enabled in
your .config?
i think so, i used mpc8272ads_defconfig becasue my processor is mpc8272, i
got a mail before about modifying and //config fdt file mpc8272ads.dts. i
fixed up my file like that.
i tried
CONFIG_PPC_EARLY_DEBUG_CPM=y
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf0008
how can i make sure CPM_ADDR, 0xf008 is default value
now it show as follow. i select smc1 as console. please check it and give me
some advice.
/ {
model = MPC8272ADS;
compatible = fsl,mpc8272ads;
#address-cells = 1;
#size-cells = 1;
cpus {
#address-cells = 1;
#size-cells = 0;
PowerPC,8...@0 {
device_type = cpu;
reg = 0;
d-cache-line-size = d#32;
i-cache-line-size = d#32;
d-cache-size = d#16384;
i-cache-size = d#16384;
timebase-frequency = 0;
bus-frequency = 0;
clock-frequency = 0;
};
};
memory {
device_type = memory;
reg = 0 0;
};
local...@f0010100 {
compatible = fsl,mpc8272-localbus,
fsl,pq2-localbus;
#address-cells = 2;
#size-cells = 1;
reg = f0010100 40;
/* chengmo : modify by my own device */
ranges = 0 0 FFF0 0008 //CS0: Flahs 512k
2 0 0200 //CS2: SDRAM 32M
;
fl...@0,0 {
compatible = cfi-flash;
reg = 0 0 0008;
bank-width = 4;
device-width = 1; // 16 bits
};
PCI_PIC: interrupt-control...@3,0 {
compatible = fsl,mpc8272ads-pci-pic,
fsl,pq2ads-pci-pic;
#interrupt-cells = 1;
interrupt-controller;
reg = 3 0 8;
interrupt-parent = PIC;
interrupts = 14 8;
};
};
s...@f000 {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
compatible = fsl,mpc8272, fsl,pq2-soc;
ranges = f000 00053000;
// Temporary -- will go away once kernel uses ranges for
get_immrbase().
reg = f000 00053000;
c...@119c0 {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,mpc8272-cpm, fsl,cpm2;
reg = 119c0 30;
ranges;
mu...@0 {
#address-cells = 1;
#size-cells = 1;
ranges = 0 0 1;
d...@0 {
compatible = fsl,cpm-muram-data;
reg = 0 2000 9800 800;
};
};
b...@119f0 {
compatible = fsl,mpc8272-brg,
fsl,cpm2-brg,
fsl,cpm-brg;
reg = 119f0 10 115f0 10;
};
ser...@11a82 {
device_type = serial;
compatible = fsl,mpc8272-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a82 20 87FC 100;
interrupts = 28 8;
interrupt-parent = PIC;
Re: [PATCH] Fix highmem build failure
On Wed, Apr 01, 2009 at 04:33:31PM -0500, Kumar Gala wrote:
The following commit breaks PPC builds with CONFIG_HIGHMEM=y
commit f4112de6b679d84bd9b9681c7504be7bdfb7c7d5
Author: Akinobu Mita akinobu.m...@gmail.com
Date: Tue Mar 31 15:23:25 2009 -0700
mm: introduce debug_kmap_atomic
Thanks.
But the definition of debug_kmap_atomic() needs to be outside of
ifdef CONFIG_HIGHMEM. Because debug_kmap_atomic() is used without
CONFIG_HIGHMEM by kmap_atomic_prot_pfn() in arch/x86/mm/iomap_32.c
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -20,6 +20,19 @@ static inline void flush_kernel_dcache_page(struct page
*page)
#endif
#ifdef CONFIG_HIGHMEM
+#include asm/kmap_types.h
+
+#if defined(CONFIG_DEBUG_HIGHMEM) defined(CONFIG_TRACE_IRQFLAGS_SUPPORT)
+
+void debug_kmap_atomic(enum km_type type);
+
+#else
+
+static inline void debug_kmap_atomic(enum km_type type)
+{
+}
+
+#endif
#include asm/highmem.h
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: change giveup_fpu/altivec to disable VSX for current
When we call giveup_fpu, we need to need to turn off VSX in current. If we don't, on return to current it may execute a VSX instruction (before the next FP), and not have it's register state refreshed correctly from the thread_struct. Ditto for altivec. This caused a bug where an unaligned lfs or stfs (which calls giveup_fpu so it can use the FPRs) to return to userspace with FP off but VSX on. Then if a VSX instruction is executed, before another FP instruction, it will proceed without another exception and hence have the incorrect register state for VSX registers 0-31. lfs unaligned - alignment exception turns FP off but leaves VSX on VSX instruction - no exception since VSX on, hence we get the wrong VSX register values for VSX registers 0-31 (overlapping the FPRs) Signed-off-by: Michael Neuling mi...@neuling.org --- arch/powerpc/kernel/fpu.S |5 + arch/powerpc/kernel/misc_64.S |8 2 files changed, 13 insertions(+) Index: linux-2.6-ozlabs/arch/powerpc/kernel/fpu.S === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/fpu.S +++ linux-2.6-ozlabs/arch/powerpc/kernel/fpu.S @@ -145,6 +145,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX) beq 1f PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5) li r3,MSR_FP|MSR_FE0|MSR_FE1 +#ifdef CONFIG_VSX +BEGIN_FTR_SECTION + orisr3,r3,msr_...@h +END_FTR_SECTION_IFSET(CPU_FTR_VSX) +#endif andcr4,r4,r3/* disable FP for previous task */ PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5) 1: Index: linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/misc_64.S +++ linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S @@ -495,7 +495,15 @@ _GLOBAL(giveup_altivec) stvxvr0,r4,r3 beq 1f ld r4,_MSR-STACK_FRAME_OVERHEAD(r5) +#ifdef CONFIG_VSX +BEGIN_FTR_SECTION + lis r3,(MSR_VEC|MSR_VSX)@h +FTR_SECTION_ELSE + lis r3,msr_...@h +ALT_FTR_SECTION_END_IFSET(CPU_FTR_VSX) +#else lis r3,msr_...@h +#endif andcr4,r4,r3/* disable FP for previous task */ std r4,_MSR-STACK_FRAME_OVERHEAD(r5) 1: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with module_init?
On Thu, 02 Apr 2009 09:24:43 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: I suspect I just screwed up the definition of PAGE_KERNEL_EXEC or something like that. Yup, that is exactly what you did ;) You left out _PAGE_HWEXEC. The following patch fixes the problem for me. Cheers, Sean diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h index d9740e8..a84f248 100644 --- a/arch/powerpc/include/asm/pte-common.h +++ b/arch/powerpc/include/asm/pte-common.h @@ -167,7 +167,8 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); #endif /* Make modules code happy. We don't set RO yet */ -#define PAGE_KERNEL_EXEC PAGE_KERNEL_X +// #define PAGE_KERNEL_EXECPAGE_KERNEL_X +#define PAGE_KERNEL_EXEC __pgprot(_PAGE_BASE | _PAGE_KERNEL_RW | _PAGE_EXEC | _PAGE_HWEXEC) /* Advertise special mapping type for AGP */ #define PAGE_AGP (PAGE_KERNEL_NC) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with module_init?
On Thu, 2009-04-02 at 00:08 -0400, Sean MacLennan wrote: On Thu, 02 Apr 2009 09:24:43 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: I suspect I just screwed up the definition of PAGE_KERNEL_EXEC or something like that. Yup, that is exactly what you did ;) You left out _PAGE_HWEXEC. The following patch fixes the problem for me. The proper fix is for PAGE_KERNEL_X to have _PAGE_HWEXEC. I'll fix that. Cheers, Ben. Cheers, Sean diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h index d9740e8..a84f248 100644 --- a/arch/powerpc/include/asm/pte-common.h +++ b/arch/powerpc/include/asm/pte-common.h @@ -167,7 +167,8 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); #endif /* Make modules code happy. We don't set RO yet */ -#define PAGE_KERNEL_EXEC PAGE_KERNEL_X +// #define PAGE_KERNEL_EXEC PAGE_KERNEL_X +#define PAGE_KERNEL_EXEC __pgprot(_PAGE_BASE | _PAGE_KERNEL_RW | _PAGE_EXEC | _PAGE_HWEXEC) /* Advertise special mapping type for AGP */ #define PAGE_AGP (PAGE_KERNEL_NC) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] Fix highmem build failure
The following commit breaks PPC builds with CONFIG_HIGHMEM=y
commit f4112de6b679d84bd9b9681c7504be7bdfb7c7d5
Author: Akinobu Mita akinobu.m...@gmail.com
Date: Tue Mar 31 15:23:25 2009 -0700
mm: introduce debug_kmap_atomic
We get:
CC init/main.o
In file included from include/linux/highmem.h:25,
from include/linux/pagemap.h:11,
from include/linux/mempolicy.h:63,
from init/main.c:53:
linux-2.6/arch/powerpc/include/asm/highmem.h: In function 'kmap_atomic_prot':
linux-2.6/arch/powerpc/include/asm/highmem.h:98: error: implicit declaration of
function 'debug_kmap_atomic'
In file included from include/linux/pagemap.h:11,
from include/linux/mempolicy.h:63,
from init/main.c:53:
include/linux/highmem.h: At top level:
include/linux/highmem.h:196: warning: conflicting types for 'debug_kmap_atomic'
include/linux/highmem.h:196: error: static declaration of 'debug_kmap_atomic'
follows non-static declaration
linux-2.6/include/asm/highmem.h:98: error: previous implicit declaration of
'debug_kmap_atomic' was here
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
Should address Akinobu issues w/having this build properly on x86
- k
include/linux/highmem.h | 29 ++---
1 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 7ff5c55..1fcb712 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -19,8 +19,21 @@ static inline void flush_kernel_dcache_page(struct page
*page)
}
#endif
-#ifdef CONFIG_HIGHMEM
+#include asm/kmap_types.h
+
+#if defined(CONFIG_DEBUG_HIGHMEM) defined(CONFIG_TRACE_IRQFLAGS_SUPPORT)
+
+void debug_kmap_atomic(enum km_type type);
+
+#else
+static inline void debug_kmap_atomic(enum km_type type)
+{
+}
+
+#endif
+
+#ifdef CONFIG_HIGHMEM
#include asm/highmem.h
/* declarations for linux/mm/highmem.c */
@@ -44,8 +57,6 @@ static inline void *kmap(struct page *page)
#define kunmap(page) do { (void) (page); } while (0)
-#include asm/kmap_types.h
-
static inline void *kmap_atomic(struct page *page, enum km_type idx)
{
pagefault_disable();
@@ -187,16 +198,4 @@ static inline void copy_highpage(struct page *to, struct
page *from)
kunmap_atomic(vto, KM_USER1);
}
-#if defined(CONFIG_DEBUG_HIGHMEM) defined(CONFIG_TRACE_IRQFLAGS_SUPPORT)
-
-void debug_kmap_atomic(enum km_type type);
-
-#else
-
-static inline void debug_kmap_atomic(enum km_type type)
-{
-}
-
-#endif
-
#endif /* _LINUX_HIGHMEM_H */
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with module_init?
On Thu, 2 Apr 2009 00:39:05 -0400 Sean MacLennan sean.maclen...@ottawa.kanatek.ca wrote: Although, that *could* be unrelated bug. It *is* an unrelated bug. dma_alloc_coherent now requires a device where before it was optional. Carry on. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with module_init?
On Thu, 2009-04-02 at 00:51 -0400, Sean MacLennan wrote: On Thu, 2 Apr 2009 00:39:05 -0400 Sean MacLennan sean.maclen...@ottawa.kanatek.ca wrote: Although, that *could* be unrelated bug. It *is* an unrelated bug. dma_alloc_coherent now requires a device where before it was optional. Carry on. Right, that's new in .30 Cheers, Ben. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'next' branch (for 2.6.30)
Please pull from 'next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next to receive the following updates: arch/powerpc/Kconfig |1 + arch/powerpc/boot/dts/ksi8560.dts |4 ++-- arch/powerpc/boot/dts/sbc8548.dts |4 ++-- arch/powerpc/boot/dts/sbc8560.dts |4 ++-- arch/powerpc/boot/dts/stx_gp3_8560.dts |4 ++-- arch/powerpc/boot/dts/tqm8540.dts |4 ++-- arch/powerpc/boot/dts/tqm8541.dts |4 ++-- arch/powerpc/boot/dts/tqm8555.dts |4 ++-- arch/powerpc/boot/dts/tqm8560.dts |4 ++-- include/linux/fsl_devices.h| 22 -- 10 files changed, 17 insertions(+), 38 deletions(-) Grant Likely (1): powerpc: Remove unused symbols from fsl_devices.h Josh Boyer (1): powerpc: Make LOWMEM_CAM_NUM depend on FSL_BOOKE Kumar Gala (1): powerpc/85xx: Use fsl,mpc85.. as prefix for memory ctrl l2-cache nodes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc ptrace block-step
On Wed, 2009-04-01 at 14:59 -0700, Roland McGrath wrote:
diff --git a/arch/powerpc/include/asm/ptrace.h
b/arch/powerpc/include/asm/ptrace.h
index c9c678f..d7692b8 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -135,7 +135,9 @@ do {
\
* These are defined as per linux/ptrace.h, which see.
*/
#define arch_has_single_step() (1)
+#define arch_has_block_step()(1)
The patch only implements it for server/classic processors, not BookE,
thus it should probably only advertise it for these :-)
Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
(Branch Taken debug event) though it might need some careful fixups such
as the one we have for single step regarding hitting exception entry
code.
Cheers,
Ben.
extern void user_enable_single_step(struct task_struct *);
+extern void user_enable_block_step(struct task_struct *);
extern void user_disable_single_step(struct task_struct *);
#endif /* __ASSEMBLY__ */
@@ -288,4 +290,6 @@ extern void user_disable_single_step(struct task_struct
*);
#define PPC_PTRACE_PEEKUSR_3264 0x91
#define PPC_PTRACE_POKEUSR_3264 0x90
+#define PTRACE_SINGLEBLOCK 0x100 /* resume execution until next branch */
+
#endif /* _ASM_POWERPC_PTRACE_H */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 3635be6..656fea2 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -707,12 +707,29 @@ void user_enable_single_step(struct task_struct *task)
task-thread.dbcr0 |= DBCR0_IDM | DBCR0_IC;
regs-msr |= MSR_DE;
#else
+ regs-msr = ~MSR_BE;
regs-msr |= MSR_SE;
#endif
}
set_tsk_thread_flag(task, TIF_SINGLESTEP);
}
+void user_enable_block_step(struct task_struct *task)
+{
+ struct pt_regs *regs = task-thread.regs;
+
+ if (regs != NULL) {
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ task-thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
+ regs-msr |= MSR_DE;
+#else
+ regs-msr = ~MSR_SE;
+ regs-msr |= MSR_BE;
+#endif
+ }
+ set_tsk_thread_flag(task, TIF_SINGLESTEP);
+}
+
void user_disable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task-thread.regs;
@@ -729,7 +746,7 @@ void user_disable_single_step(struct task_struct *task)
task-thread.dbcr0 = ~(DBCR0_IC | DBCR0_IDM);
regs-msr = ~MSR_DE;
#else
- regs-msr = ~MSR_SE;
+ regs-msr = ~(MSR_SE | MSR_BE);
#endif
}
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
