* Re: [RFC] [PATCH] hvc_console: improve tty/console put_chars handling
From: Anton Blanchard @ 2011-07-06 7:49 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: Tabi Timur-B04825, linuxppc-dev@lists.ozlabs.org,
borntraeger@de.ibm.com
In-Reply-To: <20110705142844.GA2514@linux.vnet.ibm.com>
Hi Hendrik,
> So with the patch below, the backend can now indirectly control the
> way console output is handled for it. I still have to think if this
> solution is ok or if it is better to introduce a new callback to
> console output only (and might provide a default implemenatation
> similar to the patch below).
>
> NOTE: I did not yet test this patch but will do.. I just want to
> share it early to get feedback from you.
Thanks a lot for this. I added the pseries bits and tested it, patches
to follow.
Anton
^ permalink raw reply
* [PATCH 1/2]: hvc_console: improve tty/console put_chars handling
From: Anton Blanchard @ 2011-07-06 7:50 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: Tabi Timur-B04825, linuxppc-dev@lists.ozlabs.org,
borntraeger@de.ibm.com
In-Reply-To: <20110705142844.GA2514@linux.vnet.ibm.com>
From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Currently, the hvc_console_print() function drops console output if the
hvc backend's put_chars() returns 0. This patch changes this behavior
to allow a retry through returning -EAGAIN.
This change also affects the hvc_push() function. Both functions are
changed to handle -EAGAIN and to retry the put_chars() operation.
If a hvc backend returns -EAGAIN, the retry handling differs:
- hvc_console_print() spins to write the complete console output.
- hvc_push() behaves the same way as for returning 0.
Now hvc backends can indirectly control the way how console output is
handled through the hvc console layer.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
---
Index: linux-powerpc/drivers/tty/hvc/hvc_console.c
===================================================================
--- linux-powerpc.orig/drivers/tty/hvc/hvc_console.c 2011-07-06 17:10:51.288360541 +1000
+++ linux-powerpc/drivers/tty/hvc/hvc_console.c 2011-07-06 17:11:16.398794913 +1000
@@ -163,8 +163,10 @@ static void hvc_console_print(struct con
} else {
r = cons_ops[index]->put_chars(vtermnos[index], c, i);
if (r <= 0) {
- /* throw away chars on error */
- i = 0;
+ /* throw away characters on error
+ * but spin in case of -EAGAIN */
+ if (r != -EAGAIN)
+ i = 0;
} else if (r > 0) {
i -= r;
if (i > 0)
@@ -448,7 +450,7 @@ static int hvc_push(struct hvc_struct *h
n = hp->ops->put_chars(hp->vtermno, hp->outbuf, hp->n_outbuf);
if (n <= 0) {
- if (n == 0) {
+ if (n == 0 || n == -EAGAIN) {
hp->do_wakeup = 1;
return 0;
}
^ permalink raw reply
* [PATCH 2/2]: powerpc/pseries/hvconsole: Fix dropped console output
From: Anton Blanchard @ 2011-07-06 7:51 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: Tabi Timur-B04825, linuxppc-dev@lists.ozlabs.org,
borntraeger@de.ibm.com
In-Reply-To: <20110705142844.GA2514@linux.vnet.ibm.com>
Return -EAGAIN when we get H_BUSY back from the hypervisor. This
makes the hvc console driver retry, avoiding dropped printks.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
---
Index: linux-powerpc/arch/powerpc/platforms/pseries/hvconsole.c
===================================================================
--- linux-powerpc.orig/arch/powerpc/platforms/pseries/hvconsole.c 2011-07-06 17:11:33.799095935 +1000
+++ linux-powerpc/arch/powerpc/platforms/pseries/hvconsole.c 2011-07-06 17:11:47.499332962 +1000
@@ -73,7 +73,7 @@ int hvc_put_chars(uint32_t vtermno, cons
if (ret == H_SUCCESS)
return count;
if (ret == H_BUSY)
- return 0;
+ return -EAGAIN;
return -EIO;
}
^ permalink raw reply
* Re: [PATCH] powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
From: Anton Blanchard @ 2011-07-06 7:55 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <29259.1309848010@neuling.org>
On Tue, 05 Jul 2011 16:40:10 +1000
Michael Neuling <mikey@neuling.org> wrote:
> The existing code it pretty ugly. How about we clean it up even more
> like this?
Looks good and it passed my kdump test cases.
Anton
> From: Anton Blanchard <anton@samba.org>
>
> We check for timeout expiry in the outer loop, but we also need to
> check it in the inner loop or we can lock up forever waiting for a
> CPU to hit real mode.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Cc: <stable@kernel.org>
>
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index 4e6ee94..cc6a9d5 100644
> --- a/arch/powerpc/kernel/crash.c
> +++ b/arch/powerpc/kernel/crash.c
> @@ -242,12 +242,8 @@ static void crash_kexec_wait_realmode(int cpu)
>
> while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) {
> barrier();
> - if (!cpu_possible(i)) {
> + if (!cpu_possible(i) || !cpu_online(i) ||
> (msecs <= 0)) break;
> - }
> - if (!cpu_online(i)) {
> - break;
> - }
> msecs--;
> mdelay(1);
> }
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/5200: mpc5200b.dtsi: add spi node address- and size-cells properties
From: Anatolij Gustschin @ 2011-07-06 9:43 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <1305561764-5942-1-git-send-email-agust@denx.de>
Hi Grant,
can you please pick these patches for 3.1 ?
On Mon, 16 May 2011 18:02:43 +0200
Anatolij Gustschin <agust@denx.de> wrote:
> Both, #address-cells and #size-cells properties are required
> for spi bus node, so add them.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/boot/dts/mpc5200b.dtsi | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc5200b.dtsi b/arch/powerpc/boot/dts/mpc5200b.dtsi
> index bc27548..7ab286a 100644
> --- a/arch/powerpc/boot/dts/mpc5200b.dtsi
> +++ b/arch/powerpc/boot/dts/mpc5200b.dtsi
> @@ -147,6 +147,8 @@
> };
>
> spi@f00 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
> reg = <0xf00 0x20>;
> interrupts = <2 13 0 2 14 0>;
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/5200: dts: digsy_mtc.dts: add timer0 and timer1 gpio properties
From: Anatolij Gustschin @ 2011-07-06 9:46 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev
In-Reply-To: <1307399225-15882-1-git-send-email-agust@denx.de>
Hi Grant,
Can you please pick this patch for 3.1 ?
On Tue, 7 Jun 2011 00:27:05 +0200
Anatolij Gustschin <agust@denx.de> wrote:
> timer0 and timer1 pins are used as simple GPIO on this board.
> Add gpio-controller and #gpio-cells properties to timer nodes
> so that we can control gpio lines using available MPC52xx
> GPT driver.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/boot/dts/digsy_mtc.dts | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts
> index e205d17..2aad7ae 100644
> --- a/arch/powerpc/boot/dts/digsy_mtc.dts
> +++ b/arch/powerpc/boot/dts/digsy_mtc.dts
> @@ -23,7 +23,14 @@
>
> soc5200@f0000000 {
> timer@600 { // General Purpose Timer
> + #gpio-cells = <2>;
> fsl,has-wdt;
> + gpio-controller;
> + };
> +
> + timer@610 {
> + #gpio-cells = <2>;
> + gpio-controller;
> };
>
> rtc@800 {
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/5200: add GPIO functions for simple interrupt GPIOs
From: Anatolij Gustschin @ 2011-07-06 9:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <1306142730-7528-1-git-send-email-agust@denx.de>
Hi Grant,
Ping.
On Mon, 23 May 2011 11:25:30 +0200
Anatolij Gustschin <agust@denx.de> wrote:
> The mpc52xx_gpio driver currently supports 8 wakeup GPIOs and 32
> simple GPIOs. Extend it to also support GPIO function of 8 simple
> interrupt GPIOs controlled in the standard GPIO register module.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 117 ++++++++++++++++++++++++++++
> 1 files changed, 117 insertions(+), 0 deletions(-)
...
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/5200: dts: digsy_mtc.dts: add timer0 and timer1 gpio properties
From: Grant Likely @ 2011-07-06 17:16 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20110706114627.56388c2e@wker>
On Wed, Jul 06, 2011 at 11:46:27AM +0200, Anatolij Gustschin wrote:
> Hi Grant,
>
> Can you please pick this patch for 3.1 ?
>
> On Tue, 7 Jun 2011 00:27:05 +0200
> Anatolij Gustschin <agust@denx.de> wrote:
>
> > timer0 and timer1 pins are used as simple GPIO on this board.
> > Add gpio-controller and #gpio-cells properties to timer nodes
> > so that we can control gpio lines using available MPC52xx
> > GPT driver.
> >
> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
Merged, thanks.
g.
> > ---
> > arch/powerpc/boot/dts/digsy_mtc.dts | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts
> > index e205d17..2aad7ae 100644
> > --- a/arch/powerpc/boot/dts/digsy_mtc.dts
> > +++ b/arch/powerpc/boot/dts/digsy_mtc.dts
> > @@ -23,7 +23,14 @@
> >
> > soc5200@f0000000 {
> > timer@600 { // General Purpose Timer
> > + #gpio-cells = <2>;
> > fsl,has-wdt;
> > + gpio-controller;
> > + };
> > +
> > + timer@610 {
> > + #gpio-cells = <2>;
> > + gpio-controller;
> > };
> >
> > rtc@800 {
>
>
> Thanks,
> Anatolij
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/5200: mpc5200b.dtsi: add spi node address- and size-cells properties
From: Grant Likely @ 2011-07-06 17:27 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110706114319.17af93a3@wker>
On Wed, Jul 06, 2011 at 11:43:19AM +0200, Anatolij Gustschin wrote:
> Hi Grant,
>
> can you please pick these patches for 3.1 ?
>
> On Mon, 16 May 2011 18:02:43 +0200
> Anatolij Gustschin <agust@denx.de> wrote:
>
> > Both, #address-cells and #size-cells properties are required
> > for spi bus node, so add them.
> >
> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
Merged, thanks.
g.
> > ---
> > arch/powerpc/boot/dts/mpc5200b.dtsi | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc5200b.dtsi b/arch/powerpc/boot/dts/mpc5200b.dtsi
> > index bc27548..7ab286a 100644
> > --- a/arch/powerpc/boot/dts/mpc5200b.dtsi
> > +++ b/arch/powerpc/boot/dts/mpc5200b.dtsi
> > @@ -147,6 +147,8 @@
> > };
> >
> > spi@f00 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
> > reg = <0xf00 0x20>;
> > interrupts = <2 13 0 2 14 0>;
>
> Thanks,
> Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/5200: add GPIO functions for simple interrupt GPIOs
From: Grant Likely @ 2011-07-06 17:52 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <1306142730-7528-1-git-send-email-agust@denx.de>
On Mon, May 23, 2011 at 11:25:30AM +0200, Anatolij Gustschin wrote:
> The mpc52xx_gpio driver currently supports 8 wakeup GPIOs and 32
> simple GPIOs. Extend it to also support GPIO function of 8 simple
> interrupt GPIOs controlled in the standard GPIO register module.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 117 ++++++++++++++++++++++++++++
I don't want to merge more open coded MMIO gpio driver code. This whole driver really needs to be converted to use GENERIC_GPIO.
g.
> 1 files changed, 117 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> index 1757d1d..42a0759 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> @@ -35,6 +35,9 @@ struct mpc52xx_gpiochip {
> unsigned int shadow_dvo;
> unsigned int shadow_gpioe;
> unsigned int shadow_ddr;
> + unsigned char sint_shadow_dvo;
> + unsigned char sint_shadow_gpioe;
> + unsigned char sint_shadow_ddr;
> };
>
> /*
> @@ -309,6 +312,100 @@ mpc52xx_simple_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> return 0;
> }
>
> +static int mpc52xx_sint_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct mpc52xx_gpio __iomem *regs = mm_gc->regs;
> + unsigned int ret;
> +
> + ret = (in_8(®s->sint_ival) >> (7 - gpio)) & 1;
> +
> + pr_debug("%s: gpio: %d ret: %d\n", __func__, gpio, ret);
> +
> + return ret;
> +}
> +
> +static inline void
> +__mpc52xx_sint_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct mpc52xx_gpiochip *chip = container_of(mm_gc,
> + struct mpc52xx_gpiochip, mmchip);
> + struct mpc52xx_gpio __iomem *regs = mm_gc->regs;
> +
> + if (val)
> + chip->sint_shadow_dvo |= 1 << (7 - gpio);
> + else
> + chip->sint_shadow_dvo &= ~(1 << (7 - gpio));
> +
> + out_8(®s->sint_dvo, chip->sint_shadow_dvo);
> +}
> +
> +static void
> +mpc52xx_sint_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&gpio_lock, flags);
> +
> + __mpc52xx_sint_gpio_set(gc, gpio, val);
> +
> + spin_unlock_irqrestore(&gpio_lock, flags);
> +
> + pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
> +}
> +
> +static int mpc52xx_sint_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct mpc52xx_gpiochip *chip = container_of(mm_gc,
> + struct mpc52xx_gpiochip, mmchip);
> + struct mpc52xx_gpio __iomem *regs = mm_gc->regs;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&gpio_lock, flags);
> +
> + /* set the direction */
> + chip->sint_shadow_ddr &= ~(1 << (7 - gpio));
> + out_8(®s->sint_ddr, chip->sint_shadow_ddr);
> +
> + /* and enable the pin */
> + chip->sint_shadow_gpioe |= 1 << (7 - gpio);
> + out_8(®s->sint_gpioe, chip->sint_shadow_gpioe);
> +
> + spin_unlock_irqrestore(&gpio_lock, flags);
> +
> + return 0;
> +}
> +
> +static int
> +mpc52xx_sint_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct mpc52xx_gpio __iomem *regs = mm_gc->regs;
> + struct mpc52xx_gpiochip *chip = container_of(mm_gc,
> + struct mpc52xx_gpiochip, mmchip);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&gpio_lock, flags);
> +
> + __mpc52xx_sint_gpio_set(gc, gpio, val);
> +
> + /* Then set direction */
> + chip->sint_shadow_ddr |= 1 << (7 - gpio);
> + out_8(®s->sint_ddr, chip->sint_shadow_ddr);
> +
> + /* Finally enable the pin */
> + chip->sint_shadow_gpioe |= 1 << (7 - gpio);
> + out_8(®s->sint_gpioe, chip->sint_shadow_gpioe);
> +
> + spin_unlock_irqrestore(&gpio_lock, flags);
> +
> + pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
> +
> + return 0;
> +}
> +
> static int __devinit mpc52xx_simple_gpiochip_probe(struct platform_device *ofdev)
> {
> struct mpc52xx_gpiochip *chip;
> @@ -337,6 +434,26 @@ static int __devinit mpc52xx_simple_gpiochip_probe(struct platform_device *ofdev
> chip->shadow_ddr = in_be32(®s->simple_ddr);
> chip->shadow_dvo = in_be32(®s->simple_dvo);
>
> + chip = kzalloc(sizeof(*chip), GFP_KERNEL);
> + if (!chip)
> + return -ENOMEM;
> +
> + gc = &chip->mmchip.gc;
> +
> + gc->ngpio = 8;
> + gc->direction_input = mpc52xx_sint_gpio_dir_in;
> + gc->direction_output = mpc52xx_sint_gpio_dir_out;
> + gc->get = mpc52xx_sint_gpio_get;
> + gc->set = mpc52xx_sint_gpio_set;
> +
> + ret = of_mm_gpiochip_add(ofdev->dev.of_node, &chip->mmchip);
> + if (ret)
> + return ret;
> +
> + regs = chip->mmchip.regs;
> + chip->sint_shadow_gpioe = in_8(®s->sint_gpioe);
> + chip->sint_shadow_ddr = in_8(®s->sint_ddr);
> + chip->sint_shadow_dvo = in_8(®s->sint_dvo);
> return 0;
> }
>
> --
> 1.7.1
>
^ permalink raw reply
* [PATCH] gpio: Move mpc5200 gpio driver to drivers/gpio
From: Grant Likely @ 2011-07-06 18:01 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
GPIO drivers are getting consolidated into drivers/gpio. While at it,
change the driver name to mpc5200-gpio* to avoid collisions.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Ben, I'm going to take this via the gpio/next branch to avoid
conflicts with the big gpio rename.
g.
arch/powerpc/platforms/52xx/Kconfig | 8 --------
arch/powerpc/platforms/52xx/Makefile | 1 -
drivers/gpio/Kconfig | 4 ++++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-mpc5200.c | 12 ++++--------
5 files changed, 9 insertions(+), 17 deletions(-)
rename arch/powerpc/platforms/52xx/mpc52xx_gpio.c => drivers/gpio/gpio-mpc5200.c (98%)
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 47ea1be..90f4496 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -55,14 +55,6 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
-config PPC_MPC5200_GPIO
- bool "MPC5200 GPIO support"
- depends on PPC_MPC52xx
- select ARCH_REQUIRE_GPIOLIB
- select GENERIC_GPIO
- help
- Enable gpiolib support for mpc5200 based boards
-
config PPC_MPC5200_LPBFIFO
tristate "MPC5200 LocalPlus bus FIFO driver"
depends on PPC_MPC52xx
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index 2bc8cd0..4e62486 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -14,5 +14,4 @@ ifeq ($(CONFIG_PPC_LITE5200),y)
obj-$(CONFIG_PM) += lite5200_sleep.o lite5200_pm.o
endif
-obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o
obj-$(CONFIG_PPC_MPC5200_LPBFIFO) += mpc52xx_lpbfifo.o
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index a4ac78b..47eae6e 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -99,6 +99,10 @@ config GPIO_EXYNOS4
def_bool y
depends on CPU_EXYNOS4210
+config GPIO_MPC5200
+ def_bool y
+ depends on PPC_MPC52xx
+
config GPIO_MXC
def_bool y
depends on ARCH_MXC
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index b847fb5..7207112 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_GPIO_MAX732X) += gpio-max732x.o
obj-$(CONFIG_GPIO_MC33880) += gpio-mc33880.o
obj-$(CONFIG_GPIO_MCP23S08) += gpio-mcp23s08.o
obj-$(CONFIG_GPIO_ML_IOH) += gpio-ml-ioh.o
+obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MXC) += gpio-mxc.o
obj-$(CONFIG_GPIO_MXS) += gpio-mxs.o
obj-$(CONFIG_PLAT_NOMADIK) += gpio-nomadik.o
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c b/drivers/gpio/gpio-mpc5200.c
similarity index 98%
rename from arch/powerpc/platforms/52xx/mpc52xx_gpio.c
rename to drivers/gpio/gpio-mpc5200.c
index 1757d1d..9b325dd 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/drivers/gpio/gpio-mpc5200.c
@@ -184,15 +184,13 @@ static int mpc52xx_gpiochip_remove(struct platform_device *ofdev)
}
static const struct of_device_id mpc52xx_wkup_gpiochip_match[] = {
- {
- .compatible = "fsl,mpc5200-gpio-wkup",
- },
+ { .compatible = "fsl,mpc5200-gpio-wkup", },
{}
};
static struct platform_driver mpc52xx_wkup_gpiochip_driver = {
.driver = {
- .name = "gpio_wkup",
+ .name = "mpc5200-gpio-wkup",
.owner = THIS_MODULE,
.of_match_table = mpc52xx_wkup_gpiochip_match,
},
@@ -341,15 +339,13 @@ static int __devinit mpc52xx_simple_gpiochip_probe(struct platform_device *ofdev
}
static const struct of_device_id mpc52xx_simple_gpiochip_match[] = {
- {
- .compatible = "fsl,mpc5200-gpio",
- },
+ { .compatible = "fsl,mpc5200-gpio", },
{}
};
static struct platform_driver mpc52xx_simple_gpiochip_driver = {
.driver = {
- .name = "gpio",
+ .name = "gpio-mpc5200",
.owner = THIS_MODULE,
.of_match_table = mpc52xx_simple_gpiochip_match,
},
^ permalink raw reply related
* [PATCH 0/4] Some defconfig updates
From: Anton Blanchard @ 2011-07-06 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Here are a few defconfig updates I had lying around in my tree.
Anton
^ permalink raw reply
* [PATCH 1/4] powerpc: Sync pseries and ppc64 defconfigs
From: Anton Blanchard @ 2011-07-06 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110706231313.260037641@samba.org>
The pseries defconfig had a number of drivers enabled and we may
as well add them to the ppc64 defconfig.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-powerpc.orig/arch/powerpc/configs/ppc64_defconfig 2011-07-05 15:05:59.903893167 +1000
+++ linux-powerpc/arch/powerpc/configs/ppc64_defconfig 2011-07-07 09:07:26.482898262 +1000
@@ -176,12 +176,18 @@ CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_FC_ATTRS=y
+CONFIG_SCSI_SAS_ATTRS=m
+CONFIG_SCSI_CXGB3_ISCSI=m
+CONFIG_SCSI_CXGB4_ISCSI=m
+CONFIG_SCSI_BNX2_ISCSI=m
+CONFIG_BE2ISCSI=m
CONFIG_SCSI_IBMVSCSI=y
CONFIG_SCSI_IBMVFC=m
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_IPR=y
CONFIG_SCSI_QLA_FC=m
+CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
CONFIG_ATA=y
CONFIG_SATA_SIL24=y
@@ -235,11 +241,13 @@ CONFIG_ACENIC_OMIT_TIGON_I=y
CONFIG_E1000=y
CONFIG_E1000E=y
CONFIG_TIGON3=y
+CONFIG_BNX2=m
CONFIG_SPIDER_NET=m
CONFIG_GELIC_NET=m
CONFIG_GELIC_WIRELESS=y
CONFIG_CHELSIO_T1=m
CONFIG_CHELSIO_T3=m
+CONFIG_CHELSIO_T4=m
CONFIG_EHEA=m
CONFIG_IXGBE=m
CONFIG_IXGB=m
@@ -248,6 +256,8 @@ CONFIG_MYRI10GE=m
CONFIG_NETXEN_NIC=m
CONFIG_PASEMI_MAC=y
CONFIG_MLX4_EN=m
+CONFIG_QLGE=m
+CONFIG_BE2NET=m
CONFIG_ISERIES_VETH=m
CONFIG_PPP=m
CONFIG_PPP_ASYNC=m
@@ -330,6 +340,8 @@ CONFIG_INFINIBAND_USER_MAD=m
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_MTHCA=m
CONFIG_INFINIBAND_EHCA=m
+CONFIG_INFINIBAND_CXGB3=m
+CONFIG_INFINIBAND_CXGB4=m
CONFIG_MLX4_INFINIBAND=m
CONFIG_INFINIBAND_IPOIB=m
CONFIG_INFINIBAND_IPOIB_CM=y
^ permalink raw reply
* [PATCH 2/4] powerpc: Disable IRQs off tracer in ppc64 defconfig
From: Anton Blanchard @ 2011-07-06 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110706231313.260037641@samba.org>
The IRQs off tracer enables mcount which has a big impact on
performance. Disable it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-powerpc.orig/arch/powerpc/configs/ppc64_defconfig 2011-07-07 09:07:26.482898262 +1000
+++ linux-powerpc/arch/powerpc/configs/ppc64_defconfig 2011-07-07 09:07:29.932959288 +1000
@@ -446,7 +446,6 @@ CONFIG_DEBUG_MUTEXES=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
-CONFIG_IRQSOFF_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_DEBUG_STACKOVERFLOW=y
^ permalink raw reply
* [PATCH 3/4] powerpc: Add mpt2sas driver to pseries and ppc64 defconfig
From: Anton Blanchard @ 2011-07-06 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110706231313.260037641@samba.org>
Add mpt2sas driver to pseries and ppc64 defconfig.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-powerpc.orig/arch/powerpc/configs/ppc64_defconfig 2011-07-07 09:07:29.932959288 +1000
+++ linux-powerpc/arch/powerpc/configs/ppc64_defconfig 2011-07-07 09:07:31.242982461 +1000
@@ -181,6 +181,7 @@ CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_BE2ISCSI=m
+CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_IBMVSCSI=y
CONFIG_SCSI_IBMVFC=m
CONFIG_SCSI_SYM53C8XX_2=y
Index: linux-powerpc/arch/powerpc/configs/pseries_defconfig
===================================================================
--- linux-powerpc.orig/arch/powerpc/configs/pseries_defconfig 2011-07-05 14:23:08.098773438 +1000
+++ linux-powerpc/arch/powerpc/configs/pseries_defconfig 2011-07-07 09:07:31.242982461 +1000
@@ -149,6 +149,7 @@ CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_BE2ISCSI=m
+CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_IBMVSCSI=y
CONFIG_SCSI_IBMVFC=m
CONFIG_SCSI_SYM53C8XX_2=y
^ permalink raw reply
* [PATCH 4/4] powerpc: Enable lockup and hung task detectors in pseries and ppc64 defeconfigs
From: Anton Blanchard @ 2011-07-06 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110706231313.260037641@samba.org>
As a result of changes to Kconfig files, we no longer enable
the lockup and hung task detectors. Both are very light weight
and provide useful information in the event of a hang, so
reenable them.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-powerpc.orig/arch/powerpc/configs/ppc64_defconfig 2011-07-07 09:07:31.242982461 +1000
+++ linux-powerpc/arch/powerpc/configs/ppc64_defconfig 2011-07-07 09:07:32.693008109 +1000
@@ -443,6 +443,8 @@ CONFIG_NLS_KOI8_U=m
CONFIG_CRC_T10DIF=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_LATENCYTOP=y
Index: linux-powerpc/arch/powerpc/configs/pseries_defconfig
===================================================================
--- linux-powerpc.orig/arch/powerpc/configs/pseries_defconfig 2011-07-07 09:07:31.242982461 +1000
+++ linux-powerpc/arch/powerpc/configs/pseries_defconfig 2011-07-07 09:07:32.693008109 +1000
@@ -321,6 +321,8 @@ CONFIG_NLS_ISO8859_1=y
CONFIG_CRC_T10DIF=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_DETECT_HUNG_TASK=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
^ permalink raw reply
* {PATCH] Firmware update using the update_flash -f <filename> results to soft lockup BUG
From: divya @ 2011-07-07 5:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: antonb, naveedaus, kenistoj, chavez, arunbal, srikar, jlarrew,
lxie, mahesh.salgaonkar, Subrata Modak, suzukikp
Hi ,
Problem Description:
Firmware update using the update_flash -f<filename> results to soft lockup
BUG
FLASH: preparing saved firmware image for flash
FLASH: flash image is 50141296 bytes
FLASH: performing flash and reboot
FLASH: this will take several minutes. Do not power off!
BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
Steps to reproduce:
1. Check the firmware information on the machine (using ASM or lsmcode)
2. Update the system firmware with the update_flash command
update_flash -f 01FL350_039_038.img
info: Temporary side will be updated with a newer or
identical image
Projected Flash Update Results:
Current T Image: FL350_039
Current P Image: FL350_039
New T Image: FL350_039
New P Image: FL350_039
Flash image ready...rebooting the system...
Broadcast message from root@abc
(/dev/hvc0) at 5:25 ...
The system is going down for reboot NOW!
[root@abc /]# Stopping rhsmcertd[ OK ]
Stopping atd: [ OK ]
Stopping cups: [ OK ]
Stopping abrt daemon: [ OK ]
Stopping sshd: [ OK ]
Shutting down postfix: [ OK ]
Stopping rtas_errd (platform error handling) daemon: [ OK ]
Stopping crond: [ OK ]
Stopping automount: [ OK ]
Stopping HAL daemon: [ OK ]
Stopping iprdump: [ OK ]
Killing mdmonitor: [ OK ]]
Stopping system message bus: [ OK ]
Stopping rpcbind: [ OK ]
Stopping auditd: [ OK ]
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
ip6tables: Flushing firewall rules: [ OK ]
ip6tables: Setting chains to policy ACCEPT: filter [ OK ]
ip6tables: Unloading modules: [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Unloading modules: [ OK ]
Sending all processes the TERM signal... [ OK ]
Sending all processes the KILL signal... [ OK ]
Saving random seed: [ OK ]
Turning off swap: [ OK ]
Turning off quotas: [ OK ]
Unmounting pipe file systems: [ OK ]
Unmounting file systems: [ OK ]
init: Re-executing /sbin/init
Please stand by while rebooting the system...
Restarting system.
FLASH: preparing saved firmware image for flash
FLASH: flash image is 50141296 bytes
FLASH: performing flash and reboot
FLASH: this will take several minutes. Do not power off!
BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
This is solved by the following patch
--- arch/powerpc/kernel/setup-common.c.orig 2011-07-01 22:41:12.952507971 -0400
+++ arch/powerpc/kernel/setup-common.c 2011-07-01 22:48:31.182507915 -0400
@@ -109,11 +109,12 @@ void machine_shutdown(void)
void machine_restart(char *cmd)
{
machine_shutdown();
- if (ppc_md.restart)
- ppc_md.restart(cmd);
#ifdef CONFIG_SMP
- smp_send_stop();
+ smp_send_stop();
#endif
+ if (ppc_md.restart)
+ ppc_md.restart(cmd);
+
printk(KERN_EMERG "System Halted, OK to turn off power\n");
local_irq_disable();
while (1) ;
Thanks
Divya
^ permalink raw reply
* Re: {PATCH] Firmware update using the update_flash -f <filename> results to soft lockup BUG
From: Michael Neuling @ 2011-07-07 6:12 UTC (permalink / raw)
To: divya
Cc: suzukikp, antonb, naveedaus, kenistoj, chavez, arunbal,
linuxppc-dev, jlarrew, lxie, mahesh.salgaonkar, Subrata Modak,
srikar
In-Reply-To: <4E1543B6.9060800@linux.vnet.ibm.com>
In message <4E1543B6.9060800@linux.vnet.ibm.com> you wrote:
> Hi ,
>
> Problem Description:
> Firmware update using the update_flash -f<filename> results to soft lockup
> BUG
> FLASH: preparing saved firmware image for flash
> FLASH: flash image is 50141296 bytes
> FLASH: performing flash and reboot
> FLASH: this will take several minutes. Do not power off!
> BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
>
> Steps to reproduce:
> 1. Check the firmware information on the machine (using ASM or lsmcode)
> 2. Update the system firmware with the update_flash command
> update_flash -f 01FL350_039_038.img
> info: Temporary side will be updated with a newer or
> identical image
>
> Projected Flash Update Results:
> Current T Image: FL350_039
> Current P Image: FL350_039
> New T Image: FL350_039
> New P Image: FL350_039
> Flash image ready...rebooting the system...
>
> Broadcast message from root@abc
> (/dev/hvc0) at 5:25 ...
>
> The system is going down for reboot NOW!
> [root@abc /]# Stopping rhsmcertd[ OK ]
> Stopping atd: [ OK ]
> Stopping cups: [ OK ]
> Stopping abrt daemon: [ OK ]
> Stopping sshd: [ OK ]
> Shutting down postfix: [ OK ]
> Stopping rtas_errd (platform error handling) daemon: [ OK ]
> Stopping crond: [ OK ]
> Stopping automount: [ OK ]
> Stopping HAL daemon: [ OK ]
> Stopping iprdump: [ OK ]
> Killing mdmonitor: [ OK ]]
> Stopping system message bus: [ OK ]
> Stopping rpcbind: [ OK ]
> Stopping auditd: [ OK ]
> Shutting down interface eth0: [ OK ]
> Shutting down loopback interface: [ OK ]
> ip6tables: Flushing firewall rules: [ OK ]
> ip6tables: Setting chains to policy ACCEPT: filter [ OK ]
> ip6tables: Unloading modules: [ OK ]
> iptables: Flushing firewall rules: [ OK ]
> iptables: Setting chains to policy ACCEPT: filter [ OK ]
> iptables: Unloading modules: [ OK ]
> Sending all processes the TERM signal... [ OK ]
> Sending all processes the KILL signal... [ OK ]
> Saving random seed: [ OK ]
> Turning off swap: [ OK ]
> Turning off quotas: [ OK ]
> Unmounting pipe file systems: [ OK ]
> Unmounting file systems: [ OK ]
> init: Re-executing /sbin/init
> Please stand by while rebooting the system...
> Restarting system.
> FLASH: preparing saved firmware image for flash
> FLASH: flash image is 50141296 bytes
> FLASH: performing flash and reboot
> FLASH: this will take several minutes. Do not power off!
> BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
>
> This is solved by the following patch
Can you please explain how it fixes it?
Also you need a signed off by.
>
> --- arch/powerpc/kernel/setup-common.c.orig 2011-07-01 22:41:12.952507971 -
0400
> +++ arch/powerpc/kernel/setup-common.c 2011-07-01 22:48:31.182507915 -
0400
> @@ -109,11 +109,12 @@ void machine_shutdown(void)
> void machine_restart(char *cmd)
> {
> machine_shutdown();
> - if (ppc_md.restart)
> - ppc_md.restart(cmd);
> #ifdef CONFIG_SMP
> - smp_send_stop();
> + smp_send_stop();
Random white space change here.
> #endif
> + if (ppc_md.restart)
> + ppc_md.restart(cmd);
> +
> printk(KERN_EMERG "System Halted, OK to turn off power\n");
> local_irq_disable();
> while (1) ;
>
> Thanks
> Divya
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: {PATCH] Firmware update using the update_flash -f <filename> results to soft lockup BUG
From: divya @ 2011-07-07 7:24 UTC (permalink / raw)
To: Michael Neuling
Cc: suzukikp, antonb, naveedaus, kenistoj, chavez, arunbal,
linuxppc-dev, jlarrew, lxie, mahesh.salgaonkar, Subrata Modak,
srikar
In-Reply-To: <6426.1310019149@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 4748 bytes --]
On Thursday 07 July 2011 11:42 AM, Michael Neuling wrote:
> In message<4E1543B6.9060800@linux.vnet.ibm.com> you wrote:
>
>> Hi ,
>>
>> Problem Description:
>> Firmware update using the update_flash -f<filename> results to soft lockup
>> BUG
>> FLASH: preparing saved firmware image for flash
>> FLASH: flash image is 50141296 bytes
>> FLASH: performing flash and reboot
>> FLASH: this will take several minutes. Do not power off!
>> BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
>>
>> Steps to reproduce:
>> 1. Check the firmware information on the machine (using ASM or lsmcode)
>> 2. Update the system firmware with the update_flash command
>> update_flash -f 01FL350_039_038.img
>> info: Temporary side will be updated with a newer or
>> identical image
>>
>> Projected Flash Update Results:
>> Current T Image: FL350_039
>> Current P Image: FL350_039
>> New T Image: FL350_039
>> New P Image: FL350_039
>> Flash image ready...rebooting the system...
>>
>> Broadcast message from root@abc
>> (/dev/hvc0) at 5:25 ...
>>
>> The system is going down for reboot NOW!
>> [root@abc /]# Stopping rhsmcertd[ OK ]
>> Stopping atd: [ OK ]
>> Stopping cups: [ OK ]
>> Stopping abrt daemon: [ OK ]
>> Stopping sshd: [ OK ]
>> Shutting down postfix: [ OK ]
>> Stopping rtas_errd (platform error handling) daemon: [ OK ]
>> Stopping crond: [ OK ]
>> Stopping automount: [ OK ]
>> Stopping HAL daemon: [ OK ]
>> Stopping iprdump: [ OK ]
>> Killing mdmonitor: [ OK ]]
>> Stopping system message bus: [ OK ]
>> Stopping rpcbind: [ OK ]
>> Stopping auditd: [ OK ]
>> Shutting down interface eth0: [ OK ]
>> Shutting down loopback interface: [ OK ]
>> ip6tables: Flushing firewall rules: [ OK ]
>> ip6tables: Setting chains to policy ACCEPT: filter [ OK ]
>> ip6tables: Unloading modules: [ OK ]
>> iptables: Flushing firewall rules: [ OK ]
>> iptables: Setting chains to policy ACCEPT: filter [ OK ]
>> iptables: Unloading modules: [ OK ]
>> Sending all processes the TERM signal... [ OK ]
>> Sending all processes the KILL signal... [ OK ]
>> Saving random seed: [ OK ]
>> Turning off swap: [ OK ]
>> Turning off quotas: [ OK ]
>> Unmounting pipe file systems: [ OK ]
>> Unmounting file systems: [ OK ]
>> init: Re-executing /sbin/init
>> Please stand by while rebooting the system...
>> Restarting system.
>> FLASH: preparing saved firmware image for flash
>> FLASH: flash image is 50141296 bytes
>> FLASH: performing flash and reboot
>> FLASH: this will take several minutes. Do not power off!
>> BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
>>
>> This is solved by the following patch
>>
> Can you please explain how it fixes it?
>
Here goes the explanation for the fix.
The flash update is conducted with an RTAS call. The RTAS calls are serialized
by lock_rtas() which uses a spin_lock.
Now there is rtasd which keeps scanning for the RTAS events generated on the
machine. This is performed via workqueue mechanism. The rtas_event_scan() also
uses an RTAS call to scan the events, eventually taking the lock_rtas() before
it issues the request.
The flash update is an operation which takes long time, and hence while we are
at it, anyboy else who wants to make an RTAS call will have to wait until the
update is completed. Now in this case, the rtas_event_scan() is being kicked in
to check for events and it waits a long time on the spin_lock, getting us a
SOFT Lockup.
Before the rtas firmware update starts, all other CPUs should be stopped. Which
means no other CPU should be in lock_rtas(). We do not want other CPUs execute
while FW update is in progress and the system will be rebooted anyway after the
update.
> Also you need a signed off by.
>
> Signed-off-by: Divya <dipraksh@linux.vnet.ibm.com <mailto:dipraksh@linux.vnet.ibm.com>>
>
>
>> --- arch/powerpc/kernel/setup-common.c.orig 2011-07-01 22:41:12.952507971 -
>>
> 0400
>
>> +++ arch/powerpc/kernel/setup-common.c 2011-07-01 22:48:31.182507915 -
>>
> 0400
>
>> @@ -109,11 +109,12 @@ void machine_shutdown(void)
>> void machine_restart(char *cmd)
>> {
>> machine_shutdown();
>> - if (ppc_md.restart)
>> - ppc_md.restart(cmd);
>> #ifdef CONFIG_SMP
>> - smp_send_stop();
>> + smp_send_stop();
>>
> Random white space change here.
>
>
>> #endif
>> + if (ppc_md.restart)
>> + ppc_md.restart(cmd);
>> +
>> printk(KERN_EMERG "System Halted, OK to turn off power\n");
>> local_irq_disable();
>> while (1) ;
>>
>> Thanks
>> Divya
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
[-- Attachment #2: Type: text/html, Size: 5647 bytes --]
^ permalink raw reply
* [PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.
From: Felix Radensky @ 2011-07-07 7:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Felix Radensky, B04825
On P1022DS both ethernet controllers are connected to RGMII PHYs
accessible via MDIO bus. Remove fixed-link property from ethernet
nodes as they only required when fixed link PHYs without MDIO bus
are used.
Signed-off-by: Felix Radensky <felix@embedded-sol.com>
---
arch/powerpc/boot/dts/p1022ds.dts | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
index 98d9426..1be9743 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -412,7 +412,6 @@
fsl,magic-packet;
fsl,wake-on-filer;
local-mac-address = [ 00 00 00 00 00 00 ];
- fixed-link = <1 1 1000 0 0>;
phy-handle = <&phy0>;
phy-connection-type = "rgmii-id";
queue-group@0{
@@ -439,7 +438,6 @@
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
local-mac-address = [ 00 00 00 00 00 00 ];
- fixed-link = <1 1 1000 0 0>;
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
queue-group@0{
--
1.7.4.4
^ permalink raw reply related
* RE: [PATCH 4/4] powerpc: Enable lockup and hung task detectors in pseriesand ppc64 defeconfigs
From: David Laight @ 2011-07-07 7:46 UTC (permalink / raw)
To: Anton Blanchard, benh; +Cc: linuxppc-dev
In-Reply-To: <20110706231337.327165192@samba.org>
=20
> As a result of changes to Kconfig files, we no longer enable
> the lockup and hung task detectors. Both are very light weight
> and provide useful information in the event of a hang, so
> reenable them.
...
> +CONFIG_LOCKUP_DETECTOR=3Dy
> +CONFIG_DETECT_HUNG_TASK=3Dy
Is one of thise responsible for generating a kernel stack traceback
when a process has been sleeping uninterruptably for a 'long' time?
We have a kernel subsystem that has several 'worker' threads,
these always sleep uninterruptable (they are shut down by explicit
request) and, at times, can be idle for long periods.
Perhaps it should be possible to disable the check either on
a per-process of per sleep basis?
David
^ permalink raw reply
* [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Mahesh J Salgaonkar @ 2011-07-07 10:22 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev; +Cc: mingo, torvalds, a.p.zijlstra, anton
Hi,
linux-3.0-rc fails to boot on a power7 system with 1TB ram and 896 CPUs.
While the initial boot log shows a soft-lockup [1], the machine is hung after.
Dropping into xmon shows the cpus are all struck at:
--------------------
cpu 0xa: Vector: 100 (System Reset) at [c000000fae51fae0]
pc: c0000000000596b8: .plpar_hcall_norets+0x80/0xd0
lr: c00000000005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210
sp: c000000fae51fd60
msr: 8000000000089032
current = 0xc000000fae49d990
paca = 0xc00000000ebb1900
pid = 0, comm = kworker/0:1
cpu 0x41: Vector: 100 (System Reset) at [c000000fac01bae0]
pc: c0000000000596b8: .plpar_hcall_norets+0x80/0xd0
lr: c00000000005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210
sp: c000000fac01bd60
msr: 8000000000089032
current = 0xc000000faefbf210
paca = 0xc00000000ebba280
pid = 0, comm = kworker/0:1
cpu 0x21: Vector: 100 (System Reset) at [c000000fae9abae0]
pc: c0000000000596b8: .plpar_hcall_norets+0x80/0xd0
lr: c00000000005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210
sp: c000000fae9abd60
msr: 8000000000089032
current = 0xc000000fae998590
paca = 0xc00000000ebb5280
pid = 0, comm = kworker/0:1
cpu 0xb8: Vector: 100 (System Reset) at [c000000fab3dbae0]
pc: c0000000000596b8: .plpar_hcall_norets+0x80/0xd0
lr: c00000000005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210
sp: c000000fab3dbd60
msr: 8000000000089032
current = 0xc000000fab3a2710
paca = 0xc00000000ebccc00
pid = 0, comm = kworker/0:1
......
......
And shows same for all the CPUs.
a:mon> t
[link register ] c00000000005b9a4 .pseries_dedicated_idle_sleep+0x194/0x210
[c000000fae51fd60] 00000000134d0000 (unreliable)
[c000000fae51fe20] c000000000018b64 .cpu_idle+0x164/0x210
[c000000fae51fed0] c0000000005d55b0 .start_secondary+0x348/0x354
[c000000fae51ff90] c000000000009268 .start_secondary_prolog+0x10/0x14
a:mon> S
msr = 8000000000001032 sprg0= 0000000000000000
pvr = 00000000003f0201 sprg1= c00000000ebb1900
dec = 0000000030fb5b4f sprg2= c00000000ebb1900
sp = c000000fae51f440 sprg3= 000000000000000a
toc = c000000000e21f90 dar = c000011aee0c20e8
a:mon>
--------------------
2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae -
"sched: Change NODE sched_domain group creation" as the cause.
Thanks,
-Mahesh.
[1]:
POWER7 performance monitor hardware support registered
Brought up 896 CPUs
Enabling Asymmetric SMT scheduling
BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
Modules linked in:
NIP: c000000000074b90 LR: c00000000008a1c4 CTR: 0000000000000000
REGS: c000000fae25f9c0 TRAP: 0901 Not tainted (3.0.0-rc6)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000088 XER: 00000004
TASK = c000000fae248490[1] 'swapper' THREAD: c000000fae25c000 CPU: 0
GPR00: 0000e2a55cbeec50 c000000fae25fc40 c000000000e21f90 c000007b2b34cb00
GPR04: 0000000000000100 0000000000000100 c000011adcf23418 0000000000000000
GPR08: 0000000000000000 c000008b2b7d4480 c000007b2b35ef80 00000000000024ac
GPR12: 0000000044000042 c00000000ebb0000
NIP [c000000000074b90] .update_group_power+0x50/0x190
LR [c00000000008a1c4] .build_sched_domains+0x434/0x490
Call Trace:
[c000000fae25fc40] [c000000fae25fce0] 0xc000000fae25fce0 (unreliable)
[c000000fae25fce0] [c00000000008a1c4] .build_sched_domains+0x434/0x490
[c000000fae25fdd0] [c000000000867370] .sched_init_smp+0xa8/0x224
[c000000fae25fee0] [c000000000850274] .kernel_init+0x10c/0x1fc
[c000000fae25ff90] [c000000000023884] .kernel_thread+0x54/0x70
Instruction dump:
f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa90000 419e0054
e9490010 38000000 7d495378 60000000 <8169000c> e9290000 7faa4800 7c005a14
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Peter Zijlstra @ 2011-07-07 10:59 UTC (permalink / raw)
To: mahesh; +Cc: linuxppc-dev, linux-kernel, anton, mingo, torvalds
In-Reply-To: <20110707102107.GA16666@in.ibm.com>
On Thu, 2011-07-07 at 15:52 +0530, Mahesh J Salgaonkar wrote:
>=20
> 2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae -
> "sched: Change NODE sched_domain group creation" as the cause.
Weird, there's no locking anywhere around there. The typical problems
with this patch-set were massive explosions due to bad pointers etc..
But not silent hangs.
The code its stuck at:
> [1]:
> POWER7 performance monitor hardware support registered
> Brought up 896 CPUs
> Enabling Asymmetric SMT scheduling
> BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
> Modules linked in:
> NIP: c000000000074b90 LR: c00000000008a1c4 CTR: 0000000000000000
> REGS: c000000fae25f9c0 TRAP: 0901 Not tainted (3.0.0-rc6)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000088 XER: 00000004
> TASK =3D c000000fae248490[1] 'swapper' THREAD: c000000fae25c000 CPU: 0
> GPR00: 0000e2a55cbeec50 c000000fae25fc40 c000000000e21f90 c000007b2b34cb0=
0
> GPR04: 0000000000000100 0000000000000100 c000011adcf23418 000000000000000=
0
> GPR08: 0000000000000000 c000008b2b7d4480 c000007b2b35ef80 00000000000024a=
c
> GPR12: 0000000044000042 c00000000ebb0000
> NIP [c000000000074b90] .update_group_power+0x50/0x190
> LR [c00000000008a1c4] .build_sched_domains+0x434/0x490
> Call Trace:
> [c000000fae25fc40] [c000000fae25fce0] 0xc000000fae25fce0 (unreliable)
> [c000000fae25fce0] [c00000000008a1c4] .build_sched_domains+0x434/0x490
> [c000000fae25fdd0] [c000000000867370] .sched_init_smp+0xa8/0x224
> [c000000fae25fee0] [c000000000850274] .kernel_init+0x10c/0x1fc
> [c000000fae25ff90] [c000000000023884] .kernel_thread+0x54/0x70
> Instruction dump:
> f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa90000 419e0054
> e9490010 38000000 7d495378 60000000 <8169000c> e9290000 7faa4800 7c005a14
doesn't contains any locks, its simply looping over all the cpus, and
with that many I can imagine it takes a while, but getting 'stuck' there
is unexpected to say the least.
Surely this isn't the first multi-node P7 to boot a kernel with this
patch? If my git foo is any good it hit -next on 23rd of May.
I guess I'm asking is, do smaller P7 machines boot? And if so, is there
any difference except size?
How many nodes does the thing have anyway, 28? Hmm, that could mean its
the first machine with >16 nodes to boot this, which would make it
trigger the magic ALL_NODES crap.
Let me dig around there.
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Mahesh J Salgaonkar @ 2011-07-07 11:55 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: torvalds, mingo, linuxppc-dev, linux-kernel, anton
In-Reply-To: <1310036375.3282.509.camel@twins>
On 2011-07-07 12:59:35 Thu, Peter Zijlstra wrote:
> On Thu, 2011-07-07 at 15:52 +0530, Mahesh J Salgaonkar wrote:
> >
> > 2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae -
> > "sched: Change NODE sched_domain group creation" as the cause.
>
> Weird, there's no locking anywhere around there. The typical problems
> with this patch-set were massive explosions due to bad pointers etc..
> But not silent hangs.
>
> The code its stuck at:
>
> > [1]:
> > POWER7 performance monitor hardware support registered
> > Brought up 896 CPUs
> > Enabling Asymmetric SMT scheduling
> > BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
> > Modules linked in:
> > NIP: c000000000074b90 LR: c00000000008a1c4 CTR: 0000000000000000
> > REGS: c000000fae25f9c0 TRAP: 0901 Not tainted (3.0.0-rc6)
> > MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000088 XER: 00000004
> > TASK = c000000fae248490[1] 'swapper' THREAD: c000000fae25c000 CPU: 0
> > GPR00: 0000e2a55cbeec50 c000000fae25fc40 c000000000e21f90 c000007b2b34cb00
> > GPR04: 0000000000000100 0000000000000100 c000011adcf23418 0000000000000000
> > GPR08: 0000000000000000 c000008b2b7d4480 c000007b2b35ef80 00000000000024ac
> > GPR12: 0000000044000042 c00000000ebb0000
> > NIP [c000000000074b90] .update_group_power+0x50/0x190
> > LR [c00000000008a1c4] .build_sched_domains+0x434/0x490
> > Call Trace:
> > [c000000fae25fc40] [c000000fae25fce0] 0xc000000fae25fce0 (unreliable)
> > [c000000fae25fce0] [c00000000008a1c4] .build_sched_domains+0x434/0x490
> > [c000000fae25fdd0] [c000000000867370] .sched_init_smp+0xa8/0x224
> > [c000000fae25fee0] [c000000000850274] .kernel_init+0x10c/0x1fc
> > [c000000fae25ff90] [c000000000023884] .kernel_thread+0x54/0x70
> > Instruction dump:
> > f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa90000 419e0054
> > e9490010 38000000 7d495378 60000000 <8169000c> e9290000 7faa4800 7c005a14
>
> doesn't contains any locks, its simply looping over all the cpus, and
> with that many I can imagine it takes a while, but getting 'stuck' there
> is unexpected to say the least.
>
> Surely this isn't the first multi-node P7 to boot a kernel with this
> patch? If my git foo is any good it hit -next on 23rd of May.
>
> I guess I'm asking is, do smaller P7 machines boot? And if so, is there
> any difference except size?
Yes, the smaller P7 machine that I have with 20 CPUs and 2GB ram boots
fine with 3.0.0-rc.
>
> How many nodes does the thing have anyway, 28? Hmm, that could mean its
> the first machine with >16 nodes to boot this, which would make it
> trigger the magic ALL_NODES crap.
The P7 machine where kernel fails to boot shows following demsg log w.r.t
node map:
---------------------------
Zone PFN ranges:
DMA 0x00000000 -> 0x01229000
Normal empty
Movable zone start PFN for each node
early_node_map[12] active PFN ranges
0: 0x00000000 -> 0x000fd000
4: 0x000fd000 -> 0x002fb000
5: 0x002fb000 -> 0x004b9000
6: 0x004b9000 -> 0x006b9000
8: 0x006b9000 -> 0x007b5000
12: 0x007b5000 -> 0x008b5000
16: 0x008b5000 -> 0x009b1000
20: 0x009b1000 -> 0x00bb1000
21: 0x00bb1000 -> 0x00db1000
22: 0x00db1000 -> 0x00fb1000
23: 0x00fb1000 -> 0x011b1000
28: 0x011b1000 -> 0x01229000
Could not find start_pfn for node 1
Could not find start_pfn for node 2
Could not find start_pfn for node 3
Could not find start_pfn for node 7
Could not find start_pfn for node 9
Could not find start_pfn for node 10
Could not find start_pfn for node 11
Could not find start_pfn for node 13
Could not find start_pfn for node 14
Could not find start_pfn for node 15
Could not find start_pfn for node 17
Could not find start_pfn for node 18
Could not find start_pfn for node 19
Could not find start_pfn for node 29
Could not find start_pfn for node 30
Could not find start_pfn for node 31
[boot]0015 Setup Done
PERCPU: Embedded 1 pages/cpu @c000000013c00000 s31488 r0 d34048 u65536
Built 28 zonelists in Node order, mobility grouping on. Total pages:
19026032
Policy zone: DMA
Kernel command line: root=/dev/mapper/vg_nish1-lv_root ro
rd_LVM_LV=vg_nish1/lv_root rd_LVM_LV=VolGroup/lv_swap
rd_LVM_LV=vg_nish1/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=hvc0i memblock=debug
PID hash table entries: 4096 (order: -1, 32768 bytes)
freeing bootmem node 0
freeing bootmem node 4
freeing bootmem node 5
freeing bootmem node 6
freeing bootmem node 8
freeing bootmem node 12
freeing bootmem node 16
freeing bootmem node 20
freeing bootmem node 21
freeing bootmem node 22
freeing bootmem node 23
freeing bootmem node 28
Memory: 1213775296k/1218707456k available (13312k kernel code, 4932160k
reserved, 1600k data, 2727k bss, 4928k init)
---------------------------
Thanks,
-Mahesh.
>
> Let me dig around there.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Mahesh J Salgaonkar
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Peter Zijlstra @ 2011-07-07 12:28 UTC (permalink / raw)
To: mahesh; +Cc: torvalds, mingo, linuxppc-dev, linux-kernel, anton
In-Reply-To: <20110707115531.GA21737@in.ibm.com>
On Thu, 2011-07-07 at 17:25 +0530, Mahesh J Salgaonkar wrote:
> > I guess I'm asking is, do smaller P7 machines boot? And if so, is there
> > any difference except size?
>=20
> Yes, the smaller P7 machine that I have with 20 CPUs and 2GB ram boots
> fine with 3.0.0-rc.=20
That sounds like a single node machine. P7 comes as {4,6,8}*4 (16,24,32
cpus) per socket. And that 2G doesn't sound like much either.
^ 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