* [PATCH v2 04/28] powerpc: platforms/82xx irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110307235917.GI16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 27 ++++++++++++-------------
1 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
index 5a55d87..926dfda 100644
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -39,10 +39,10 @@ struct pq2ads_pci_pic {
#define NUM_IRQS 32
-static void pq2ads_pci_mask_irq(unsigned int virq)
+static void pq2ads_pci_mask_irq(struct irq_data *d)
{
- struct pq2ads_pci_pic *priv = get_irq_chip_data(virq);
- int irq = NUM_IRQS - virq_to_hw(virq) - 1;
+ struct pq2ads_pci_pic *priv = irq_data_get_irq_chip_data(d);
+ int irq = NUM_IRQS - virq_to_hw(d->irq) - 1;
if (irq != -1) {
unsigned long flags;
@@ -55,10 +55,10 @@ static void pq2ads_pci_mask_irq(unsigned int virq)
}
}
-static void pq2ads_pci_unmask_irq(unsigned int virq)
+static void pq2ads_pci_unmask_irq(struct irq_data *d)
{
- struct pq2ads_pci_pic *priv = get_irq_chip_data(virq);
- int irq = NUM_IRQS - virq_to_hw(virq) - 1;
+ struct pq2ads_pci_pic *priv = irq_data_get_irq_chip_data(d);
+ int irq = NUM_IRQS - virq_to_hw(d->irq) - 1;
if (irq != -1) {
unsigned long flags;
@@ -71,18 +71,17 @@ static void pq2ads_pci_unmask_irq(unsigned int virq)
static struct irq_chip pq2ads_pci_ic = {
.name = "PQ2 ADS PCI",
- .end = pq2ads_pci_unmask_irq,
- .mask = pq2ads_pci_mask_irq,
- .mask_ack = pq2ads_pci_mask_irq,
- .ack = pq2ads_pci_mask_irq,
- .unmask = pq2ads_pci_unmask_irq,
- .enable = pq2ads_pci_unmask_irq,
- .disable = pq2ads_pci_mask_irq
+ .irq_mask = pq2ads_pci_mask_irq,
+ .irq_mask_ack = pq2ads_pci_mask_irq,
+ .irq_ack = pq2ads_pci_mask_irq,
+ .irq_unmask = pq2ads_pci_unmask_irq,
+ .irq_enable = pq2ads_pci_unmask_irq,
+ .irq_disable = pq2ads_pci_mask_irq
};
static void pq2ads_pci_irq_demux(unsigned int irq, struct irq_desc *desc)
{
- struct pq2ads_pci_pic *priv = desc->handler_data;
+ struct pq2ads_pci_pic *priv = get_irq_desc_data(desc);
u32 stat, mask, pend;
int bit;
--
1.7.4
^ permalink raw reply related
* [PATCH v2 10/28] powerpc: platforms/embedded6xx irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110307235933.GO16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/platforms/embedded6xx/flipper-pic.c | 32 ++++++++--------
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 41 +++++++++++----------
2 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/flipper-pic.c b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
index c278bd3..0aca0e2 100644
--- a/arch/powerpc/platforms/embedded6xx/flipper-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
@@ -46,10 +46,10 @@
*
*/
-static void flipper_pic_mask_and_ack(unsigned int virq)
+static void flipper_pic_mask_and_ack(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void __iomem *io_base = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void __iomem *io_base = irq_data_get_irq_chip_data(d);
u32 mask = 1 << irq;
clrbits32(io_base + FLIPPER_IMR, mask);
@@ -57,27 +57,27 @@ static void flipper_pic_mask_and_ack(unsigned int virq)
out_be32(io_base + FLIPPER_ICR, mask);
}
-static void flipper_pic_ack(unsigned int virq)
+static void flipper_pic_ack(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void __iomem *io_base = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void __iomem *io_base = irq_data_get_irq_chip_data(d);
/* this is at least needed for RSW */
out_be32(io_base + FLIPPER_ICR, 1 << irq);
}
-static void flipper_pic_mask(unsigned int virq)
+static void flipper_pic_mask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void __iomem *io_base = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void __iomem *io_base = irq_data_get_irq_chip_data(d);
clrbits32(io_base + FLIPPER_IMR, 1 << irq);
}
-static void flipper_pic_unmask(unsigned int virq)
+static void flipper_pic_unmask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void __iomem *io_base = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void __iomem *io_base = irq_data_get_irq_chip_data(d);
setbits32(io_base + FLIPPER_IMR, 1 << irq);
}
@@ -85,10 +85,10 @@ static void flipper_pic_unmask(unsigned int virq)
static struct irq_chip flipper_pic = {
.name = "flipper-pic",
- .ack = flipper_pic_ack,
- .mask_ack = flipper_pic_mask_and_ack,
- .mask = flipper_pic_mask,
- .unmask = flipper_pic_unmask,
+ .irq_ack = flipper_pic_ack,
+ .irq_mask_ack = flipper_pic_mask_and_ack,
+ .irq_mask = flipper_pic_mask,
+ .irq_unmask = flipper_pic_unmask,
};
/*
diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
index a771f91..35e448b 100644
--- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
@@ -41,36 +41,36 @@
*
*/
-static void hlwd_pic_mask_and_ack(unsigned int virq)
+static void hlwd_pic_mask_and_ack(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void __iomem *io_base = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void __iomem *io_base = irq_data_get_irq_chip_data(d);
u32 mask = 1 << irq;
clrbits32(io_base + HW_BROADWAY_IMR, mask);
out_be32(io_base + HW_BROADWAY_ICR, mask);
}
-static void hlwd_pic_ack(unsigned int virq)
+static void hlwd_pic_ack(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void __iomem *io_base = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void __iomem *io_base = irq_data_get_irq_chip_data(d);
out_be32(io_base + HW_BROADWAY_ICR, 1 << irq);
}
-static void hlwd_pic_mask(unsigned int virq)
+static void hlwd_pic_mask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void __iomem *io_base = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void __iomem *io_base = irq_data_get_irq_chip_data(d);
clrbits32(io_base + HW_BROADWAY_IMR, 1 << irq);
}
-static void hlwd_pic_unmask(unsigned int virq)
+static void hlwd_pic_unmask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void __iomem *io_base = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void __iomem *io_base = irq_data_get_irq_chip_data(d);
setbits32(io_base + HW_BROADWAY_IMR, 1 << irq);
}
@@ -78,10 +78,10 @@ static void hlwd_pic_unmask(unsigned int virq)
static struct irq_chip hlwd_pic = {
.name = "hlwd-pic",
- .ack = hlwd_pic_ack,
- .mask_ack = hlwd_pic_mask_and_ack,
- .mask = hlwd_pic_mask,
- .unmask = hlwd_pic_unmask,
+ .irq_ack = hlwd_pic_ack,
+ .irq_mask_ack = hlwd_pic_mask_and_ack,
+ .irq_mask = hlwd_pic_mask,
+ .irq_unmask = hlwd_pic_unmask,
};
/*
@@ -129,11 +129,12 @@ static unsigned int __hlwd_pic_get_irq(struct irq_host *h)
static void hlwd_pic_irq_cascade(unsigned int cascade_virq,
struct irq_desc *desc)
{
+ struct irq_chip *chip = get_irq_desc_chip(desc);
struct irq_host *irq_host = get_irq_data(cascade_virq);
unsigned int virq;
raw_spin_lock(&desc->lock);
- desc->chip->mask(cascade_virq); /* IRQ_LEVEL */
+ chip->irq_mask(&desc->irq_data); /* IRQ_LEVEL */
raw_spin_unlock(&desc->lock);
virq = __hlwd_pic_get_irq(irq_host);
@@ -143,9 +144,9 @@ static void hlwd_pic_irq_cascade(unsigned int cascade_virq,
pr_err("spurious interrupt!\n");
raw_spin_lock(&desc->lock);
- desc->chip->ack(cascade_virq); /* IRQ_LEVEL */
- if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
- desc->chip->unmask(cascade_virq);
+ chip->irq_ack(&desc->irq_data); /* IRQ_LEVEL */
+ if (!(desc->status & IRQ_DISABLED) && chip->irq_unmask)
+ chip->irq_unmask(&desc->irq_data);
raw_spin_unlock(&desc->lock);
}
--
1.7.4
^ permalink raw reply related
* [PATCH v2 13/28] powerpc: platforms/ps3 irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110307235942.GR16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/platforms/ps3/interrupt.c | 40 ++++++++++++++++----------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
index 92290ff..3988c86 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -99,16 +99,16 @@ static DEFINE_PER_CPU(struct ps3_private, ps3_private);
* Sets ps3_bmp.mask and calls lv1_did_update_interrupt_mask().
*/
-static void ps3_chip_mask(unsigned int virq)
+static void ps3_chip_mask(struct irq_data *d)
{
- struct ps3_private *pd = get_irq_chip_data(virq);
+ struct ps3_private *pd = irq_data_get_irq_chip_data(d);
unsigned long flags;
pr_debug("%s:%d: thread_id %llu, virq %d\n", __func__, __LINE__,
- pd->thread_id, virq);
+ pd->thread_id, d->irq);
local_irq_save(flags);
- clear_bit(63 - virq, &pd->bmp.mask);
+ clear_bit(63 - d->irq, &pd->bmp.mask);
lv1_did_update_interrupt_mask(pd->ppe_id, pd->thread_id);
local_irq_restore(flags);
}
@@ -120,16 +120,16 @@ static void ps3_chip_mask(unsigned int virq)
* Clears ps3_bmp.mask and calls lv1_did_update_interrupt_mask().
*/
-static void ps3_chip_unmask(unsigned int virq)
+static void ps3_chip_unmask(struct irq_data *d)
{
- struct ps3_private *pd = get_irq_chip_data(virq);
+ struct ps3_private *pd = irq_data_get_irq_chip_data(d);
unsigned long flags;
pr_debug("%s:%d: thread_id %llu, virq %d\n", __func__, __LINE__,
- pd->thread_id, virq);
+ pd->thread_id, d->irq);
local_irq_save(flags);
- set_bit(63 - virq, &pd->bmp.mask);
+ set_bit(63 - d->irq, &pd->bmp.mask);
lv1_did_update_interrupt_mask(pd->ppe_id, pd->thread_id);
local_irq_restore(flags);
}
@@ -141,10 +141,10 @@ static void ps3_chip_unmask(unsigned int virq)
* Calls lv1_end_of_interrupt_ext().
*/
-static void ps3_chip_eoi(unsigned int virq)
+static void ps3_chip_eoi(struct irq_data *d)
{
- const struct ps3_private *pd = get_irq_chip_data(virq);
- lv1_end_of_interrupt_ext(pd->ppe_id, pd->thread_id, virq);
+ const struct ps3_private *pd = irq_data_get_irq_chip_data(d);
+ lv1_end_of_interrupt_ext(pd->ppe_id, pd->thread_id, d->irq);
}
/**
@@ -153,9 +153,9 @@ static void ps3_chip_eoi(unsigned int virq)
static struct irq_chip ps3_irq_chip = {
.name = "ps3",
- .mask = ps3_chip_mask,
- .unmask = ps3_chip_unmask,
- .eoi = ps3_chip_eoi,
+ .irq_mask = ps3_chip_mask,
+ .irq_unmask = ps3_chip_unmask,
+ .irq_eoi = ps3_chip_eoi,
};
/**
@@ -202,7 +202,7 @@ static int ps3_virq_setup(enum ps3_cpu_binding cpu, unsigned long outlet,
goto fail_set;
}
- ps3_chip_mask(*virq);
+ ps3_chip_mask(irq_get_irq_data(*virq));
return result;
@@ -296,7 +296,7 @@ int ps3_irq_plug_destroy(unsigned int virq)
pr_debug("%s:%d: ppe_id %llu, thread_id %llu, virq %u\n", __func__,
__LINE__, pd->ppe_id, pd->thread_id, virq);
- ps3_chip_mask(virq);
+ ps3_chip_mask(irq_get_irq_data(virq));
result = lv1_disconnect_irq_plug_ext(pd->ppe_id, pd->thread_id, virq);
@@ -357,7 +357,7 @@ int ps3_event_receive_port_destroy(unsigned int virq)
pr_debug(" -> %s:%d virq %u\n", __func__, __LINE__, virq);
- ps3_chip_mask(virq);
+ ps3_chip_mask(irq_get_irq_data(virq));
result = lv1_destruct_event_receive_port(virq_to_hw(virq));
@@ -492,7 +492,7 @@ int ps3_io_irq_destroy(unsigned int virq)
int result;
unsigned long outlet = virq_to_hw(virq);
- ps3_chip_mask(virq);
+ ps3_chip_mask(irq_get_irq_data(virq));
/*
* lv1_destruct_io_irq_outlet() will destroy the IRQ plug,
@@ -553,7 +553,7 @@ int ps3_vuart_irq_destroy(unsigned int virq)
{
int result;
- ps3_chip_mask(virq);
+ ps3_chip_mask(irq_get_irq_data(virq));
result = lv1_deconfigure_virtual_uart_irq();
if (result) {
@@ -605,7 +605,7 @@ int ps3_spe_irq_destroy(unsigned int virq)
{
int result;
- ps3_chip_mask(virq);
+ ps3_chip_mask(irq_get_irq_data(virq));
result = ps3_irq_plug_destroy(virq);
BUG_ON(result);
--
1.7.4
^ permalink raw reply related
* [PATCH v2 21/28] powerpc: sysdev/mpc8xxx_gpio irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110308000004.GZ16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/sysdev/mpc8xxx_gpio.c | 42 ++++++++++++++++++------------------
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index c48cd81..11fb518 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -155,43 +155,43 @@ static void mpc8xxx_gpio_irq_cascade(unsigned int irq, struct irq_desc *desc)
32 - ffs(mask)));
}
-static void mpc8xxx_irq_unmask(unsigned int virq)
+static void mpc8xxx_irq_unmask(struct irq_data *d)
{
- struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
unsigned long flags;
spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
- setbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ setbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(d->irq)));
spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
}
-static void mpc8xxx_irq_mask(unsigned int virq)
+static void mpc8xxx_irq_mask(struct irq_data *d)
{
- struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
unsigned long flags;
spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
- clrbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ clrbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(d->irq)));
spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
}
-static void mpc8xxx_irq_ack(unsigned int virq)
+static void mpc8xxx_irq_ack(struct irq_data *d)
{
- struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
- out_be32(mm->regs + GPIO_IER, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ out_be32(mm->regs + GPIO_IER, mpc8xxx_gpio2mask(virq_to_hw(d->irq)));
}
-static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
+static int mpc8xxx_irq_set_type(struct irq_data *d, unsigned int flow_type)
{
- struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
unsigned long flags;
@@ -199,14 +199,14 @@ static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
case IRQ_TYPE_EDGE_FALLING:
spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
setbits32(mm->regs + GPIO_ICR,
- mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ mpc8xxx_gpio2mask(virq_to_hw(d->irq)));
spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
break;
case IRQ_TYPE_EDGE_BOTH:
spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
clrbits32(mm->regs + GPIO_ICR,
- mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ mpc8xxx_gpio2mask(virq_to_hw(d->irq)));
spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
break;
@@ -217,11 +217,11 @@ static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
return 0;
}
-static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_type)
+static int mpc512x_irq_set_type(struct irq_data *d, unsigned int flow_type)
{
- struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
- unsigned long gpio = virq_to_hw(virq);
+ unsigned long gpio = virq_to_hw(d->irq);
void __iomem *reg;
unsigned int shift;
unsigned long flags;
@@ -264,10 +264,10 @@ static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_type)
static struct irq_chip mpc8xxx_irq_chip = {
.name = "mpc8xxx-gpio",
- .unmask = mpc8xxx_irq_unmask,
- .mask = mpc8xxx_irq_mask,
- .ack = mpc8xxx_irq_ack,
- .set_type = mpc8xxx_irq_set_type,
+ .irq_unmask = mpc8xxx_irq_unmask,
+ .irq_mask = mpc8xxx_irq_mask,
+ .irq_ack = mpc8xxx_irq_ack,
+ .irq_set_type = mpc8xxx_irq_set_type,
};
static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
@@ -276,7 +276,7 @@ static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
struct mpc8xxx_gpio_chip *mpc8xxx_gc = h->host_data;
if (mpc8xxx_gc->of_dev_id_data)
- mpc8xxx_irq_chip.set_type = mpc8xxx_gc->of_dev_id_data;
+ mpc8xxx_irq_chip.irq_set_type = mpc8xxx_gc->of_dev_id_data;
set_irq_chip_data(virq, h->host_data);
set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
--
1.7.4
^ permalink raw reply related
* [PATCH v2 23/28] powerpc: sysdev/qe_lib/qe_ic irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110308000010.GB16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/include/asm/qe_ic.h | 19 +++++++++++--------
arch/powerpc/sysdev/qe_lib/qe_ic.c | 25 +++++++++++++++----------
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/qe_ic.h b/arch/powerpc/include/asm/qe_ic.h
index cf51966..9e2cb20 100644
--- a/arch/powerpc/include/asm/qe_ic.h
+++ b/arch/powerpc/include/asm/qe_ic.h
@@ -81,7 +81,7 @@ int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high);
static inline void qe_ic_cascade_low_ipic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
if (cascade_irq != NO_IRQ)
@@ -91,7 +91,7 @@ static inline void qe_ic_cascade_low_ipic(unsigned int irq,
static inline void qe_ic_cascade_high_ipic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
if (cascade_irq != NO_IRQ)
@@ -101,32 +101,35 @@ static inline void qe_ic_cascade_high_ipic(unsigned int irq,
static inline void qe_ic_cascade_low_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
+ struct irq_chip *chip = get_irq_desc_chip(desc);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- desc->chip->eoi(irq);
+ chip->irq_eoi(&desc->irq_data);
}
static inline void qe_ic_cascade_high_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
+ struct irq_chip *chip = get_irq_desc_chip(desc);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- desc->chip->eoi(irq);
+ chip->irq_eoi(&desc->irq_data);
}
static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq;
+ struct irq_chip *chip = get_irq_desc_chip(desc);
cascade_irq = qe_ic_get_high_irq(qe_ic);
if (cascade_irq == NO_IRQ)
@@ -135,7 +138,7 @@ static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- desc->chip->eoi(irq);
+ chip->irq_eoi(&desc->irq_data);
}
#endif /* _ASM_POWERPC_QE_IC_H */
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 541ba98..8c9ded8 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -189,15 +189,20 @@ static inline void qe_ic_write(volatile __be32 __iomem * base, unsigned int reg
static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
{
- return irq_to_desc(virq)->chip_data;
+ return get_irq_chip_data(virq);
+}
+
+static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
+{
+ return irq_data_get_irq_chip_data(d);
}
#define virq_to_hw(virq) ((unsigned int)irq_map[virq].hwirq)
-static void qe_ic_unmask_irq(unsigned int virq)
+static void qe_ic_unmask_irq(struct irq_data *d)
{
- struct qe_ic *qe_ic = qe_ic_from_irq(virq);
- unsigned int src = virq_to_hw(virq);
+ struct qe_ic *qe_ic = qe_ic_from_irq_data(d);
+ unsigned int src = virq_to_hw(d->irq);
unsigned long flags;
u32 temp;
@@ -210,10 +215,10 @@ static void qe_ic_unmask_irq(unsigned int virq)
raw_spin_unlock_irqrestore(&qe_ic_lock, flags);
}
-static void qe_ic_mask_irq(unsigned int virq)
+static void qe_ic_mask_irq(struct irq_data *d)
{
- struct qe_ic *qe_ic = qe_ic_from_irq(virq);
- unsigned int src = virq_to_hw(virq);
+ struct qe_ic *qe_ic = qe_ic_from_irq_data(d);
+ unsigned int src = virq_to_hw(d->irq);
unsigned long flags;
u32 temp;
@@ -238,9 +243,9 @@ static void qe_ic_mask_irq(unsigned int virq)
static struct irq_chip qe_ic_irq_chip = {
.name = "QEIC",
- .unmask = qe_ic_unmask_irq,
- .mask = qe_ic_mask_irq,
- .mask_ack = qe_ic_mask_irq,
+ .irq_unmask = qe_ic_unmask_irq,
+ .irq_mask = qe_ic_mask_irq,
+ .irq_mask_ack = qe_ic_mask_irq,
};
static int qe_ic_host_match(struct irq_host *h, struct device_node *node)
--
1.7.4
^ permalink raw reply related
* [PATCH v2 25/28] powerpc: sysdev/uic irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110308000015.GD16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/sysdev/uic.c | 59 +++++++++++++++++++++++----------------------
1 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 0038fb7..835f795 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -55,11 +55,11 @@ struct uic {
struct irq_host *irqhost;
};
-static void uic_unmask_irq(unsigned int virq)
+static void uic_unmask_irq(struct irq_data *d)
{
- struct irq_desc *desc = irq_to_desc(virq);
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
+ struct irq_desc *desc = irq_to_desc(d->irq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
unsigned long flags;
u32 er, sr;
@@ -74,10 +74,10 @@ static void uic_unmask_irq(unsigned int virq)
spin_unlock_irqrestore(&uic->lock, flags);
}
-static void uic_mask_irq(unsigned int virq)
+static void uic_mask_irq(struct irq_data *d)
{
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
unsigned long flags;
u32 er;
@@ -88,10 +88,10 @@ static void uic_mask_irq(unsigned int virq)
spin_unlock_irqrestore(&uic->lock, flags);
}
-static void uic_ack_irq(unsigned int virq)
+static void uic_ack_irq(struct irq_data *d)
{
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
unsigned long flags;
spin_lock_irqsave(&uic->lock, flags);
@@ -99,11 +99,11 @@ static void uic_ack_irq(unsigned int virq)
spin_unlock_irqrestore(&uic->lock, flags);
}
-static void uic_mask_ack_irq(unsigned int virq)
+static void uic_mask_ack_irq(struct irq_data *d)
{
- struct irq_desc *desc = irq_to_desc(virq);
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
+ struct irq_desc *desc = irq_to_desc(d->irq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
unsigned long flags;
u32 er, sr;
@@ -125,18 +125,18 @@ static void uic_mask_ack_irq(unsigned int virq)
spin_unlock_irqrestore(&uic->lock, flags);
}
-static int uic_set_irq_type(unsigned int virq, unsigned int flow_type)
+static int uic_set_irq_type(struct irq_data *d, unsigned int flow_type)
{
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
- struct irq_desc *desc = irq_to_desc(virq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
+ struct irq_desc *desc = irq_to_desc(d->irq);
unsigned long flags;
int trigger, polarity;
u32 tr, pr, mask;
switch (flow_type & IRQ_TYPE_SENSE_MASK) {
case IRQ_TYPE_NONE:
- uic_mask_irq(virq);
+ uic_mask_irq(d);
return 0;
case IRQ_TYPE_EDGE_RISING:
@@ -178,11 +178,11 @@ static int uic_set_irq_type(unsigned int virq, unsigned int flow_type)
static struct irq_chip uic_irq_chip = {
.name = "UIC",
- .unmask = uic_unmask_irq,
- .mask = uic_mask_irq,
- .mask_ack = uic_mask_ack_irq,
- .ack = uic_ack_irq,
- .set_type = uic_set_irq_type,
+ .irq_unmask = uic_unmask_irq,
+ .irq_mask = uic_mask_irq,
+ .irq_mask_ack = uic_mask_ack_irq,
+ .irq_ack = uic_ack_irq,
+ .irq_set_type = uic_set_irq_type,
};
static int uic_host_map(struct irq_host *h, unsigned int virq,
@@ -220,6 +220,7 @@ static struct irq_host_ops uic_host_ops = {
void uic_irq_cascade(unsigned int virq, struct irq_desc *desc)
{
+ struct irq_chip *chip = get_irq_desc_chip(desc);
struct uic *uic = get_irq_data(virq);
u32 msr;
int src;
@@ -227,9 +228,9 @@ void uic_irq_cascade(unsigned int virq, struct irq_desc *desc)
raw_spin_lock(&desc->lock);
if (desc->status & IRQ_LEVEL)
- desc->chip->mask(virq);
+ chip->irq_mask(&desc->irq_data);
else
- desc->chip->mask_ack(virq);
+ chip->irq_mask_ack(&desc->irq_data);
raw_spin_unlock(&desc->lock);
msr = mfdcr(uic->dcrbase + UIC_MSR);
@@ -244,9 +245,9 @@ void uic_irq_cascade(unsigned int virq, struct irq_desc *desc)
uic_irq_ret:
raw_spin_lock(&desc->lock);
if (desc->status & IRQ_LEVEL)
- desc->chip->ack(virq);
- if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
- desc->chip->unmask(virq);
+ chip->irq_ack(&desc->irq_data);
+ if (!(desc->status & IRQ_DISABLED) && chip->irq_unmask)
+ chip->irq_unmask(&desc->irq_data);
raw_spin_unlock(&desc->lock);
}
--
1.7.4
^ permalink raw reply related
* [PATCH v2 26/28] powerpc: sysdev/xilinx_intc irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110308000018.GE16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/sysdev/xilinx_intc.c | 48 +++++++++++++++++++-----------------
1 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index 1e0ccfa..7436f3e 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -69,17 +69,17 @@ static unsigned char xilinx_intc_map_senses[] = {
*
* IRQ Chip common (across level and edge) operations
*/
-static void xilinx_intc_mask(unsigned int virq)
+static void xilinx_intc_mask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void * regs = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void * regs = irq_data_get_irq_chip_data(d);
pr_debug("mask: %d\n", irq);
out_be32(regs + XINTC_CIE, 1 << irq);
}
-static int xilinx_intc_set_type(unsigned int virq, unsigned int flow_type)
+static int xilinx_intc_set_type(struct irq_data *d, unsigned int flow_type)
{
- struct irq_desc *desc = irq_to_desc(virq);
+ struct irq_desc *desc = irq_to_desc(d->irq);
desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
@@ -91,10 +91,10 @@ static int xilinx_intc_set_type(unsigned int virq, unsigned int flow_type)
/*
* IRQ Chip level operations
*/
-static void xilinx_intc_level_unmask(unsigned int virq)
+static void xilinx_intc_level_unmask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void * regs = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void * regs = irq_data_get_irq_chip_data(d);
pr_debug("unmask: %d\n", irq);
out_be32(regs + XINTC_SIE, 1 << irq);
@@ -107,37 +107,37 @@ static void xilinx_intc_level_unmask(unsigned int virq)
static struct irq_chip xilinx_intc_level_irqchip = {
.name = "Xilinx Level INTC",
- .mask = xilinx_intc_mask,
- .mask_ack = xilinx_intc_mask,
- .unmask = xilinx_intc_level_unmask,
- .set_type = xilinx_intc_set_type,
+ .irq_mask = xilinx_intc_mask,
+ .irq_mask_ack = xilinx_intc_mask,
+ .irq_unmask = xilinx_intc_level_unmask,
+ .irq_set_type = xilinx_intc_set_type,
};
/*
* IRQ Chip edge operations
*/
-static void xilinx_intc_edge_unmask(unsigned int virq)
+static void xilinx_intc_edge_unmask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void *regs = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void *regs = irq_data_get_irq_chip_data(d);
pr_debug("unmask: %d\n", irq);
out_be32(regs + XINTC_SIE, 1 << irq);
}
-static void xilinx_intc_edge_ack(unsigned int virq)
+static void xilinx_intc_edge_ack(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void * regs = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void * regs = irq_data_get_irq_chip_data(d);
pr_debug("ack: %d\n", irq);
out_be32(regs + XINTC_IAR, 1 << irq);
}
static struct irq_chip xilinx_intc_edge_irqchip = {
.name = "Xilinx Edge INTC",
- .mask = xilinx_intc_mask,
- .unmask = xilinx_intc_edge_unmask,
- .ack = xilinx_intc_edge_ack,
- .set_type = xilinx_intc_set_type,
+ .irq_mask = xilinx_intc_mask,
+ .irq_unmask = xilinx_intc_edge_unmask,
+ .irq_ack = xilinx_intc_edge_ack,
+ .irq_set_type = xilinx_intc_set_type,
};
/*
@@ -229,12 +229,14 @@ int xilinx_intc_get_irq(void)
*/
static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc)
{
+ struct irq_chip *chip = get_irq_desc_chip(desc);
unsigned int cascade_irq = i8259_irq();
+
if (cascade_irq)
generic_handle_irq(cascade_irq);
/* Let xilinx_intc end the interrupt */
- desc->chip->unmask(irq);
+ chip->irq_unmask(&desc->irq_data);
}
static void __init xilinx_i8259_setup_cascade(void)
--
1.7.4
^ permalink raw reply related
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 10:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299639487.22236.256.camel@pasglop>
On Wed, 2011-03-09 at 13:58 +1100, Benjamin Herrenschmidt wrote:
> So I've been experiencing hangs shortly after boot with recent kernels
> on a Power7 machine. I was testing with PREEMPT & HZ=3D1024 which might
> increase the frequency of the problem but I don't think they are
> necessary to expose it.
>=20
> From what I've figured out, when the machine hangs, it's essentially
> looping forever in update_sd_lb_stats(), due to a corrupted sd->groups
> list (in my cases, the list contains a loop that doesn't loop back
> the the first element).
>=20
> It appears that this corresponds to one CPU deciding to rebuild the
> sched domains. There's various reasons why that can happen, the typical
> one in our case is the new VPNH feature where the hypervisor informs us
> of a change in node affinity of our virtual processors. s390 has a
> similar feature and should be affected as well.
Ahh, so that's triggering it :-), just curious, how often does the HV do
that to you?
> I suspect the problem could be reproduced on x86 by hammering the sysfs
> file that can be used to trigger a rebuild as well on a sufficently
> large machine.
Should, yeah, regular hotplug is racy too.
> From what I can tell, there's some missing locking here between
> rebuilding the domains and find_busiest_group.=20
init_sched_build_groups() races against pretty much all sched_group
iterations, like the one in update_sd_lb_stats() which is the most
common one and the one you're getting stuck in.
> I haven't quite got my
> head around how that -should- be done, though, as I an really not very
> familiar with that code.=20
:-)
> For example, I don't quite get when domains are
> attached to an rq, and whether code like build_numa_sched_groups() which
> allocates groups and attach them to sched domains sd->groups does it on
> a "live" domain or not (in that case, there's a problem since it kmalloc
> and attaches the uninitialized result immediately).
No, the domain stuff is good, we allocate new domains and have a
synchronize_sched() between us installing the new ones and freeing the
old ones.
But the sched_group list is as said rather icky.
> I don't believe I understand enough of the scheduler to fix that quickly
> and I'm really bogged down with some other urgent stuff, so I would very
> much appreciate if you could provide some assistance here, even if it's
> just in the form of suggestions/hints.
Yeah, sched_group rebuild is racy as hell, I haven't really managed to
come up with a sane fix yet, will poke at it.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 11:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299665998.2308.2753.camel@twins>
On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > It appears that this corresponds to one CPU deciding to rebuild the
> > sched domains. There's various reasons why that can happen, the typical
> > one in our case is the new VPNH feature where the hypervisor informs us
> > of a change in node affinity of our virtual processors. s390 has a
> > similar feature and should be affected as well.
>=20
> Ahh, so that's triggering it :-), just curious, how often does the HV do
> that to you?=20
OK, so Ben told me on IRC this can happen quite frequently, to which I
must ask WTF were you guys smoking? Flipping the CPU topology every time
the HV scheduler does something funny is quite insane. And you did that
without ever talking to the scheduler folks, not cool.
That is of course aside from the fact that we have a real bug there that
needs fixing, but really guys, WTF!
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Américo Wang @ 2011-03-09 12:20 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar
Cc: kexec, linux-kernel, linuxppc-dev, Eric W. Biederman, akpm,
Anton Blanchard
In-Reply-To: <4D771EE6.5050404@linux.vnet.ibm.com>
On Wed, Mar 09, 2011 at 12:02:06PM +0530, Mahesh Jagannath Salgaonkar wrote:
>On 08/25/2010 06:07 AM, Eric W. Biederman wrote:
>> Anton Blanchard <anton@samba.org> writes:
>>
>>> On ppc64 the crashkernel region almost always overlaps an area of firmware.
>>> This works fine except when using the sysfs interface to reduce the kdump
>>> region. If we free the firmware area we are guaranteed to crash.
>>
>> That is ppc64 bug. firmware should not be in the reserved region. Any
>> random kernel like thing can be put in to that region at any valid
>> address and the fact that shrinking the region frees your firmware means
>> that using that region could also stomp your firmware (which I assume
>> would be a bad thing).
>The issue only happens while shrinking the region using sysfs interface.
>We already have checks in kexec for not to stomp over on the firmware
>overlap area while loading capture kernel. Currently we do a top-down
>allocation for the firmware region which means it sits at the top of the
>RMO, right in the middle of the crashdump region. We can not move the
>crashkernel region beyond firmware region because kernel needs its some
>of memory in RMO region.
The crashkernel region is specified via kernel cmdline, so why
not just drop a failure when it overlaps with RMO region?
Am I missing something?
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Anton Blanchard @ 2011-03-09 12:46 UTC (permalink / raw)
To: Américo Wang
Cc: Mahesh Jagannath Salgaonkar, kexec, linux-kernel, linuxppc-dev,
Eric W. Biederman, akpm
In-Reply-To: <20110309122046.GC16951@cr0.redhat.com>
Hi,
> The crashkernel region is specified via kernel cmdline, so why
> not just drop a failure when it overlaps with RMO region?
> Am I missing something?
Unfortunately a ppc64 kernel requires a chunk of RMO memory. We would
need the ability to specify multiple crashkernel regions - about 32MB
in the RMO and the rest can be anywhere. That sounds pretty fragile for
a user to configure successfully on the cmdline.
Thats why the ppc64 crashkernel region begins mid way through the RMO
region. It means both kernels get a chunk of RMO and we only have to
deal with one crashkernel reservation in all the tools and
documentation.
Anton
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 13:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299665998.2308.2753.camel@twins>
On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> No, the domain stuff is good, we allocate new domains and have a
> synchronize_sched() between us installing the new ones and freeing the
> old ones.=20
Gah, if only..
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
From: Michel Lespinasse @ 2011-03-09 13:09 UTC (permalink / raw)
To: Stephen Wilson
Cc: linux-s390, Andi Kleen, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, linuxppc-dev, Andrew Morton
In-Reply-To: <1299630721-4337-1-git-send-email-wilsons@start.ca>
On Tue, Mar 8, 2011 at 4:31 PM, Stephen Wilson <wilsons@start.ca> wrote:
> Morally, the question of whether an address lies in a gate vma should be =
asked
> with respect to an mm, not a particular task.
>
> Practically, dropping the dependency on task_struct will help make curren=
t and
> future operations on mm's more flexible and convenient. =A0In particular,=
it
> allows some code paths to avoid the need to hold task_lock.
Reviewed-by: Michel Lespinasse <walken@google.com>
May I suggest ia32_compat instead of just compat for the flag name ?
--=20
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Martin Schwidefsky @ 2011-03-09 13:15 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <1299670429.2308.2834.camel@twins>
On Wed, 09 Mar 2011 12:33:49 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > It appears that this corresponds to one CPU deciding to rebuild the
> > > sched domains. There's various reasons why that can happen, the typical
> > > one in our case is the new VPNH feature where the hypervisor informs us
> > > of a change in node affinity of our virtual processors. s390 has a
> > > similar feature and should be affected as well.
> >
> > Ahh, so that's triggering it :-), just curious, how often does the HV do
> > that to you?
>
> OK, so Ben told me on IRC this can happen quite frequently, to which I
> must ask WTF were you guys smoking? Flipping the CPU topology every time
> the HV scheduler does something funny is quite insane. And you did that
> without ever talking to the scheduler folks, not cool.
>
> That is of course aside from the fact that we have a real bug there that
> needs fixing, but really guys, WTF!
Just for info, on s390 the topology change events are rather infrequent.
They do happen e.g. after an LPAR has been activated and the LPAR
hypervisor needs to reshuffle the CPUs of the different nodes.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 13:19 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <20110309141548.722e4f56@mschwide.boeblingen.de.ibm.com>
On Wed, 2011-03-09 at 14:15 +0100, Martin Schwidefsky wrote:
> On Wed, 09 Mar 2011 12:33:49 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> > On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > > It appears that this corresponds to one CPU deciding to rebuild the
> > > > sched domains. There's various reasons why that can happen, the typ=
ical
> > > > one in our case is the new VPNH feature where the hypervisor inform=
s us
> > > > of a change in node affinity of our virtual processors. s390 has a
> > > > similar feature and should be affected as well.
> > >=20
> > > Ahh, so that's triggering it :-), just curious, how often does the HV=
do
> > > that to you?=20
> >=20
> > OK, so Ben told me on IRC this can happen quite frequently, to which I
> > must ask WTF were you guys smoking? Flipping the CPU topology every tim=
e
> > the HV scheduler does something funny is quite insane. And you did that
> > without ever talking to the scheduler folks, not cool.
> >=20
> > That is of course aside from the fact that we have a real bug there tha=
t
> > needs fixing, but really guys, WTF!
>=20
> Just for info, on s390 the topology change events are rather infrequent.
> They do happen e.g. after an LPAR has been activated and the LPAR
> hypervisor needs to reshuffle the CPUs of the different nodes.
But if you don't also update the cpu->node memory mappings (which I
think it near impossible) what good is it to change the scheduler
topology?
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Martin Schwidefsky @ 2011-03-09 13:31 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <1299676769.2308.2944.camel@twins>
On Wed, 09 Mar 2011 14:19:29 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2011-03-09 at 14:15 +0100, Martin Schwidefsky wrote:
> > On Wed, 09 Mar 2011 12:33:49 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > > > It appears that this corresponds to one CPU deciding to rebuild the
> > > > > sched domains. There's various reasons why that can happen, the typical
> > > > > one in our case is the new VPNH feature where the hypervisor informs us
> > > > > of a change in node affinity of our virtual processors. s390 has a
> > > > > similar feature and should be affected as well.
> > > >
> > > > Ahh, so that's triggering it :-), just curious, how often does the HV do
> > > > that to you?
> > >
> > > OK, so Ben told me on IRC this can happen quite frequently, to which I
> > > must ask WTF were you guys smoking? Flipping the CPU topology every time
> > > the HV scheduler does something funny is quite insane. And you did that
> > > without ever talking to the scheduler folks, not cool.
> > >
> > > That is of course aside from the fact that we have a real bug there that
> > > needs fixing, but really guys, WTF!
> >
> > Just for info, on s390 the topology change events are rather infrequent.
> > They do happen e.g. after an LPAR has been activated and the LPAR
> > hypervisor needs to reshuffle the CPUs of the different nodes.
>
> But if you don't also update the cpu->node memory mappings (which I
> think it near impossible) what good is it to change the scheduler
> topology?
The memory for the different LPARs is striped over all nodes (or books as we
call them). We heavily rely on the large shared cache between the books to hide
the different memory access latencies.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 13:33 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <20110309143152.3cc6c191@mschwide.boeblingen.de.ibm.com>
On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > But if you don't also update the cpu->node memory mappings (which I
> > think it near impossible) what good is it to change the scheduler
> > topology?
>=20
> The memory for the different LPARs is striped over all nodes (or books as=
we
> call them). We heavily rely on the large shared cache between the books t=
o hide
> the different memory access latencies.=20
Right, so effectively you don't have NUMA due to that striping. So why
then change the CPU topology? Simply create a topology without NUMA and
keep it static, that accurately reflects the memory topology.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Martin Schwidefsky @ 2011-03-09 13:46 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <1299677636.2308.2960.camel@twins>
On Wed, 09 Mar 2011 14:33:56 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > > But if you don't also update the cpu->node memory mappings (which I
> > > think it near impossible) what good is it to change the scheduler
> > > topology?
> >
> > The memory for the different LPARs is striped over all nodes (or books as we
> > call them). We heavily rely on the large shared cache between the books to hide
> > the different memory access latencies.
>
> Right, so effectively you don't have NUMA due to that striping. So why
> then change the CPU topology? Simply create a topology without NUMA and
> keep it static, that accurately reflects the memory topology.
Well the CPU topology can change due to different grouping of logical CPUs
dependent on which LPARs are activated. And we effectively do not have a
memory topology, only CPU. Its basically all about caches, we want to
reflect the distance between CPUs over the up to 4 cache levels.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 13:54 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <20110309144636.3f0899d1@mschwide.boeblingen.de.ibm.com>
On Wed, 2011-03-09 at 14:46 +0100, Martin Schwidefsky wrote:
> On Wed, 09 Mar 2011 14:33:56 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> > On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > > > But if you don't also update the cpu->node memory mappings (which I
> > > > think it near impossible) what good is it to change the scheduler
> > > > topology?
> > >=20
> > > The memory for the different LPARs is striped over all nodes (or book=
s as we
> > > call them). We heavily rely on the large shared cache between the boo=
ks to hide
> > > the different memory access latencies.=20
> >=20
> > Right, so effectively you don't have NUMA due to that striping. So why
> > then change the CPU topology? Simply create a topology without NUMA and
> > keep it static, that accurately reflects the memory topology.
>=20
> Well the CPU topology can change due to different grouping of logical CPU=
s
> dependent on which LPARs are activated. And we effectively do not have a
> memory topology, only CPU. Its basically all about caches, we want to
> reflect the distance between CPUs over the up to 4 cache levels.
Right, so I consider caches to be part of the memory topology, anyway,
if this all is very rare then yeah, that works out.
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
From: Stephen Wilson @ 2011-03-09 14:14 UTC (permalink / raw)
To: Michel Lespinasse
Cc: linux-s390, Andi Kleen, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, linuxppc-dev, Andrew Morton
In-Reply-To: <AANLkTikTEi8uKeCfPLoenNx9g6fLyAqNqfVdR=4KzNB3@mail.gmail.com>
On Wed, Mar 09, 2011 at 05:09:09AM -0800, Michel Lespinasse wrote:
> On Tue, Mar 8, 2011 at 4:31 PM, Stephen Wilson <wilsons@start.ca> wrote:
> > Morally, the question of whether an address lies in a gate vma should be asked
> > with respect to an mm, not a particular task.
> >
> > Practically, dropping the dependency on task_struct will help make current and
> > future operations on mm's more flexible and convenient. In particular, it
> > allows some code paths to avoid the need to hold task_lock.
>
> Reviewed-by: Michel Lespinasse <walken@google.com>
>
> May I suggest ia32_compat instead of just compat for the flag name ?
Yes, sounds good to me. Will change in the next iteration.
Thanks for the review!
> --
> Michel "Walken" Lespinasse
> A program is never fully debugged until the last user dies.
--
steve
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Américo Wang @ 2011-03-09 14:21 UTC (permalink / raw)
To: Anton Blanchard
Cc: Mahesh Jagannath Salgaonkar, kexec, linux-kernel, linuxppc-dev,
Eric W. Biederman, Américo Wang, akpm
In-Reply-To: <20110309234657.264d3080@kryten>
On Wed, Mar 09, 2011 at 11:46:57PM +1100, Anton Blanchard wrote:
>
>Hi,
>
>> The crashkernel region is specified via kernel cmdline, so why
>> not just drop a failure when it overlaps with RMO region?
>> Am I missing something?
>
>Unfortunately a ppc64 kernel requires a chunk of RMO memory. We would
>need the ability to specify multiple crashkernel regions - about 32MB
>in the RMO and the rest can be anywhere. That sounds pretty fragile for
>a user to configure successfully on the cmdline.
>
>Thats why the ppc64 crashkernel region begins mid way through the RMO
>region. It means both kernels get a chunk of RMO and we only have to
>deal with one crashkernel reservation in all the tools and
>documentation.
>
So, when I specify 128M in cmdline, 32M of them are RMO, and the
rest 96M are normal memory? And when I want to free all of them,
actually the 32M RMO will never be freed?
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Steven Rostedt @ 2011-03-09 15:26 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299670429.2308.2834.camel@twins>
On Wed, Mar 09, 2011 at 12:33:49PM +0100, Peter Zijlstra wrote:
>
> That is of course aside from the fact that we have a real bug there that
> needs fixing, but really guys, WTF!
They just wanted to give you a very nice reproducer for that bug ;)
-- Steve
^ permalink raw reply
* [5200B/slightly ot] MPC52xx LPB FIFO memory requirements
From: Albrecht Dreß @ 2011-03-09 20:45 UTC (permalink / raw)
To: Linux PPC Development
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
Hi all,
I have a slightly off-topic question regarding the use of mpc52xx_lpbfifo_submit() & friends...
In struct mpc52xx_lpbfifo_request, the element 'data' (with address 'data_phys') is apparently the chunk of data which is transferred through bestcomm, right? Dumb question: has this chunk of memory to be DMA mem (i.e. allocated via dma_alloc_coherent), or is "normal" kernel memory (kmalloc) sufficient?
Thanks,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: disable MSI using new interface if possible
From: Michael Ellerman @ 2011-03-09 22:54 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <20110308053413.GA26971@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
On Mon, 2011-03-07 at 21:34 -0800, Nishanth Aravamudan wrote:
> On 03.03.2011 [23:24:44 -0800], Nishanth Aravamudan wrote:
> > On 04.03.2011 [14:01:24 +1100], Michael Ellerman wrote:
> > > Looking closer at your patch, now I don't understand :)
> > >
> > > + /*
> > > + * disabling MSI with the explicit interface also disables MSI-X
> > > + */
> > > + if (rtas_change_msi(pdn, RTAS_CHANGE_MSI_FN, 0) != 0) {
> > >
> > >
> > > So we first disable using function 3, which should:
> > >
> > > 3: Request to set to a new number of MSI interrupts (including set to 0)
> > >
> > > Which does not mention MSI-X at all, implying it has no effect on them.
> > > Which contradicts what you see, and the comment in the code?
> >
> > Thanks for the thorough review!
> >
> > Per PAPR 2.4 from Power.org, look at the page before that table, page
> > 169:
> >
> > "Specifying Function 3 (MSI) also disables MSI-X for the specified IOA
> > function, and likewise specifying Function 4 (MSI-X) disables MSI for
> > the IOA function....Specifying the Requested Number of Interrupts to
> > zero for either Function 3 or 4 removes all MSI & MSI-X interrupts from
> > the IOA function."
> >
> > So I'm relying on this aspect of PAPR being enforced by the firmware,
> > which I think it is in my testing.
>
> Given all that, do I have your Ack? :)
Indeed. Thanks for clarifying it.
Acked-by: Michael Ellerman <michael@ellerman.id.au>
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] powerpc/pseries: Disable VPNH feature
From: Benjamin Herrenschmidt @ 2011-03-09 23:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jesse Larrew
This feature triggers nasty races in the scheduler between the
rebuilding of the topology and the load balancing code, causing
the machine to hang.
Disable it for now until the races are fixed.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Jesse: I'm sending that to Linus now. We'll sort things out for the
next release.
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index fd48123..74f1baa 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1516,6 +1516,7 @@ int start_topology_update(void)
{
int rc = 0;
+#if 0 /* Disabled until races with load balancing are fixed */
if (firmware_has_feature(FW_FEATURE_VPHN) &&
get_lppaca()->shared_proc) {
vphn_enabled = 1;
@@ -1524,6 +1525,7 @@ int start_topology_update(void)
set_topology_timer();
rc = 1;
}
+#endif
return rc;
}
^ permalink raw reply related
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