* [PATCH] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
From: Grant Likely @ 2009-12-04 21:20 UTC (permalink / raw)
To: netdev, linuxppc-dev, David S. Miller; +Cc: Asier Llano
From: Asier Llano Palacios <asierllano@gmail.com>
net/mpc5200: Fix locking on fec_mpc52xx driver
Fix the locking scheme on the fec_mpc52xx driver. This device can
receive IRQs from three sources; the FEC itself, the tx DMA, and the
rx DMA. Mutual exclusion was handled by taking a spin_lock() in the
critical regions, but because the handlers are run with IRQs enabled,
spin_lock() is insufficient and the driver can end up interrupting
a critical region anyway from another IRQ.
Asier Llano discovered that this occurs when an error IRQ is raised
in the middle of handling rx irqs which resulted in an sk_buff memory
leak.
In addition, locking is spotty at best in the driver and inspection
revealed quite a few places with insufficient locking.
This patch is based on Asier's initial work, but reworks a number of
things so that locks are held for as short a time as possible, so
that spin_lock_irqsave() is used everywhere, and so the locks are
dropped when calling into the network stack (because the lock only
protects the hardware interface; not the network stack).
Boot tested on a lite5200 with an NFS root. Has not been performance
tested.
Signed-off-by: Asier Llano <a.llano@ziv.es>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Asier, can you please test this? It took me a while to respond to
your initial post because I was concerned about some of the latency
issues, and I was concerned about disabling IRQs for long periods in
the RX handler. I think it should be good now, but it needs testing.
Cheers,
g.
drivers/net/fec_mpc52xx.c | 121 +++++++++++++++++++++++----------------------
1 files changed, 62 insertions(+), 59 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 66dace6..4889b4d 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -85,11 +85,15 @@ MODULE_PARM_DESC(debug, "debugging messages level");
static void mpc52xx_fec_tx_timeout(struct net_device *dev)
{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ unsigned long flags;
+
dev_warn(&dev->dev, "transmit timed out\n");
+ spin_lock_irqsave(&priv->lock, flags);
mpc52xx_fec_reset(dev);
-
dev->stats.tx_errors++;
+ spin_unlock_irqrestore(&priv->lock, flags);
netif_wake_queue(dev);
}
@@ -135,28 +139,32 @@ static void mpc52xx_fec_free_rx_buffers(struct net_device *dev, struct bcom_task
}
}
+static void
+mpc52xx_fec_rx_submit(struct net_device *dev, struct sk_buff *rskb)
+{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ struct bcom_fec_bd *bd;
+
+ bd = (struct bcom_fec_bd *) bcom_prepare_next_buffer(priv->rx_dmatsk);
+ bd->status = FEC_RX_BUFFER_SIZE;
+ 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);
+}
+
static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct bcom_task *rxtsk)
{
- while (!bcom_queue_full(rxtsk)) {
- struct sk_buff *skb;
- struct bcom_fec_bd *bd;
+ struct sk_buff *skb;
+ while (!bcom_queue_full(rxtsk)) {
skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
- if (skb == NULL)
+ if (!skb)
return -EAGAIN;
/* zero out the initial receive buffers to aid debugging */
memset(skb->data, 0, FEC_RX_BUFFER_SIZE);
-
- bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
-
- bd->status = FEC_RX_BUFFER_SIZE;
- bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
-
- bcom_submit_next_buffer(rxtsk, skb);
+ mpc52xx_fec_rx_submit(dev, skb);
}
-
return 0;
}
@@ -328,13 +336,12 @@ static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
DMA_TO_DEVICE);
bcom_submit_next_buffer(priv->tx_dmatsk, skb);
+ spin_unlock_irqrestore(&priv->lock, flags);
if (bcom_queue_full(priv->tx_dmatsk)) {
netif_stop_queue(dev);
}
- spin_unlock_irqrestore(&priv->lock, flags);
-
return NETDEV_TX_OK;
}
@@ -359,9 +366,9 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ unsigned long flags;
- spin_lock(&priv->lock);
-
+ spin_lock_irqsave(&priv->lock, flags);
while (bcom_buffer_done(priv->tx_dmatsk)) {
struct sk_buff *skb;
struct bcom_fec_bd *bd;
@@ -372,11 +379,10 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
dev_kfree_skb_irq(skb);
}
+ spin_unlock_irqrestore(&priv->lock, flags);
netif_wake_queue(dev);
- spin_unlock(&priv->lock);
-
return IRQ_HANDLED;
}
@@ -384,67 +390,60 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ struct sk_buff *rskb; /* received sk_buff */
+ struct sk_buff *skb; /* new sk_buff to enqueue in its place */
+ struct bcom_fec_bd *bd;
+ u32 status, physaddr;
+ int length;
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->lock, flags);
while (bcom_buffer_done(priv->rx_dmatsk)) {
- struct sk_buff *skb;
- struct sk_buff *rskb;
- struct bcom_fec_bd *bd;
- u32 status;
rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
- (struct bcom_bd **)&bd);
- dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
- DMA_FROM_DEVICE);
+ (struct bcom_bd **)&bd);
+ physaddr = bd->skb_pa;
/* Test for errors in received frame */
if (status & BCOM_FEC_RX_BD_ERRORS) {
/* Drop packet and reuse the buffer */
- bd = (struct bcom_fec_bd *)
- bcom_prepare_next_buffer(priv->rx_dmatsk);
-
- bd->status = FEC_RX_BUFFER_SIZE;
- 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);
-
+ mpc52xx_fec_rx_submit(dev, rskb);
dev->stats.rx_dropped++;
-
continue;
}
/* skbs are allocated on open, so now we allocate a new one,
* and remove the old (with the packet) */
skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
- if (skb) {
- /* Process the received skb */
- int length = status & BCOM_FEC_RX_BD_LEN_MASK;
-
- skb_put(rskb, length - 4); /* length without CRC32 */
-
- rskb->dev = dev;
- rskb->protocol = eth_type_trans(rskb, dev);
-
- netif_rx(rskb);
- } else {
+ if (!skb) {
/* Can't get a new one : reuse the same & drop pkt */
- dev_notice(&dev->dev, "Memory squeeze, dropping packet.\n");
+ dev_notice(&dev->dev, "Low memory - dropped packet.\n");
+ mpc52xx_fec_rx_submit(dev, rskb);
dev->stats.rx_dropped++;
-
- skb = rskb;
+ continue;
}
- bd = (struct bcom_fec_bd *)
- bcom_prepare_next_buffer(priv->rx_dmatsk);
+ /* Enqueue the new sk_buff back on the hardware */
+ mpc52xx_fec_rx_submit(dev, skb);
- bd->status = FEC_RX_BUFFER_SIZE;
- bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
+ /* Process the received skb - Drop the spin lock while
+ * calling into the network stack */
+ spin_unlock_irqrestore(&priv->lock, flags);
- bcom_submit_next_buffer(priv->rx_dmatsk, skb);
+ dma_unmap_single(dev->dev.parent, physaddr, rskb->len,
+ DMA_FROM_DEVICE);
+ length = status & BCOM_FEC_RX_BD_LEN_MASK;
+ skb_put(rskb, length - 4); /* length without CRC32 */
+ rskb->dev = dev;
+ rskb->protocol = eth_type_trans(rskb, dev);
+ netif_rx(rskb);
+
+ spin_lock_irqsave(&priv->lock, flags);
}
+ spin_unlock_irqrestore(&priv->lock, flags);
+
return IRQ_HANDLED;
}
@@ -454,6 +453,7 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
struct mpc52xx_fec __iomem *fec = priv->fec;
u32 ievent;
+ unsigned long flags;
ievent = in_be32(&fec->ievent);
@@ -471,9 +471,10 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
+ spin_lock_irqsave(&priv->lock, flags);
mpc52xx_fec_reset(dev);
+ spin_unlock_irqrestore(&priv->lock, flags);
- netif_wake_queue(dev);
return IRQ_HANDLED;
}
@@ -768,6 +769,8 @@ static void mpc52xx_fec_reset(struct net_device *dev)
bcom_enable(priv->tx_dmatsk);
mpc52xx_fec_start(dev);
+
+ netif_wake_queue(dev);
}
^ permalink raw reply related
* Re: [RFC PATCH v4 2/2] powerpc: gamecube/wii: early debugging using usbgecko
From: Segher Boessenkool @ 2009-12-04 19:56 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B193EAD.2040303@yahoo.es>
>>> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
>>> +setup_usbgecko_bat:
>>> + /* prepare a BAT for early io */
>>> +#if defined(CONFIG_GAMECUBE)
>>> + lis r8, 0x0c00
>>> +#elif defined(CONFIG_WII)
>>> + lis r8, 0x0d00
>>> +#else
>>> +#error Invalid platform for USB Gecko based early debugging.
>>> +#endif
>>
>> A kernel with both CONFIG_WII and CONFIG_GAMECUBE works fine
>> on either, right? If so, could you please switch the two #ifs?
>> A dual-platform kernel will be used on a Wii much more likely
>> than on a GC.
>
> Nope, a GameCube kernel currently doesn't work on a Wii and the same the
> other way around.
What is the problem, just the wrappers?
> But I can make that particular check a runtime check.
Nah, don't bother, this is just early debug stuff.
> The idea would be to enclose that snippet in GAMECUBE_COMMON and check the
> PVR.
Ugly!
Segher
^ permalink raw reply
* [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
From: Peter Tyser @ 2009-12-04 19:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Peter Tyser
This change resolves 2 issues:
- Different chips have a different number of GPIO pins per controller.
For example, the MPC8347 has 32, the P2020 16, and the mpc8572 8.
Previously, the mpc8xxx_gpio driver assumed every chip had 32 GPIO
pins which resulted in some processors reporting an incorrect 'ngpio'
field in /sys. Additionally, users could export and "use" 32 GPIO
pins, although in reality only a subset of the 32 pins had any real
functionality.
- Some boards don't utilize all available GPIO pins. Previously,
unused GPIO pins could still be exported and "used", even though the
pins had no real functionality. This is somewhat confusing to a user
and also allow a user to do something "bad", like change an unused
floating output into a floating input.
Adding a new "fsl,gpio-mask" device tree property allows a dts file to
accurately describe what GPIO pins are available for use on a given
board.
Note that the 'ngpio' value reported in /sys will represent the
"highest" gpio pin accessible, not the total number of gpio pins
available. For example, if a device only allowed the use of GPIO pin 3
(fsl,gpio-mask = 0x8), 'ngpio' would be reported as 4, although
only GPIO pin 3 could be exported and used.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---
I don't know which GPIO pins are usable on Freescale boards. Let me
know if the default mask for the reference boards should change.
Thanks,
Peter
.../powerpc/dts-bindings/fsl/8xxx_gpio.txt | 11 ++++++--
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +
arch/powerpc/boot/dts/mpc8377_wlan.dts | 2 +
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +
arch/powerpc/boot/dts/p2020ds.dts | 1 +
arch/powerpc/boot/dts/p2020rdb.dts | 1 +
arch/powerpc/boot/dts/xcalibur1501.dts | 1 +
arch/powerpc/boot/dts/xpedite5301.dts | 1 +
arch/powerpc/boot/dts/xpedite5330.dts | 1 +
arch/powerpc/boot/dts/xpedite5370.dts | 1 +
arch/powerpc/sysdev/mpc8xxx_gpio.c | 24 ++++++++++++++++---
12 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
index d015dce..a8fac7f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
@@ -11,9 +11,12 @@ Required properties:
83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- - interrupts : Interrupt mapping for GPIO IRQ (currently unused).
- - interrupt-parent : Phandle for the interrupt controller that
- services interrupts for this device.
+- interrupts : Interrupt mapping for GPIO IRQ (currently unused).
+- interrupt-parent : Phandle for the interrupt controller that
+ services interrupts for this device.
+- fsl,gpio-mask: A bitmask representing which GPIO pins are availabe for
+ use. For example, a value of 0x13 means GPIO pins 0, 1, and 4 are
+ usable.
- gpio-controller : Marks the port as GPIO controller.
Example of gpio-controller nodes for a MPC8347 SoC:
@@ -24,6 +27,7 @@ Example of gpio-controller nodes for a MPC8347 SoC:
reg = <0xc00 0x100>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0xffffffff>;
gpio-controller;
};
@@ -33,6 +37,7 @@ Example of gpio-controller nodes for a MPC8347 SoC:
reg = <0xd00 0x100>;
interrupts = <75 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0xffffffff>;
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 9e2264b..6152bfa 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -115,6 +115,7 @@
reg = <0xc00 0x100>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0xffffffff>;
gpio-controller;
};
@@ -124,6 +125,7 @@
reg = <0xd00 0x100>;
interrupts = <75 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0xffffffff>;
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/mpc8377_wlan.dts b/arch/powerpc/boot/dts/mpc8377_wlan.dts
index 9ea7830..a26535c 100644
--- a/arch/powerpc/boot/dts/mpc8377_wlan.dts
+++ b/arch/powerpc/boot/dts/mpc8377_wlan.dts
@@ -105,6 +105,7 @@
reg = <0xc00 0x100>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0xffffffff>;
gpio-controller;
};
@@ -114,6 +115,7 @@
reg = <0xd00 0x100>;
interrupts = <75 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0xffffffff>;
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 4e6a1a4..11ba39c 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -115,6 +115,7 @@
reg = <0xc00 0x100>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0xffffffff>;
gpio-controller;
};
@@ -124,6 +125,7 @@
reg = <0xd00 0x100>;
interrupts = <75 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0xffffffff>;
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index 72336d5..975bdd7 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -113,6 +113,7 @@
reg = <0xc00 0x100>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0x3ffffff>; /* mpc8379 has 26 gpio */
gpio-controller;
};
@@ -122,6 +123,7 @@
reg = <0xd00 0x100>;
interrupts = <75 0x8>;
interrupt-parent = <&ipic>;
+ fsl,gpio-mask = <0x3ffffff>; /* mpc8379 has 26 gpio */
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/p2020ds.dts b/arch/powerpc/boot/dts/p2020ds.dts
index 1101914..e64a936 100644
--- a/arch/powerpc/boot/dts/p2020ds.dts
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -277,6 +277,7 @@
reg = <0xf000 0x100>;
interrupts = <47 0x2>;
interrupt-parent = <&mpic>;
+ fsl,gpio-mask = <0xffff>; /* p2020 has 16 gpio*/
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts b/arch/powerpc/boot/dts/p2020rdb.dts
index da4cb0d..53f75ca 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -337,6 +337,7 @@
reg = <0xf000 0x100>;
interrupts = <47 0x2>;
interrupt-parent = <&mpic>;
+ fsl,gpio-mask = <0xffff>; /* p2020 has 16 gpio*/
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
index ac0a617..858668c 100644
--- a/arch/powerpc/boot/dts/xcalibur1501.dts
+++ b/arch/powerpc/boot/dts/xcalibur1501.dts
@@ -598,6 +598,7 @@
interrupts = <47 2>;
interrupt-parent = <&mpic>;
#gpio-cells = <2>;
+ fsl,gpio-mask = <0xf0>; /* 4 LEDs */
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/xpedite5301.dts b/arch/powerpc/boot/dts/xpedite5301.dts
index db7faf5..944f08c 100644
--- a/arch/powerpc/boot/dts/xpedite5301.dts
+++ b/arch/powerpc/boot/dts/xpedite5301.dts
@@ -508,6 +508,7 @@
interrupts = <47 2>;
interrupt-parent = <&mpic>;
#gpio-cells = <2>;
+ fsl,gpio-mask = <0xf0>; /* 4 LEDs */
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/xpedite5330.dts b/arch/powerpc/boot/dts/xpedite5330.dts
index c364ca6..1dacacd 100644
--- a/arch/powerpc/boot/dts/xpedite5330.dts
+++ b/arch/powerpc/boot/dts/xpedite5330.dts
@@ -544,6 +544,7 @@
interrupts = <47 2>;
interrupt-parent = <&mpic>;
#gpio-cells = <2>;
+ fsl,gpio-mask = <0xf0>; /* 4 LEDs */
gpio-controller;
};
diff --git a/arch/powerpc/boot/dts/xpedite5370.dts b/arch/powerpc/boot/dts/xpedite5370.dts
index 7a8a4af..d783a50 100644
--- a/arch/powerpc/boot/dts/xpedite5370.dts
+++ b/arch/powerpc/boot/dts/xpedite5370.dts
@@ -506,6 +506,7 @@
interrupts = <47 2>;
interrupt-parent = <&mpic>;
#gpio-cells = <2>;
+ fsl,gpio-mask = <0xf0>; /* 4 LEDs */
gpio-controller;
};
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index 103eace..2c07052 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -16,8 +16,6 @@
#include <linux/of_gpio.h>
#include <linux/gpio.h>
-#define MPC8XXX_GPIO_PINS 32
-
#define GPIO_DIR 0x00
#define GPIO_ODR 0x04
#define GPIO_DAT 0x08
@@ -34,11 +32,12 @@ struct mpc8xxx_gpio_chip {
* open drain mode safely
*/
u32 data;
+ u32 valid_pins; /* Bitmask of valid gpio pins */
};
static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
{
- return 1u << (MPC8XXX_GPIO_PINS - 1 - gpio);
+ return 0x80000000 >> gpio;
}
static inline struct mpc8xxx_gpio_chip *
@@ -111,12 +110,23 @@ static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val
return 0;
}
+static int mpc8xxx_gpio_request(struct gpio_chip *gc, unsigned int gpio) {
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
+
+ if (mpc8xxx_gc->valid_pins & (1 << gpio))
+ return 0;
+
+ return -1;
+}
+
static void __init mpc8xxx_add_controller(struct device_node *np)
{
struct mpc8xxx_gpio_chip *mpc8xxx_gc;
struct of_mm_gpio_chip *mm_gc;
struct of_gpio_chip *of_gc;
struct gpio_chip *gc;
+ const u32 *prop;
int ret;
mpc8xxx_gc = kzalloc(sizeof(*mpc8xxx_gc), GFP_KERNEL);
@@ -133,11 +143,17 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
mm_gc->save_regs = mpc8xxx_gpio_save_regs;
of_gc->gpio_cells = 2;
- gc->ngpio = MPC8XXX_GPIO_PINS;
+ prop = of_get_property(np, "fsl,gpio-mask", NULL);
+ if (prop)
+ mpc8xxx_gc->valid_pins = *prop;
+ else
+ mpc8xxx_gc->valid_pins = 0xffffffff;
+ gc->ngpio = fls(mpc8xxx_gc->valid_pins);
gc->direction_input = mpc8xxx_gpio_dir_in;
gc->direction_output = mpc8xxx_gpio_dir_out;
gc->get = mpc8xxx_gpio_get;
gc->set = mpc8xxx_gpio_set;
+ gc->request = mpc8xxx_gpio_request;
ret = of_mm_gpiochip_add(np, mm_gc);
if (ret)
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: Add PowerPC patterns
From: Grant Likely @ 2009-12-04 18:36 UTC (permalink / raw)
To: Josh Boyer
Cc: linuxppc-dev, LKML, Colin Leroy, Paul Mackerras, Joe Perches,
Jean Delvare, Darrick J. Wong
In-Reply-To: <20091204173902.GK2937@zod.rchland.ibm.com>
On Fri, Dec 4, 2009 at 10:39 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wr=
ote:
> On Fri, Dec 04, 2009 at 09:16:59AM -0800, Joe Perches wrote:
>> LINUX FOR POWERPC EMBEDDED PPC4XX
>> M: =A0 =A0Josh Boyer <jwboyer@linux.vnet.ibm.com>
>>@@ -3221,6 +3228,8 @@ W: =A0 =A0 =A0 http://www.penguinppc.org/
>> L: =A0 =A0linuxppc-dev@ozlabs.org
>> T: =A0 =A0git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powe=
rpc-4xx.git
>> S: =A0 =A0Maintained
>>+F: =A0 =A0arch/powerpc/platforms/40x/
>>+F: =A0 =A0arch/powerpc/platforms/44x/
>
> This is mostly complete. =A0There are a few files under arch/powerpc/sysd=
ev/, and
> arch/powerpc/boot/ as well, but I don't think they're entirely necessary.
>
> For the 4xx parts:
>
> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add PowerPC patterns
From: Josh Boyer @ 2009-12-04 17:39 UTC (permalink / raw)
To: Joe Perches
Cc: linuxppc-dev, LKML, Jean Delvare, Paul Mackerras, Colin Leroy,
Darrick J. Wong
In-Reply-To: <1259947019.22783.116.camel@Joe-Laptop.home>
On Fri, Dec 04, 2009 at 09:16:59AM -0800, Joe Perches wrote:
> LINUX FOR POWERPC EMBEDDED PPC4XX
> M: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>@@ -3221,6 +3228,8 @@ W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
> S: Maintained
>+F: arch/powerpc/platforms/40x/
>+F: arch/powerpc/platforms/44x/
This is mostly complete. There are a few files under arch/powerpc/sysdev/, and
arch/powerpc/boot/ as well, but I don't think they're entirely necessary.
For the 4xx parts:
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
^ permalink raw reply
* [PATCH] MAINTAINERS: Add PowerPC patterns
From: Joe Perches @ 2009-12-04 17:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, LKML, Colin Leroy, Paul Mackerras, Jean Delvare,
Darrick J. Wong
In-Reply-To: <1259920775.2076.1273.camel@pasglop>
On Fri, 2009-12-04 at 20:59 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2009-12-04 at 10:34 +0100, Jean Delvare wrote:
> > I've sent it to linuxppc-dev@ozlabs.org on October 14th. This is the
> > address which is listed 22 times in MAINTAINERS. If it isn't correct,
> > then please update MAINTAINERS.
> No it's fine both shoul work. Your patches are there, just waiting for
> me to pick them up, I was just firing a reminder to the rest of the CC
> list :-) (and I do remember fwd'ing a couple of your patches to the
> list, for some reason they didn't make it to patchwork back then, that
> was a few month ago).
> Anyways, I've been stretched thin with all sort of stuff lately, so bear
> with me if I'm a bit slow at taking or testing stuff, I'm doing my best.
Adding patterns to the PowerPC sections of MAINTAINERS is useful.
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 4f96ac8..c7f8e5a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3193,6 +3193,7 @@ LINUX FOR IBM pSERIES (RS/6000)
M: Paul Mackerras <paulus@au.ibm.com>
W: http://www.ibm.com/linux/ltc/projects/ppc
S: Supported
+F: arch/powerpc/boot/rs6000.h
LINUX FOR POWERPC (32-BIT AND 64-BIT)
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
@@ -3201,18 +3202,24 @@ W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
S: Supported
+F: Documentation/powerpc/
+F: arch/powerpc/
LINUX FOR POWER MACINTOSH
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
S: Maintained
+F: arch/powerpc/platforms/powermac/
+F: drivers/macintosh/
LINUX FOR POWERPC EMBEDDED MPC5XXX
M: Grant Likely <grant.likely@secretlab.ca>
L: linuxppc-dev@ozlabs.org
T: git git://git.secretlab.ca/git/linux-2.6.git
S: Maintained
+F: arch/powerpc/platforms/512x/
+F: arch/powerpc/platforms/52xx/
LINUX FOR POWERPC EMBEDDED PPC4XX
M: Josh Boyer <jwboyer@linux.vnet.ibm.com>
@@ -3221,6 +3228,8 @@ W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
S: Maintained
+F: arch/powerpc/platforms/40x/
+F: arch/powerpc/platforms/44x/
LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
M: Grant Likely <grant.likely@secretlab.ca>
@@ -3228,6 +3237,8 @@ W: http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
L: linuxppc-dev@ozlabs.org
T: git git://git.secretlab.ca/git/linux-2.6.git
S: Maintained
+F: arch/powerpc/*/*virtex*
+F: arch/powerpc/*/*/*virtex*
LINUX FOR POWERPC EMBEDDED PPC8XX
M: Vitaly Bordug <vitb@kernel.crashing.org>
@@ -3241,12 +3252,16 @@ M: Kumar Gala <galak@kernel.crashing.org>
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
S: Maintained
+F: arch/powerpc/platforms/83xx/
LINUX FOR POWERPC PA SEMI PWRFICIENT
M: Olof Johansson <olof@lixom.net>
W: http://www.pasemi.com/
L: linuxppc-dev@ozlabs.org
S: Supported
+F: arch/powerpc/platforms/pasemi/
+F: drivers/*/*pasemi*
+F: drivers/*/*/*pasemi*
LINUX SECURITY MODULE (LSM) FRAMEWORK
M: Chris Wright <chrisw@sous-sol.org>
^ permalink raw reply related
* Re: [RFC PATCH v2 1/6] powerpc: wii: device tree
From: Albert Herranz @ 2009-12-04 16:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <E340F52C-7795-4A0B-8286-C2B6028054CC@kernel.crashing.org>
Segher Boessenkool wrote:
>> Add a device tree source file for the Nintendo Wii video game console.
>>
>> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
>
> Great work Albert!
>
Thanks!
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH v4 2/2] powerpc: gamecube/wii: early debugging using usbgecko
From: Albert Herranz @ 2009-12-04 16:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <364F1867-9601-44FD-B140-EAA0FCC2C237@kernel.crashing.org>
Segher Boessenkool wrote:
>> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
>> +setup_usbgecko_bat:
>> + /* prepare a BAT for early io */
>> +#if defined(CONFIG_GAMECUBE)
>> + lis r8, 0x0c00
>> +#elif defined(CONFIG_WII)
>> + lis r8, 0x0d00
>> +#else
>> +#error Invalid platform for USB Gecko based early debugging.
>> +#endif
>
> A kernel with both CONFIG_WII and CONFIG_GAMECUBE works fine
> on either, right? If so, could you please switch the two #ifs?
> A dual-platform kernel will be used on a Wii much more likely
> than on a GC.
>
Nope, a GameCube kernel currently doesn't work on a Wii and the same the other way around.
But I can make that particular check a runtime check.
The idea would be to enclose that snippet in GAMECUBE_COMMON and check the PVR. If it is a Gekko (a fixed value) then we have a GameCube, otherwise we assume a Wii.
>> + /*
>> + * The virtual address used must match the virtual address
>> + * associated to the fixmap entry FIX_EARLY_DEBUG_BASE.
>> + */
>> + lis r11, 0xfffe /* top 128K */
>> + ori r8, r8, 0x002a /* uncached, guarded ,rw */
>> + ori r11, r11, 0x3 /* 128K */
>
> I think you should clear Vp since the BAT mapping can survive until
> after user space is started; it won't hurt to remove it either way.
> So 2 instead of 3. And put the meaning in the comment :-)
This BAT is re-setup again on MMU_init, way before starting userspace.
But I'll make it Vs=1, Vp=0 here too :)
>
> Looks fine otherwise.
>
Thanks.
>
> Segher
>
>
Cheers,
Albert
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Sean MacLennan @ 2009-12-04 16:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259925535.2076.1275.camel@pasglop>
On Fri, 04 Dec 2009 22:18:55 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Ok, I'll have a look next week. In the meantime, Sean, can you give
> me a hint of what you do to trigger it ? Boot time ? specific
> workload ?
It hasn't happened that often, but I have been focusing on 2.6.31.
So far, it has always happened well after the boot, but not hours. I
haven't worked out a specific workload.
Cheers,
Sean
^ permalink raw reply
* Re: [RFC PATCH v2 1/6] powerpc: wii: device tree
From: Segher Boessenkool @ 2009-12-04 15:25 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1259880447-5008-2-git-send-email-albert_herranz@yahoo.es>
> Add a device tree source file for the Nintendo Wii video game console.
>
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Great work Albert!
^ permalink raw reply
* Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2009-12-04 14:38 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi Ben,
A couple of DTS fixups for you. Thanks.
josh
The following changes since commit 5a7b4193e564d1611ecf1cd859aed60d5612d78f:
Benjamin Herrenschmidt (1):
Revert "powerpc/mm: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT"
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next
Curtis Wald (1):
powerpc/44x: Fix PCI node in Yosemite DTS
pbathija@amcc.com (1):
powerpc/44x: Fix DMA ranges in DTS file for Katmai board.
arch/powerpc/boot/dts/katmai.dts | 22 +++++++++++-----------
arch/powerpc/boot/dts/yosemite.dts | 14 ++------------
2 files changed, 13 insertions(+), 23 deletions(-)
^ permalink raw reply
* TQM5200 + SM501 FB
From: Rolf Offermanns @ 2009-12-04 14:23 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
does anyone has a working SM501 framebuffer on the STK5200 board? The
board itself works fine on the 2.6.32 kernel.
I got a patch from TQ which used to work around 2.6.24 but it seems with
the unification of the "simple mpc5200" boards the sm501 support got lost.
I toyed around with the patch a bit and I got the driver to probe and
initialize the chip, but I don't get an output on the crt port and an
open() on /dev/fb0 or /dev/fb1 fails with "no device".
Any hints are welcome.
Thanks,
Rolf.
^ permalink raw reply
* RE: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
From: Curtis Wald @ 2009-12-04 14:19 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20091204120744.GI2937@zod.rchland.ibm.com>
Josh,
Yes, the patch you provided below is exactly what is needed for PCI
functionality.
I've verified using a 2 port Silicon Image 3512 PCI to SATA controller
card on Yosemite.
-Curtis
> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]
> Sent: Friday, December 04, 2009 6:08 AM
> To: Curtis Wald
> Cc: mporter@kernel.crashing.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
>=20
> On Mon, Nov 30, 2009 at 09:25:51AM -0600, Curtis Wald wrote:
> >Josh,
> >Here is a resend of the Yosemite.dts patch, deleting tabs and spaces
> in
> >the IDSEL section that should look better when viewing as 80 column.
>=20
> Something is still eating your patches when you send them out. They
> get
> corrupted to the point of being unusable as you can see here:
>=20
> http://patchwork.ozlabs.org/patch/39810/
>=20
> However, your intentions are pretty clear. Could you look at the
patch
> below
> and see if it was what you intended? If so, I'll include it in my
> 'next'
> branch today.
>=20
> josh
>=20
> ---
>=20
> diff --git a/arch/powerpc/boot/dts/yosemite.dts
> b/arch/powerpc/boot/dts/yosemite.dts
> index 1fa3cb4..6492324 100644
> --- a/arch/powerpc/boot/dts/yosemite.dts
> +++ b/arch/powerpc/boot/dts/yosemite.dts
> @@ -282,20 +282,10 @@
> /* Inbound 2GB range starting at 0 */
> dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0 0x0
> 0x80000000>;
>=20
> - /* Bamboo has all 4 IRQ pins tied together per
slot
> */
> interrupt-map-mask =3D <0xf800 0x0 0x0 0x0>;
> interrupt-map =3D <
> - /* IDSEL 1 */
> - 0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
> -
> - /* IDSEL 2 */
> - 0x1000 0x0 0x0 0x0 &UIC0 0x1b 0x8
> -
> - /* IDSEL 3 */
> - 0x1800 0x0 0x0 0x0 &UIC0 0x1a 0x8
> -
> - /* IDSEL 4 */
> - 0x2000 0x0 0x0 0x0 &UIC0 0x19 0x8
> + /* IDSEL 12 */
> + 0x6000 0x0 0x0 0x0 &UIC0 0x19 0x8
> >;
> };
> };
^ permalink raw reply
* Re: using different format for hugetlbfs
From: Kumar Gala @ 2009-12-04 14:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc list, David Gibson
In-Reply-To: <1259917136.2076.1264.camel@pasglop>
On Dec 4, 2009, at 2:58 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-12-04 at 01:18 -0600, Kumar Gala wrote:
>> Ben, David,
>>
>> If we want to support true 4G/4G split on ppc32 using the MSB of the
>> address to determine of the pgd_t is for hugetlbfs isn't going to
>> work. Since every pointer in the pgd_t -> pud_t -> pmd_t is point to
>> at least a 4K page I would think the low order 12-bits should always
>> be 0.
>
> On 32 bit maybe. On 64, the pg/u/md's can be smaller. I don't really
> want to have a different encoding for both types though.
What do you mean they can be smaller? We have some scenario when we
dont allocate a full page? I agree having the encodings be different
would be bad. I'm trying to avoid having it be different between 32
bit and 64 (but maybe that will be impossible).
>> Could we use something like:
>>
>> addr[0:51] || shift [52:59] || flags [60:63]
>>
>> with the LSB flag being 'normal pointer' vs 'hugetlbfs mangled
>> pointer'. Seems like shift will at most be 64 so 8-bits should cover
>> it.
>
> Cheers,
> Ben.
>
- k
^ permalink raw reply
* Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
From: Josh Boyer @ 2009-12-04 12:07 UTC (permalink / raw)
To: Curtis Wald; +Cc: linuxppc-dev
In-Reply-To: <13F6A75BE29CE44F801B912901C3EF270233B6A4@wgv4.watchguardvideo.local>
On Mon, Nov 30, 2009 at 09:25:51AM -0600, Curtis Wald wrote:
>Josh,
>Here is a resend of the Yosemite.dts patch, deleting tabs and spaces in
>the IDSEL section that should look better when viewing as 80 column.
Something is still eating your patches when you send them out. They get
corrupted to the point of being unusable as you can see here:
http://patchwork.ozlabs.org/patch/39810/
However, your intentions are pretty clear. Could you look at the patch below
and see if it was what you intended? If so, I'll include it in my 'next'
branch today.
josh
---
diff --git a/arch/powerpc/boot/dts/yosemite.dts b/arch/powerpc/boot/dts/yosemite.dts
index 1fa3cb4..6492324 100644
--- a/arch/powerpc/boot/dts/yosemite.dts
+++ b/arch/powerpc/boot/dts/yosemite.dts
@@ -282,20 +282,10 @@
/* Inbound 2GB range starting at 0 */
dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
- /* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = <0xf800 0x0 0x0 0x0>;
interrupt-map = <
- /* IDSEL 1 */
- 0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
-
- /* IDSEL 2 */
- 0x1000 0x0 0x0 0x0 &UIC0 0x1b 0x8
-
- /* IDSEL 3 */
- 0x1800 0x0 0x0 0x0 &UIC0 0x1a 0x8
-
- /* IDSEL 4 */
- 0x2000 0x0 0x0 0x0 &UIC0 0x19 0x8
+ /* IDSEL 12 */
+ 0x6000 0x0 0x0 0x0 &UIC0 0x19 0x8
>;
};
};
^ permalink raw reply related
* Re: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT (v2)
From: Sachin Sant @ 2009-12-04 12:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Stephen Rothwell, David Gibson
In-Reply-To: <20091127045604.GE3184@yookeroo>
David Gibson wrote:
> Oops, stupid compile bug in the !CONFIG_PPC_SUBPAGE_PROT case with the
> last version. Fixed below.
>
> Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
>
> Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
> of kmem_caches for allocating various levels of pagetables.
> Unfortunately, it conflicts badly with CONFIG_PPC_SUBPAGE_PROT, due to
> the latter's cleverly hidden technique of adding some extra allocation
> space to the top level page directory to store the extra information
> it needs.
>
> Since that extra allocation really doesn't fit into the cleaned up
> page directory allocating scheme, this patch alters
> CONFIG_PPC_SUBPAGE_PROT to instead allocate its struct
> subpage_prot_table as part of the mm_context_t.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Ben,
Ping on this patch. It is still missing from linux-next.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [RFC PATCH v4 2/2] powerpc: gamecube/wii: early debugging using usbgecko
From: Segher Boessenkool @ 2009-12-04 12:04 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4f4baca1cd65f7949610ca901c9a8bcb1bb74cfd.1259871725.git.albert_herranz@yahoo.es>
> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
> +setup_usbgecko_bat:
> + /* prepare a BAT for early io */
> +#if defined(CONFIG_GAMECUBE)
> + lis r8, 0x0c00
> +#elif defined(CONFIG_WII)
> + lis r8, 0x0d00
> +#else
> +#error Invalid platform for USB Gecko based early debugging.
> +#endif
A kernel with both CONFIG_WII and CONFIG_GAMECUBE works fine
on either, right? If so, could you please switch the two #ifs?
A dual-platform kernel will be used on a Wii much more likely
than on a GC.
> + /*
> + * The virtual address used must match the virtual address
> + * associated to the fixmap entry FIX_EARLY_DEBUG_BASE.
> + */
> + lis r11, 0xfffe /* top 128K */
> + ori r8, r8, 0x002a /* uncached, guarded ,rw */
> + ori r11, r11, 0x3 /* 128K */
I think you should clear Vp since the BAT mapping can survive until
after user space is started; it won't hurt to remove it either way.
So 2 instead of 3. And put the meaning in the comment :-)
Looks fine otherwise.
Segher
^ permalink raw reply
* Git tags
From: Martyn Welch @ 2009-12-04 11:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Hi Ben,
Could you please pull the git tags from Linus' tree when you pull?
It aids a little in quickly seeing how far a tree on kernel has moved
forward, at the moment the last tag on your tree is "v2.6.26-rc9" [1].
Martyn
[1]
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/benh/powerpc.git;a=summary
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Benjamin Herrenschmidt @ 2009-12-04 11:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <20091204110055.GP14279@hansolo.jdub.homelinux.org>
On Fri, 2009-12-04 at 06:00 -0500, Josh Boyer wrote:
> On Fri, Dec 04, 2009 at 08:08:27PM +1100, Benjamin Herrenschmidt wrote:
> >On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
> >> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
> >> shown below. I believe these started in 2.6.32-rc8 or possibly
> >> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
> >> on that release, and not really testing the 2.6.32 stream.
> >>
> >> I wish I could give more info, but I don't really even have the time to
> >> write this email :( I am hoping somebody will have a eureka moment.
> >
> >That's a concern. Remind me what CPU / MMU type is Pika using ?
>
> 440EP
Ok, I'll have a look next week. In the meantime, Sean, can you give me a
hint of what you do to trigger it ? Boot time ? specific workload ?
Cheers,
Ben.
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Josh Boyer @ 2009-12-04 11:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <1259917707.2076.1271.camel@pasglop>
On Fri, Dec 04, 2009 at 08:08:27PM +1100, Benjamin Herrenschmidt wrote:
>On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
>> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
>> shown below. I believe these started in 2.6.32-rc8 or possibly
>> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
>> on that release, and not really testing the 2.6.32 stream.
>>
>> I wish I could give more info, but I don't really even have the time to
>> write this email :( I am hoping somebody will have a eureka moment.
>
>That's a concern. Remind me what CPU / MMU type is Pika using ?
440EP
josh
^ permalink raw reply
* Re: [v10 PATCH 8/9]: pSeries: implement pSeries processor idle module
From: Benjamin Herrenschmidt @ 2009-12-04 10:00 UTC (permalink / raw)
To: arun
Cc: linux-arch, Peter Zijlstra, linux-kernel, linux-acpi,
Venkatesh Pallipadi, Ingo Molnar, linuxppc-dev
In-Reply-To: <20091204081539.GA5883@linux.vnet.ibm.com>
On Fri, 2009-12-04 at 13:45 +0530, Arun R Bharadwaj wrote:
>
> Hi Ben,
>
> I forgot to attach the patch which enables cpuidle for the rest of the
> POWER platforms. Attaching it below.
>
> So for these platforms, ppc_md.power_save will be called from from the
> cpuidle_idle_call idle loop itself. Also, this cpuidle_idle_call is
> not a pseries specific idle loop. It is a common loop for Intel and
> PPC which use cpuidle infrastructure.
Ok, so there was a missing piece in the puzzle ;-)
I'll review asap.
Cheers,
Ben.
> arun
>
>
>
> This patch enables cpuidle for the rest of the POWER platforms like
> 44x, Cell, Pasemi etc.
>
> Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/system.h | 2 ++
> arch/powerpc/kernel/idle.c | 28 ++++++++++++++++++++++++++++
> arch/powerpc/kernel/setup_32.c | 8 ++++++--
> arch/powerpc/platforms/44x/idle.c | 2 ++
> arch/powerpc/platforms/cell/pervasive.c | 2 ++
> arch/powerpc/platforms/pasemi/idle.c | 2 ++
> arch/powerpc/platforms/ps3/setup.c | 2 ++
> 7 files changed, 44 insertions(+), 2 deletions(-)
>
> Index: linux.trees.git/arch/powerpc/include/asm/system.h
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/include/asm/system.h
> +++ linux.trees.git/arch/powerpc/include/asm/system.h
> @@ -551,8 +551,10 @@ void cpu_idle_wait(void);
>
> #ifdef CONFIG_CPU_IDLE
> extern void update_smt_snooze_delay(int snooze);
> +extern void setup_cpuidle_ppc(void);
> #else
> static inline void update_smt_snooze_delay(int snooze) {}
> +static inline void setup_cpuidle_ppc(void) {}
> #endif
>
> #endif /* __KERNEL__ */
> Index: linux.trees.git/arch/powerpc/kernel/idle.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/kernel/idle.c
> +++ linux.trees.git/arch/powerpc/kernel/idle.c
> @@ -129,6 +129,34 @@ void default_idle(void)
> HMT_very_low();
> }
>
> +#ifdef CONFIG_CPU_IDLE
> +DEFINE_PER_CPU(struct cpuidle_device, ppc_idle_devices);
> +struct cpuidle_driver cpuidle_ppc_driver = {
> + .name = "cpuidle_ppc",
> +};
> +
> +static void ppc_idle_loop(struct cpuidle_device *dev, struct cpuidle_state *st)
> +{
> + ppc_md.power_save();
> +}
> +
> +void setup_cpuidle_ppc(void)
> +{
> + struct cpuidle_device *dev;
> + int cpu;
> +
> + cpuidle_register_driver(&cpuidle_ppc_driver);
> +
> + for_each_online_cpu(cpu) {
> + dev = &per_cpu(ppc_idle_devices, cpu);
> + dev->cpu = cpu;
> + dev->states[0].enter = ppc_idle_loop;
> + dev->state_count = 1;
> + cpuidle_register_device(dev);
> + }
> +}
> +#endif
> +
> int powersave_nap;
>
> #ifdef CONFIG_SYSCTL
> Index: linux.trees.git/arch/powerpc/kernel/setup_32.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/kernel/setup_32.c
> +++ linux.trees.git/arch/powerpc/kernel/setup_32.c
> @@ -133,14 +133,18 @@ notrace void __init machine_init(unsigne
>
> #ifdef CONFIG_6xx
> if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
> - cpu_has_feature(CPU_FTR_CAN_NAP))
> + cpu_has_feature(CPU_FTR_CAN_NAP)) {
> ppc_md.power_save = ppc6xx_idle;
> + setup_cpuidle_ppc();
> + }
> #endif
>
> #ifdef CONFIG_E500
> if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
> - cpu_has_feature(CPU_FTR_CAN_NAP))
> + cpu_has_feature(CPU_FTR_CAN_NAP)) {
> ppc_md.power_save = e500_idle;
> + setup_cpuidle_ppc();
> + }
> #endif
> if (ppc_md.progress)
> ppc_md.progress("id mach(): done", 0x200);
> Index: linux.trees.git/arch/powerpc/platforms/44x/idle.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/44x/idle.c
> +++ linux.trees.git/arch/powerpc/platforms/44x/idle.c
> @@ -24,6 +24,7 @@
> #include <linux/of.h>
> #include <linux/kernel.h>
> #include <asm/machdep.h>
> +#include <asm/system.h>
>
> static int mode_spin;
>
> @@ -46,6 +47,7 @@ int __init ppc44x_idle_init(void)
> /* If we are not setting spin mode
> then we set to wait mode */
> ppc_md.power_save = &ppc44x_idle;
> + setup_cpuidle_ppc();
> }
>
> return 0;
> Index: linux.trees.git/arch/powerpc/platforms/cell/pervasive.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/cell/pervasive.c
> +++ linux.trees.git/arch/powerpc/platforms/cell/pervasive.c
> @@ -35,6 +35,7 @@
> #include <asm/pgtable.h>
> #include <asm/reg.h>
> #include <asm/cell-regs.h>
> +#include <asm/system.h>
>
> #include "pervasive.h"
>
> @@ -128,5 +129,6 @@ void __init cbe_pervasive_init(void)
> }
>
> ppc_md.power_save = cbe_power_save;
> + setup_cpuidle_ppc();
> ppc_md.system_reset_exception = cbe_system_reset_exception;
> }
> Index: linux.trees.git/arch/powerpc/platforms/pasemi/idle.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/pasemi/idle.c
> +++ linux.trees.git/arch/powerpc/platforms/pasemi/idle.c
> @@ -27,6 +27,7 @@
> #include <asm/machdep.h>
> #include <asm/reg.h>
> #include <asm/smp.h>
> +#include <asm/system.h>
>
> #include "pasemi.h"
>
> @@ -81,6 +82,7 @@ static int __init pasemi_idle_init(void)
>
> ppc_md.system_reset_exception = pasemi_system_reset_exception;
> ppc_md.power_save = modes[current_mode].entry;
> + setup_cpuidle_ppc();
> printk(KERN_INFO "Using PA6T idle loop (%s)\n", modes[current_mode].name);
>
> return 0;
> Index: linux.trees.git/arch/powerpc/platforms/ps3/setup.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/ps3/setup.c
> +++ linux.trees.git/arch/powerpc/platforms/ps3/setup.c
> @@ -33,6 +33,7 @@
> #include <asm/prom.h>
> #include <asm/lv1call.h>
> #include <asm/ps3gpu.h>
> +#include <asm/system.h>
>
> #include "platform.h"
>
> @@ -214,6 +215,7 @@ static void __init ps3_setup_arch(void)
> prealloc_ps3flash_bounce_buffer();
>
> ppc_md.power_save = ps3_power_save;
> + setup_cpuidle_ppc();
> ps3_os_area_init();
>
> DBG(" <- %s:%d\n", __func__, __LINE__);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Benjamin Herrenschmidt @ 2009-12-04 9:08 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20091203141853.3eafba47@lappy.seanm.ca>
On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
> shown below. I believe these started in 2.6.32-rc8 or possibly
> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
> on that release, and not really testing the 2.6.32 stream.
>
> I wish I could give more info, but I don't really even have the time to
> write this email :( I am hoping somebody will have a eureka moment.
That's a concern. Remind me what CPU / MMU type is Pika using ?
Cheers,
Ben.
> Cheers,
> Sean
>
>
> [ 147.410448] BUG: Bad page map in process udevd pte:ffffffffffffffff pmd:cd883000
> [ 147.417989] addr:48003000 vm_flags:08000875 anon_vma:(null) mapping:cf4150ac index:3
> [ 147.425837] vma->vm_ops->fault: filemap_fault+0x0/0x410
> [ 147.431101] vma->vm_file->f_op->mmap: nfs_file_mmap+0x0/0x94
> [ 147.436795] Call Trace:
> [ 147.439268] [cf2dbd80] [c00065a4] show_stack+0x48/0x168 (unreliable)
> [ 147.445708] [cf2dbdb0] [c0064ac8] print_bad_pte+0x14c/0x204
> [ 147.451337] [cf2dbde0] [c0064cd4] vm_normal_page+0x90/0x98
> [ 147.456875] [cf2dbdf0] [c0064ee8] unmap_vmas+0x20c/0x638
> [ 147.462239] [cf2dbe80] [c0069194] exit_mmap+0xc8/0x170
> [ 147.467441] [cf2dbea0] [c001caa4] mmput+0x50/0xf4
> [ 147.472195] [cf2dbeb0] [c0020808] exit_mm+0x100/0x138
> [ 147.477299] [cf2dbee0] [c00211b0] do_exit+0xb0/0x580
> [ 147.482315] [cf2dbf20] [c00216c4] do_group_exit+0x44/0x9c
> [ 147.487766] [cf2dbf30] [c0021730] sys_exit_group+0x14/0x28
> [ 147.493308] [cf2dbf40] [c000dde4] ret_from_syscall+0x0/0x3c
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PCI interrupt question
From: Benjamin Herrenschmidt @ 2009-12-04 9:05 UTC (permalink / raw)
To: David Hawkins; +Cc: Jeff Hane, linuxppc-dev@ozlabs.org
In-Reply-To: <4B1816F9.1020601@ovro.caltech.edu>
On Thu, 2009-12-03 at 11:52 -0800, David Hawkins wrote:
>
> Really? I thought the pci_dev structures represent the
> devices found on the PCI bus, and the IRQ line in
> that structure was merely copied from the configuration
> space registers.
No, it's not. In fact it's mostly irrelevant. It has room for only 8
bits and we commonly manipulate a lot more interrupts on some modern
systems.
Linux will obtain from the device-tree the routing for the interrupt
line(s) of the device. If you don't have a node for the device (which is
allowed for PCI), linux will use the INTERRUPT_PIN register to query
which interrupt line is the device output, and will use the host bridge
device-tree node "interrupt-map" property to find where it's connected
to on the PIC.
It will then map that to a linux virtual IRQ number which is what you
find in pci_dev. At least that's how it works on powerpc :-)
> When you request that interrupt, the
> code would have to remap it to a host IRQ line, which
> it would use the DTS for. (But I'm just speculating).
No, it's already remapped in pci_dev. The mapping happen when the PCI
devices are discovered by the kernel.
> Bottom line is; if the IRQ field of lspci is 0, then you
> need to figure out that problem first :)
I wouldn't trust lspci too much, I'm not sure we bother writing back the
number to the PCI_INTERRUPT_LINE register anymore anyways.
If your pci_dev->irq is non-0 then Linux found -something- but it might
not be right, it depends on your device-tree.
Cheers,
Ben.
^ permalink raw reply
* Re: PCI interrupt question
From: Benjamin Herrenschmidt @ 2009-12-04 9:02 UTC (permalink / raw)
To: Jeff Hane; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1259869140.18190.52.camel@qu102.quarc.com>
> So are you saying linux should be writing the irq number to the
> INTERRUPT_LINE config reg? This is what I expected but I do not see
> it.
No it won't necessarily touch it, this is not terribly useful anyways.
Linux will assign an interrupt based on the informations from the
device-tree and you should be able to retrieve it in pci_dev->irq.
> I believe the DTS is being parsed properly and the connection is made
> to the correct interrupt line on the device. But somebody still needs
> to assign and IRQ number, right?
What do you mean ? If the connection is made properly, the code will
obtain an HW IRQ input number on the UIC and will map it to a linux
virtual IRQ number which you can find in pci_dev->irq.
> This is the part that is not clear,
> there is an irq field in pci_dev structure which is filled in after
> looking at the DTS and I just want to be sure this is the irq number to
> be used when calling request_irq.
Yes, it is.
If things don't work, it's possible that you assigned the wrong number
in the device-tree ?
Cheers,
Ben.
> thanks,
> jeff
>
>
>
> > These comments might not be 100% correct, but the list of things
> > to check should be close enough for you to track down your
> > problem.
> >
> > Cheers,
> > Dave
> >
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: using different format for hugetlbfs
From: Benjamin Herrenschmidt @ 2009-12-04 8:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc list, David Gibson
In-Reply-To: <230774E3-2D94-44DA-85AC-151485996789@kernel.crashing.org>
On Fri, 2009-12-04 at 01:18 -0600, Kumar Gala wrote:
> Ben, David,
>
> If we want to support true 4G/4G split on ppc32 using the MSB of the
> address to determine of the pgd_t is for hugetlbfs isn't going to
> work. Since every pointer in the pgd_t -> pud_t -> pmd_t is point to
> at least a 4K page I would think the low order 12-bits should always
> be 0.
On 32 bit maybe. On 64, the pg/u/md's can be smaller. I don't really
want to have a different encoding for both types though.
> Could we use something like:
>
> addr[0:51] || shift [52:59] || flags [60:63]
>
> with the LSB flag being 'normal pointer' vs 'hugetlbfs mangled
> pointer'. Seems like shift will at most be 64 so 8-bits should cover
> it.
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox