* [PATCH v3 1/9] genirq: cosmetic: remove cur_regs
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 2/9] genirq: add mask_cache and pmask_cache into struct irq_chip_type Gerlando Falauto
` (11 subsequent siblings)
12 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
Since we already have an irq_data_get_chip_type() function which returns
a pointer to irq_chip_type, use that instead of cur_regs().
This will also simplify subsequent patches.
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
kernel/irq/generic-chip.c | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index c89295a..0e6ba78 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -16,11 +16,6 @@
static LIST_HEAD(gc_list);
static DEFINE_RAW_SPINLOCK(gc_lock);
-static inline struct irq_chip_regs *cur_regs(struct irq_data *d)
-{
- return &container_of(d->chip, struct irq_chip_type, chip)->regs;
-}
-
/**
* irq_gc_noop - NOOP function
* @d: irq_data
@@ -39,10 +34,11 @@ void irq_gc_noop(struct irq_data *d)
void irq_gc_mask_disable_reg(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- irq_reg_writel(mask, gc->reg_base + cur_regs(d)->disable);
+ irq_reg_writel(mask, gc->reg_base + ct->regs.disable);
gc->mask_cache &= ~mask;
irq_gc_unlock(gc);
}
@@ -57,11 +53,12 @@ void irq_gc_mask_disable_reg(struct irq_data *d)
void irq_gc_mask_set_bit(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
gc->mask_cache |= mask;
- irq_reg_writel(gc->mask_cache, gc->reg_base + cur_regs(d)->mask);
+ irq_reg_writel(gc->mask_cache, gc->reg_base + ct->regs.mask);
irq_gc_unlock(gc);
}
@@ -75,11 +72,12 @@ void irq_gc_mask_set_bit(struct irq_data *d)
void irq_gc_mask_clr_bit(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
gc->mask_cache &= ~mask;
- irq_reg_writel(gc->mask_cache, gc->reg_base + cur_regs(d)->mask);
+ irq_reg_writel(gc->mask_cache, gc->reg_base + ct->regs.mask);
irq_gc_unlock(gc);
}
@@ -93,10 +91,11 @@ void irq_gc_mask_clr_bit(struct irq_data *d)
void irq_gc_unmask_enable_reg(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- irq_reg_writel(mask, gc->reg_base + cur_regs(d)->enable);
+ irq_reg_writel(mask, gc->reg_base + ct->regs.enable);
gc->mask_cache |= mask;
irq_gc_unlock(gc);
}
@@ -108,10 +107,11 @@ void irq_gc_unmask_enable_reg(struct irq_data *d)
void irq_gc_ack_set_bit(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- irq_reg_writel(mask, gc->reg_base + cur_regs(d)->ack);
+ irq_reg_writel(mask, gc->reg_base + ct->regs.ack);
irq_gc_unlock(gc);
}
@@ -122,10 +122,11 @@ void irq_gc_ack_set_bit(struct irq_data *d)
void irq_gc_ack_clr_bit(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = ~(1 << (d->irq - gc->irq_base));
irq_gc_lock(gc);
- irq_reg_writel(mask, gc->reg_base + cur_regs(d)->ack);
+ irq_reg_writel(mask, gc->reg_base + ct->regs.ack);
irq_gc_unlock(gc);
}
@@ -136,11 +137,12 @@ void irq_gc_ack_clr_bit(struct irq_data *d)
void irq_gc_mask_disable_reg_and_ack(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- irq_reg_writel(mask, gc->reg_base + cur_regs(d)->mask);
- irq_reg_writel(mask, gc->reg_base + cur_regs(d)->ack);
+ irq_reg_writel(mask, gc->reg_base + ct->regs.mask);
+ irq_reg_writel(mask, gc->reg_base + ct->regs.ack);
irq_gc_unlock(gc);
}
@@ -151,10 +153,11 @@ void irq_gc_mask_disable_reg_and_ack(struct irq_data *d)
void irq_gc_eoi(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- irq_reg_writel(mask, gc->reg_base + cur_regs(d)->eoi);
+ irq_reg_writel(mask, gc->reg_base + ct->regs.eoi);
irq_gc_unlock(gc);
}
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 2/9] genirq: add mask_cache and pmask_cache into struct irq_chip_type
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 1/9] genirq: cosmetic: remove cur_regs Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-19 11:32 ` Thomas Gleixner
2013-03-18 14:00 ` [PATCH v3 3/9] gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type Gerlando Falauto
` (10 subsequent siblings)
12 siblings, 1 reply; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
Today the same interrupt mask cache (stored within struct irq_chip_generic)
is shared between all the irq_chip_type instances. As there are instances
where each irq_chip_type uses a distinct mask register (as it is the case
for Orion SoCs), sharing a single mask cache may be incorrect.
So add a distinct pointer for each irq_chip_type, which for now
points to the original mask register within irq_chip_generic.
So no functional changes here.
Reported-by: Joey Oravec <joravec@drewtech.com>
Signed-off-by: Simon Guinot <sguinot@lacie.com>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
include/linux/irq.h | 4 ++++
kernel/irq/generic-chip.c | 16 ++++++++++------
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index fdf2c4a..05d7fbd 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -636,6 +636,8 @@ struct irq_chip_regs {
* @regs: Register offsets for this chip
* @handler: Flow handler associated with this chip
* @type: Chip can handle these flow types
+ * @mask_cache: Cached mask register
+ * @pmask_cache: Pointer to cached mask register
*
* A irq_generic_chip can have several instances of irq_chip_type when
* it requires different functions and register offsets for different
@@ -646,6 +648,8 @@ struct irq_chip_type {
struct irq_chip_regs regs;
irq_flow_handler_t handler;
u32 type;
+ u32 mask_cache;
+ u32 *pmask_cache;
};
/**
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index 0e6ba78..c8ec24d 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -39,7 +39,7 @@ void irq_gc_mask_disable_reg(struct irq_data *d)
irq_gc_lock(gc);
irq_reg_writel(mask, gc->reg_base + ct->regs.disable);
- gc->mask_cache &= ~mask;
+ *ct->pmask_cache &= ~mask;
irq_gc_unlock(gc);
}
@@ -57,8 +57,8 @@ void irq_gc_mask_set_bit(struct irq_data *d)
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache |= mask;
- irq_reg_writel(gc->mask_cache, gc->reg_base + ct->regs.mask);
+ *ct->pmask_cache |= mask;
+ irq_reg_writel(*ct->pmask_cache, gc->reg_base + ct->regs.mask);
irq_gc_unlock(gc);
}
@@ -76,8 +76,8 @@ void irq_gc_mask_clr_bit(struct irq_data *d)
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache &= ~mask;
- irq_reg_writel(gc->mask_cache, gc->reg_base + ct->regs.mask);
+ *ct->pmask_cache &= ~mask;
+ irq_reg_writel(*ct->pmask_cache, gc->reg_base + ct->regs.mask);
irq_gc_unlock(gc);
}
@@ -96,7 +96,7 @@ void irq_gc_unmask_enable_reg(struct irq_data *d)
irq_gc_lock(gc);
irq_reg_writel(mask, gc->reg_base + ct->regs.enable);
- gc->mask_cache |= mask;
+ *ct->pmask_cache |= mask;
irq_gc_unlock(gc);
}
@@ -250,6 +250,10 @@ void irq_setup_generic_chip(struct irq_chip_generic *gc, u32 msk,
if (flags & IRQ_GC_INIT_MASK_CACHE)
gc->mask_cache = irq_reg_readl(gc->reg_base + ct->regs.mask);
+ /* Initialize mask cache pointer */
+ for (i = 0; i < gc->num_ct; i++)
+ ct[i].pmask_cache = &gc->mask_cache;
+
for (i = gc->irq_base; msk; msk >>= 1, i++) {
if (!(msk & 0x01))
continue;
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 2/9] genirq: add mask_cache and pmask_cache into struct irq_chip_type
2013-03-18 14:00 ` [PATCH v3 2/9] genirq: add mask_cache and pmask_cache into struct irq_chip_type Gerlando Falauto
@ 2013-03-19 11:32 ` Thomas Gleixner
0 siblings, 0 replies; 45+ messages in thread
From: Thomas Gleixner @ 2013-03-19 11:32 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 18 Mar 2013, Gerlando Falauto wrote:
> Today the same interrupt mask cache (stored within struct irq_chip_generic)
> is shared between all the irq_chip_type instances. As there are instances
> where each irq_chip_type uses a distinct mask register (as it is the case
> for Orion SoCs), sharing a single mask cache may be incorrect.
> So add a distinct pointer for each irq_chip_type, which for now
> points to the original mask register within irq_chip_generic.
> So no functional changes here.
>
> Reported-by: Joey Oravec <joravec@drewtech.com>
> Signed-off-by: Simon Guinot <sguinot@lacie.com>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Who wrote the patch?
If it was not you, then please add a From: real author next time.
If it was you, what are the other Signed-off-bys for?
SOB is added by the author and by people who handle the patch passing
it to the next person.
Thanks,
tglx
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 3/9] gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 1/9] genirq: cosmetic: remove cur_regs Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 2/9] genirq: add mask_cache and pmask_cache into struct irq_chip_type Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 4/9] MIPS: JZ4740: " Gerlando Falauto
` (9 subsequent siblings)
12 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
Since we have now introduced pmask_cache within irq_chip_type to also
handle per-chip-type mask registers, convert gpio-mvebu driver to use
this new pointer.
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
drivers/gpio/gpio-mvebu.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 456663c..81384f4 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -302,48 +302,52 @@ static void mvebu_gpio_irq_ack(struct irq_data *d)
static void mvebu_gpio_edge_irq_mask(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct mvebu_gpio_chip *mvchip = gc->private;
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache &= ~mask;
- writel_relaxed(gc->mask_cache, mvebu_gpioreg_edge_mask(mvchip));
+ *ct->pmask_cache &= ~mask;
+ writel_relaxed(*ct->pmask_cache, mvebu_gpioreg_edge_mask(mvchip));
irq_gc_unlock(gc);
}
static void mvebu_gpio_edge_irq_unmask(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct mvebu_gpio_chip *mvchip = gc->private;
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache |= mask;
- writel_relaxed(gc->mask_cache, mvebu_gpioreg_edge_mask(mvchip));
+ *ct->pmask_cache |= mask;
+ writel_relaxed(*ct->pmask_cache, mvebu_gpioreg_edge_mask(mvchip));
irq_gc_unlock(gc);
}
static void mvebu_gpio_level_irq_mask(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct mvebu_gpio_chip *mvchip = gc->private;
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache &= ~mask;
- writel_relaxed(gc->mask_cache, mvebu_gpioreg_level_mask(mvchip));
+ *ct->pmask_cache &= ~mask;
+ writel_relaxed(*ct->pmask_cache, mvebu_gpioreg_level_mask(mvchip));
irq_gc_unlock(gc);
}
static void mvebu_gpio_level_irq_unmask(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct mvebu_gpio_chip *mvchip = gc->private;
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache |= mask;
- writel_relaxed(gc->mask_cache, mvebu_gpioreg_level_mask(mvchip));
+ *ct->pmask_cache |= mask;
+ writel_relaxed(*ct->pmask_cache, mvebu_gpioreg_level_mask(mvchip));
irq_gc_unlock(gc);
}
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 4/9] MIPS: JZ4740: convert to usage of *pmask_cache within irq_chip_type
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (2 preceding siblings ...)
2013-03-18 14:00 ` [PATCH v3 3/9] gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 5/9] ARM: SAMSUNG: " Gerlando Falauto
` (8 subsequent siblings)
12 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
Since we have now introduced pmask_cache within irq_chip_type to also
handle per-chip-type mask registers, convert jz4740 irq driver to use
this new pointer.
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
arch/mips/jz4740/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/jz4740/irq.c b/arch/mips/jz4740/irq.c
index fc57ded..228ee33 100644
--- a/arch/mips/jz4740/irq.c
+++ b/arch/mips/jz4740/irq.c
@@ -68,7 +68,8 @@ void jz4740_irq_suspend(struct irq_data *data)
void jz4740_irq_resume(struct irq_data *data)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
- jz4740_irq_set_mask(gc, gc->mask_cache);
+ struct irq_chip_type *ct = irq_data_get_irq_chip_type(data);
+ jz4740_irq_set_mask(gc, *ct->pmask_cache);
}
static struct irqaction jz4740_cascade_action = {
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 5/9] ARM: SAMSUNG: convert to usage of *pmask_cache within irq_chip_type
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (3 preceding siblings ...)
2013-03-18 14:00 ` [PATCH v3 4/9] MIPS: JZ4740: " Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 6/9] genirq: rename mask_cache to shared_mask_cache Gerlando Falauto
` (7 subsequent siblings)
12 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
Since we have now introduced pmask_cache within irq_chip_type to also
handle per-chip-type mask registers, convert samsung irq-vic-timer driver
to use this new pointer.
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
arch/arm/plat-samsung/irq-vic-timer.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-samsung/irq-vic-timer.c b/arch/arm/plat-samsung/irq-vic-timer.c
index f980cf3..a37ded2 100644
--- a/arch/arm/plat-samsung/irq-vic-timer.c
+++ b/arch/arm/plat-samsung/irq-vic-timer.c
@@ -37,9 +37,11 @@ static void s3c_irq_demux_vic_timer(unsigned int irq, struct irq_desc *desc)
static void s3c_irq_timer_ack(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_irq_chip_type(d);
+
u32 mask = (1 << 5) << (d->irq - gc->irq_base);
- irq_reg_writel(mask | gc->mask_cache, gc->reg_base);
+ irq_reg_writel(mask | *ct->pmask_cache, gc->reg_base);
}
/**
@@ -89,7 +91,7 @@ void __init s3c_init_vic_timer_irq(unsigned int num, unsigned int timer_irq)
irq_setup_generic_chip(s3c_tgc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
/* Clear the upper bits of the mask_cache*/
- s3c_tgc->mask_cache &= 0x1f;
+ *ct->pmask_cache &= 0x1f;
for (i = 0; i < num; i++, timer_irq++) {
irq_set_chained_handler(pirq[i], s3c_irq_demux_vic_timer);
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 6/9] genirq: rename mask_cache to shared_mask_cache
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (4 preceding siblings ...)
2013-03-18 14:00 ` [PATCH v3 5/9] ARM: SAMSUNG: " Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 7/9] genirq: handle separate mask registers Gerlando Falauto
` (6 subsequent siblings)
12 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
after introducing pmask_cached pointer within irq_chip_type, rename
mask_cache into shared_mask_cache so to state clearly that drivers
should not use it anymore, but should only access *pmask_cache from
irq_chip_type instead.
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
include/linux/irq.h | 4 ++--
kernel/irq/generic-chip.c | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 05d7fbd..5aca310 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -658,7 +658,7 @@ struct irq_chip_type {
* @reg_base: Register base address (virtual)
* @irq_base: Interrupt base nr for this chip
* @irq_cnt: Number of interrupts handled by this chip
- * @mask_cache: Cached mask register
+ * @shared_mask_cache: Cached mask register shared among all irq_chip_type's
* @type_cache: Cached type register
* @polarity_cache: Cached polarity register
* @wake_enabled: Interrupt can wakeup from suspend
@@ -679,7 +679,7 @@ struct irq_chip_generic {
void __iomem *reg_base;
unsigned int irq_base;
unsigned int irq_cnt;
- u32 mask_cache;
+ u32 shared_mask_cache;
u32 type_cache;
u32 polarity_cache;
u32 wake_enabled;
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index c8ec24d..b5cb991 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -248,11 +248,12 @@ void irq_setup_generic_chip(struct irq_chip_generic *gc, u32 msk,
/* Init mask cache ? */
if (flags & IRQ_GC_INIT_MASK_CACHE)
- gc->mask_cache = irq_reg_readl(gc->reg_base + ct->regs.mask);
+ gc->shared_mask_cache =
+ irq_reg_readl(gc->reg_base + ct->regs.mask);
/* Initialize mask cache pointer */
for (i = 0; i < gc->num_ct; i++)
- ct[i].pmask_cache = &gc->mask_cache;
+ ct[i].pmask_cache = &gc->shared_mask_cache;
for (i = gc->irq_base; msk; msk >>= 1, i++) {
if (!(msk & 0x01))
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 7/9] genirq: handle separate mask registers
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (5 preceding siblings ...)
2013-03-18 14:00 ` [PATCH v3 6/9] genirq: rename mask_cache to shared_mask_cache Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 8/9] orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS Gerlando Falauto
` (5 subsequent siblings)
12 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
There are cases where all irq_chip_type instances have separate mask registers,
making a shared mask register cache unsuitable for the purpose.
So introduce a new flag IRQ_GC_SEPARATE_MASK_REGISTERS to explicitly enable
this separate treatment.
When this flag is not set, pointers for all irq_chip_type instances point
to the the shared mask register as it has been done so far.
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
include/linux/irq.h | 1 +
kernel/irq/generic-chip.c | 15 +++++++++++----
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 5aca310..9feb06f 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -700,6 +700,7 @@ struct irq_chip_generic {
enum irq_gc_flags {
IRQ_GC_INIT_MASK_CACHE = 1 << 0,
IRQ_GC_INIT_NESTED_LOCK = 1 << 1,
+ IRQ_GC_SEPARATE_MASK_REGISTERS = 1 << 2,
};
/* Generic chip callback functions */
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index b5cb991..ae5ce41 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -241,19 +241,26 @@ void irq_setup_generic_chip(struct irq_chip_generic *gc, u32 msk,
{
struct irq_chip_type *ct = gc->chip_types;
unsigned int i;
+ bool mskperct = flags & IRQ_GC_SEPARATE_MASK_REGISTERS;
+ bool mskinit = flags & IRQ_GC_INIT_MASK_CACHE;
raw_spin_lock(&gc_lock);
list_add_tail(&gc->list, &gc_list);
raw_spin_unlock(&gc_lock);
/* Init mask cache ? */
- if (flags & IRQ_GC_INIT_MASK_CACHE)
+ if (mskinit && !mskperct)
gc->shared_mask_cache =
irq_reg_readl(gc->reg_base + ct->regs.mask);
- /* Initialize mask cache pointer */
- for (i = 0; i < gc->num_ct; i++)
- ct[i].pmask_cache = &gc->shared_mask_cache;
+ /* Initialize mask cache pointers */
+ for (i = 0; i < gc->num_ct; i++) {
+ ct[i].pmask_cache = mskperct ?
+ &ct[i].mask_cache : &gc->shared_mask_cache;
+ if (mskinit && mskperct)
+ ct[i].mask_cache =
+ irq_reg_readl(gc->reg_base + ct[i].regs.mask);
+ }
for (i = gc->irq_base; msk; msk >>= 1, i++) {
if (!(msk & 0x01))
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 8/9] orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (6 preceding siblings ...)
2013-03-18 14:00 ` [PATCH v3 7/9] genirq: handle separate mask registers Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-18 14:00 ` [PATCH v3 9/9] gpio: mvebu: " Gerlando Falauto
` (4 subsequent siblings)
12 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
enable handling of separate mask registers for Orion SoC GPIOs,
fixing indeed the regression introduced by e59347a
"arm: orion: Use generic irq chip".
Reported-by: Joey Oravec <joravec@drewtech.com>
Signed-off-by: Simon Guinot <sguinot@lacie.com>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
arch/arm/plat-orion/gpio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-orion/gpio.c b/arch/arm/plat-orion/gpio.c
index c29ee7e..a4dc04a 100644
--- a/arch/arm/plat-orion/gpio.c
+++ b/arch/arm/plat-orion/gpio.c
@@ -522,7 +522,8 @@ void __init orion_gpio_init(struct device_node *np,
ct->handler = handle_edge_irq;
ct->chip.name = ochip->chip.label;
- irq_setup_generic_chip(gc, IRQ_MSK(ngpio), IRQ_GC_INIT_MASK_CACHE,
+ irq_setup_generic_chip(gc, IRQ_MSK(ngpio), IRQ_GC_INIT_MASK_CACHE |
+ IRQ_GC_SEPARATE_MASK_REGISTERS,
IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
/* Setup irq domain on top of the generic chip. */
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 9/9] gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (7 preceding siblings ...)
2013-03-18 14:00 ` [PATCH v3 8/9] orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS Gerlando Falauto
@ 2013-03-18 14:00 ` Gerlando Falauto
2013-03-18 14:28 ` [PATCH v3 0/9] refactoring for mask_cache Simon Guinot
` (3 subsequent siblings)
12 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
enable handling of separate mask registers for all three SoC variants
handled by this driver.
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
---
drivers/gpio/gpio-mvebu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 81384f4..c01376d 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -660,7 +660,8 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
ct->handler = handle_edge_irq;
ct->chip.name = mvchip->chip.label;
- irq_setup_generic_chip(gc, IRQ_MSK(ngpios), 0,
+ irq_setup_generic_chip(gc, IRQ_MSK(ngpios),
+ IRQ_GC_SEPARATE_MASK_REGISTERS,
IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
/* Setup irq domain on top of the generic chip. */
--
1.7.10.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (8 preceding siblings ...)
2013-03-18 14:00 ` [PATCH v3 9/9] gpio: mvebu: " Gerlando Falauto
@ 2013-03-18 14:28 ` Simon Guinot
2013-03-18 14:39 ` Simon Guinot
2013-03-19 10:03 ` Ezequiel Garcia
` (2 subsequent siblings)
12 siblings, 1 reply; 45+ messages in thread
From: Simon Guinot @ 2013-03-18 14:28 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> Hi everyone,
> here is a patchset to address the issue found with Orion, in incremental
> stages as Thomas suggested.
> a) we introduce the new fields and pointer (though only the shared one is used)
> b) we convert all drivers to use it
> c) we rename the field so to force the use of the per-ct pointer
> d) we add per-ct mask cache, provided the new flag
> IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> e) we enable the flag for orion-gpio and mvebu drivers
>
> So even though I'm also providing changes for mvebu, I only
> tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
> We currently do not have a working 3.6+ configuration for our Kirkwood
> boards (3.6 is apparently where this mvebu gpio driver was introduced),
> so I would be glad if someone could give it a try.
> I also have no idea whether the three Marvell variants all have separate
> mask registers (which is what the last patch assumes).
Accordingly to MV78230/78x60 (Armada-XP) functional specification, we
have separate mask registers for the GPIO level and edge interrupts.
I believe that the GPIO mask register is only shared on Orion and
Kirkwood based SoCs.
Regards,
Simon
>
> Gerlando Falauto (9):
> genirq: cosmetic: remove cur_regs
> genirq: add mask_cache and pmask_cache into struct irq_chip_type
> gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type
> MIPS: JZ4740: convert to usage of *pmask_cache within irq_chip_type
> ARM: SAMSUNG: convert to usage of *pmask_cache within irq_chip_type
> genirq: rename mask_cache to shared_mask_cache
> genirq: handle separate mask registers
> orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS
> gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS
>
> arch/arm/plat-orion/gpio.c | 3 +-
> arch/arm/plat-samsung/irq-vic-timer.c | 6 ++--
> arch/mips/jz4740/irq.c | 3 +-
> drivers/gpio/gpio-mvebu.c | 23 ++++++++------
> include/linux/irq.h | 9 ++++--
> kernel/irq/generic-chip.c | 55 +++++++++++++++++++++------------
> 6 files changed, 64 insertions(+), 35 deletions(-)
>
> --
> 1.7.10.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130318/e0391611/attachment-0001.sig>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-18 14:28 ` [PATCH v3 0/9] refactoring for mask_cache Simon Guinot
@ 2013-03-18 14:39 ` Simon Guinot
0 siblings, 0 replies; 45+ messages in thread
From: Simon Guinot @ 2013-03-18 14:39 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 18, 2013 at 03:28:17PM +0100, Simon Guinot wrote:
> On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> > Hi everyone,
> > here is a patchset to address the issue found with Orion, in incremental
> > stages as Thomas suggested.
> > a) we introduce the new fields and pointer (though only the shared one is used)
> > b) we convert all drivers to use it
> > c) we rename the field so to force the use of the per-ct pointer
> > d) we add per-ct mask cache, provided the new flag
> > IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> > e) we enable the flag for orion-gpio and mvebu drivers
> >
> > So even though I'm also providing changes for mvebu, I only
> > tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
> > We currently do not have a working 3.6+ configuration for our Kirkwood
> > boards (3.6 is apparently where this mvebu gpio driver was introduced),
> > so I would be glad if someone could give it a try.
> > I also have no idea whether the three Marvell variants all have separate
> > mask registers (which is what the last patch assumes).
>
> Accordingly to MV78230/78x60 (Armada-XP) functional specification, we
> have separate mask registers for the GPIO level and edge interrupts.
>
> I believe that the GPIO mask register is only shared on Orion and
> Kirkwood based SoCs.
Of course, I was meaning that all the three Marvell variants (Orion,
Kirkwood and Armada) are using separate mask registers for the GPIO
interrupts :)
Simon
>
> Regards,
>
> Simon
>
> >
> > Gerlando Falauto (9):
> > genirq: cosmetic: remove cur_regs
> > genirq: add mask_cache and pmask_cache into struct irq_chip_type
> > gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type
> > MIPS: JZ4740: convert to usage of *pmask_cache within irq_chip_type
> > ARM: SAMSUNG: convert to usage of *pmask_cache within irq_chip_type
> > genirq: rename mask_cache to shared_mask_cache
> > genirq: handle separate mask registers
> > orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS
> > gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS
> >
> > arch/arm/plat-orion/gpio.c | 3 +-
> > arch/arm/plat-samsung/irq-vic-timer.c | 6 ++--
> > arch/mips/jz4740/irq.c | 3 +-
> > drivers/gpio/gpio-mvebu.c | 23 ++++++++------
> > include/linux/irq.h | 9 ++++--
> > kernel/irq/generic-chip.c | 55 +++++++++++++++++++++------------
> > 6 files changed, 64 insertions(+), 35 deletions(-)
> >
> > --
> > 1.7.10.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130318/cc8bb7cc/attachment-0001.sig>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (9 preceding siblings ...)
2013-03-18 14:28 ` [PATCH v3 0/9] refactoring for mask_cache Simon Guinot
@ 2013-03-19 10:03 ` Ezequiel Garcia
2013-03-19 10:09 ` Gerlando Falauto
2013-03-19 11:06 ` Jason Cooper
2013-03-21 10:51 ` Simon Guinot
2013-04-04 9:31 ` Ezequiel Garcia
12 siblings, 2 replies; 45+ messages in thread
From: Ezequiel Garcia @ 2013-03-19 10:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Gerlando,
On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> here is a patchset to address the issue found with Orion, in incremental
> stages as Thomas suggested.
> a) we introduce the new fields and pointer (though only the shared one is used)
> b) we convert all drivers to use it
> c) we rename the field so to force the use of the per-ct pointer
> d) we add per-ct mask cache, provided the new flag
> IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> e) we enable the flag for orion-gpio and mvebu drivers
>
> So even though I'm also providing changes for mvebu, I only
> tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
Great job! Since this is a really old bug you're fixing I believe that the
patchset applies for stable as well as mainline.
According to Documentation/stable_kernel_rules.txt all you need to do
is add a 'Cc: stable at vger.kernel.org' tag in your sign-off area.
Stable people will take care of picking the patch when it hits
mainline. You should receive a mail notification about patches
being included in stable kernels.
Thanks,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-19 10:03 ` Ezequiel Garcia
@ 2013-03-19 10:09 ` Gerlando Falauto
2013-03-19 11:25 ` Ezequiel Garcia
2013-03-19 11:06 ` Jason Cooper
1 sibling, 1 reply; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-19 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ezequiel,
On 03/19/2013 11:03 AM, Ezequiel Garcia wrote:
> Hi Gerlando,
>
thanks for the information!
[...]
> According to Documentation/stable_kernel_rules.txt all you need to do
> is add a 'Cc: stable at vger.kernel.org' tag in your sign-off area.
While we're at it, is there any other people I should have added in the
sign-off area? I mean, the original reporter (Joey Oravec), the author
of the first working fix (Simon Guinot), and so on... should they all be
quoted on *each* patch?
> Stable people will take care of picking the patch when it hits
> mainline. You should receive a mail notification about patches
> being included in stable kernels.
Thank you so much. I guess I'd rather have to wait for Thomas' blessing
first (maybe in the form of an Acked-By), don't I?
Thanks!
Gerlando
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-19 10:09 ` Gerlando Falauto
@ 2013-03-19 11:25 ` Ezequiel Garcia
0 siblings, 0 replies; 45+ messages in thread
From: Ezequiel Garcia @ 2013-03-19 11:25 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 19, 2013 at 11:09:36AM +0100, Gerlando Falauto wrote:
>
> thanks for the information!
>
You're welcome :-)
> > Stable people will take care of picking the patch when it hits
> > mainline. You should receive a mail notification about patches
> > being included in stable kernels.
>
> Thank you so much. I guess I'd rather have to wait for Thomas' blessing
> first (maybe in the form of an Acked-By), don't I?
>
AFAIK no, you don't have to wait for Thomas.
The stable rules are like this:
You submit a patch you think it applies for stable (see Documentation/stable_kernel_rules)
adding a 'Cc: stable at vger.kernel.org' tag. If the suitable maintainer accepts the patch,
it will eventually get merged, and when it hits mainline, the stable tag will tell stable
people to add this patch into their trees (anyone please correct me if I'm wrong).
As Jason suggests, you should also state which commit is your patch fixing.
Thanks,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-19 10:03 ` Ezequiel Garcia
2013-03-19 10:09 ` Gerlando Falauto
@ 2013-03-19 11:06 ` Jason Cooper
2013-03-19 11:10 ` Gerlando Falauto
2013-03-19 11:19 ` Ezequiel Garcia
1 sibling, 2 replies; 45+ messages in thread
From: Jason Cooper @ 2013-03-19 11:06 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 19, 2013 at 07:03:53AM -0300, Ezequiel Garcia wrote:
> Hi Gerlando,
>
> On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> > here is a patchset to address the issue found with Orion, in incremental
> > stages as Thomas suggested.
> > a) we introduce the new fields and pointer (though only the shared one is used)
> > b) we convert all drivers to use it
> > c) we rename the field so to force the use of the per-ct pointer
> > d) we add per-ct mask cache, provided the new flag
> > IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> > e) we enable the flag for orion-gpio and mvebu drivers
> >
> > So even though I'm also providing changes for mvebu, I only
> > tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
>
> Great job! Since this is a really old bug you're fixing I believe that the
> patchset applies for stable as well as mainline.
>
> According to Documentation/stable_kernel_rules.txt all you need to do
> is add a 'Cc: stable at vger.kernel.org' tag in your sign-off area.
>
> Stable people will take care of picking the patch when it hits
> mainline. You should receive a mail notification about patches
> being included in stable kernels.
Yes, and if you have an idea of when the regression was introduced,
perhaps even which commit, that would be *extremely* helpful.
Otherwise, the stable folks have to expend a lot of time tracking it
down.
thx,
Jason.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-19 11:06 ` Jason Cooper
@ 2013-03-19 11:10 ` Gerlando Falauto
2013-03-19 11:44 ` Jason Cooper
2013-03-19 11:19 ` Ezequiel Garcia
1 sibling, 1 reply; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-19 11:10 UTC (permalink / raw)
To: linux-arm-kernel
On 03/19/2013 12:06 PM, Jason Cooper wrote:
> On Tue, Mar 19, 2013 at 07:03:53AM -0300, Ezequiel Garcia wrote:
>> Hi Gerlando,
>>
>> On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
>>> here is a patchset to address the issue found with Orion, in incremental
>>> stages as Thomas suggested.
>>> a) we introduce the new fields and pointer (though only the shared one is used)
>>> b) we convert all drivers to use it
>>> c) we rename the field so to force the use of the per-ct pointer
>>> d) we add per-ct mask cache, provided the new flag
>>> IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
>>> e) we enable the flag for orion-gpio and mvebu drivers
>>>
>>> So even though I'm also providing changes for mvebu, I only
>>> tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
>>
>> Great job! Since this is a really old bug you're fixing I believe that the
>> patchset applies for stable as well as mainline.
>>
>> According to Documentation/stable_kernel_rules.txt all you need to do
>> is add a 'Cc: stable at vger.kernel.org' tag in your sign-off area.
>>
>> Stable people will take care of picking the patch when it hits
>> mainline. You should receive a mail notification about patches
>> being included in stable kernels.
>
> Yes, and if you have an idea of when the regression was introduced,
> perhaps even which commit, that would be *extremely* helpful.
Uhm, you're right, that piece of information sort of got lost while
reworking the whole thing (from a single patch to a 9-piece series!).
Here it is:
This fixes a regression introduced by e59347a
"arm: orion: Use generic irq chip".
Question is, where (out of the 9 patches) should that be mentioned?
On all of them?
> Otherwise, the stable folks have to expend a lot of time tracking it
> down.
Let's try and save them that... :-)
Thank you!
Gerlando
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-19 11:10 ` Gerlando Falauto
@ 2013-03-19 11:44 ` Jason Cooper
2013-03-19 11:56 ` Jason Cooper
0 siblings, 1 reply; 45+ messages in thread
From: Jason Cooper @ 2013-03-19 11:44 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 19, 2013 at 12:10:11PM +0100, Gerlando Falauto wrote:
> On 03/19/2013 12:06 PM, Jason Cooper wrote:
> >On Tue, Mar 19, 2013 at 07:03:53AM -0300, Ezequiel Garcia wrote:
> >>Hi Gerlando,
> >>
> >>On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> >>>here is a patchset to address the issue found with Orion, in incremental
> >>>stages as Thomas suggested.
> >>>a) we introduce the new fields and pointer (though only the shared one is used)
> >>>b) we convert all drivers to use it
> >>>c) we rename the field so to force the use of the per-ct pointer
> >>>d) we add per-ct mask cache, provided the new flag
> >>> IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> >>>e) we enable the flag for orion-gpio and mvebu drivers
> >>>
> >>>So even though I'm also providing changes for mvebu, I only
> >>>tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
> >>
> >>Great job! Since this is a really old bug you're fixing I believe that the
> >>patchset applies for stable as well as mainline.
> >>
> >>According to Documentation/stable_kernel_rules.txt all you need to do
> >>is add a 'Cc: stable at vger.kernel.org' tag in your sign-off area.
> >>
> >>Stable people will take care of picking the patch when it hits
> >>mainline. You should receive a mail notification about patches
> >>being included in stable kernels.
> >
> >Yes, and if you have an idea of when the regression was introduced,
> >perhaps even which commit, that would be *extremely* helpful.
>
> Uhm, you're right, that piece of information sort of got lost while
> reworking the whole thing (from a single patch to a 9-piece
> series!).
> Here it is:
>
> This fixes a regression introduced by e59347a
> "arm: orion: Use generic irq chip".
Great!
$ git tag --contains e59347a | grep '^v[23]\.[0-9]*\.' | \
sed -e 's/\.[0-9]*$/.x/' | sort -uV
v3.0.x
v3.1.x
v3.2.x
v3.3.x
v3.4.x
v3.5.x
v3.6.x
v3.7.x
v3.8.x
So:
Cc: <stable@vger.kernel.org> # 3.0.x
oughta do it for the first patch...
> Question is, where (out of the 9 patches) should that be mentioned?
> On all of them?
That's where it gets more complicated. Short answer, yes. The long
answer: You need to tell the stable team about the dependencies in your
series. After reading bullet 3 of "Procedures for submitting patches"
in stable_kernel_rules.txt, I would break up your series into two
chunks.
The first is that which can be applied to v3.0.x on up (everything
fixing the regression and plat-orion/gpio.c). The second being the fix
to gpio-mvebu.c. Anything affecting gpio-mvebu.c should only be for
v3.7.x and newer. It would still list the dependency on v3.0.x series
of patches.
Each patch in your series should then have a longer and longer list of
Cc: stable... lines as they list the previous patches in the series.
Those commit IDs are going to change once LinusW (I presume) applies
them to his tree, so he'll have to edit each commit message to point the
the correct commit.
LinusW, do you want me to handle this? If you prefer to take it:
Whole series:
Acked-by: Jason Cooper <jason@lakedaemon.net>
Gerlando, Feel free to ask if you have any questions.
Also note, this is something the sub-system maintainers usually handle.
We appreciate all the help we can get, though. ;-) Just letting us
know which patch introduced the regression makes this a lot easier.
thx,
Jason.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-19 11:44 ` Jason Cooper
@ 2013-03-19 11:56 ` Jason Cooper
2013-03-20 17:40 ` Gerlando Falauto
0 siblings, 1 reply; 45+ messages in thread
From: Jason Cooper @ 2013-03-19 11:56 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 19, 2013 at 07:44:31AM -0400, Jason Cooper wrote:
> Those commit IDs are going to change once LinusW (I presume) applies
> them to his tree, so he'll have to edit each commit message to point the
> the correct commit.
>
> LinusW, do you want me to handle this?
Never mind, coffee underflow to /dev/brain. One drawback to mutt, can't
view thread while typing messages...
> If you prefer to take it:
>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
for the plat-orion/gpio.c bits and if it helps, the gpio-mvebu.c bits.
thx,
Jason.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-19 11:56 ` Jason Cooper
@ 2013-03-20 17:40 ` Gerlando Falauto
2013-03-20 21:42 ` Thomas Gleixner
2013-03-21 10:59 ` Simon Guinot
0 siblings, 2 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-20 17:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
sorry about the delay (been busy with other stuff).
First of all thanks for your hints. I have some questions.
This is my first time, so please be gentle... :-)
On 03/19/2013 12:56 PM, Jason Cooper wrote:
> On Tue, Mar 19, 2013 at 07:44:31AM -0400, Jason Cooper wrote:
>> Those commit IDs are going to change once LinusW (I presume) applies
>> them to his tree, so he'll have to edit each commit message to point the
>> the correct commit.
>>
>> LinusW, do you want me to handle this?
>
> Never mind, coffee underflow to /dev/brain. One drawback to mutt, can't
> view thread while typing messages...
1) I had no idea who LinusW is, I assume Linus Walleij who should be the
maintainer of linux-gpio. And linux-gpio should have nothing to do with
this discussion... so I should assume you never mentioned him, right?
2) About the SOB part... most of this is inspired by Simon's original
(single) patch and Holger's reworking. Should they be given credit or
not? If yes, how? If I don't get an answer I would just assume no and
I'll take all the blame and credit all by myself. :-)
3) Jason, did you mean you would pull it to
http://git.infradead.org/users/jcooper/linux.git? Shall I change the SOB
lines and resubmit? Or should I submit it somewhere else instead?
4) About submitting to -stable, I guess it wouldn't make any sense until
it gets included upstream
(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ so to
speak). Is that right?
Or at least to jcooper's tree, through which it should eventually make
it mainline through a merge (therefore keeping its commit-id). That right?
I did read Documentation/stable_kernel_rules.txt and what I understand
is that it would be enough to submit to stable at vger.kernel.org only the
last one, while providing a list of
Cc: <stable@vger.kernel.org> # 3.0.x: 123456 first patch
Cc: <stable@vger.kernel.org> # 3.0.x: 123457 second patch
Cc: <stable@vger.kernel.org> # 3.0.x: 123458 third patch
using the mainstream (or jcooper's) commit IDs.
I don't know whether I'd have to repeat that for each version (3.0 will
include only a subset of this series, while 3.7 and following will need
the whole nine yards, and what's in between... well, something in between).
Please let me know what to do. Again, it's my first time so please be
gentle. :-)
Thanks again!
Gerlando
>> If you prefer to take it:
>>
>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>
> for the plat-orion/gpio.c bits and if it helps, the gpio-mvebu.c bits.
>
> thx,
>
> Jason.
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-20 17:40 ` Gerlando Falauto
@ 2013-03-20 21:42 ` Thomas Gleixner
2013-03-21 10:37 ` Gerlando Falauto
2013-03-21 10:59 ` Simon Guinot
1 sibling, 1 reply; 45+ messages in thread
From: Thomas Gleixner @ 2013-03-20 21:42 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 20 Mar 2013, Gerlando Falauto wrote:
> On 03/19/2013 12:56 PM, Jason Cooper wrote:
> > On Tue, Mar 19, 2013 at 07:44:31AM -0400, Jason Cooper wrote:
> > > Those commit IDs are going to change once LinusW (I presume) applies
> > > them to his tree, so he'll have to edit each commit message to point the
> > > the correct commit.
> > >
> > > LinusW, do you want me to handle this?
> >
> > Never mind, coffee underflow to /dev/brain. One drawback to mutt, can't
> > view thread while typing messages...
>
> 1) I had no idea who LinusW is, I assume Linus Walleij who should be the
> maintainer of linux-gpio. And linux-gpio should have nothing to do with this
> discussion... so I should assume you never mentioned him, right?
Jason had a brain hickup as he told. So please ignore that part :)
> 2) About the SOB part... most of this is inspired by Simon's original (single)
> patch and Holger's reworking. Should they be given credit or not? If yes, how?
> If I don't get an answer I would just assume no and I'll take all the blame
> and credit all by myself. :-)
Yes, you can give them credit. There are only a few official
"....-by:" tags, but you can chose from the inofficial ones:
Suggested-by:
Originally-by:
Original-patch-by:
Requested-by:
Original-idea-by:
Based-on-patch-by:
That's an incomplete list of already in-use tags, but one of those is
probably sufficient.
> 3) Jason, did you mean you would pull it to
> http://git.infradead.org/users/jcooper/linux.git? Shall I change the SOB lines
> and resubmit? Or should I submit it somewhere else instead?
That needs to go through my tree, really. And please just post it to
LKML with the relevant people CC'ed.
> 4) About submitting to -stable, I guess it wouldn't make any sense until it
> gets included upstream
Right. Though I'm a bit concerned about the amount of change
involved. So it's simpler to do:
Cc: <stable@vger.kernel.org> # simple resolution will be sent in reply
Then let the people who have this problem reply on that patch series
with a simple revert of that generic_chip() conversion commit
concering their particular subarchitecture instead of forcing a
nightmare of complex (and maybe untested) changes onto stable.
Thanks,
tglx
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-20 21:42 ` Thomas Gleixner
@ 2013-03-21 10:37 ` Gerlando Falauto
0 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-21 10:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
first of all thanks for your patience.
On 03/20/2013 10:42 PM, Thomas Gleixner wrote:
> On Wed, 20 Mar 2013, Gerlando Falauto wrote:
>> On 03/19/2013 12:56 PM, Jason Cooper wrote:
>>> On Tue, Mar 19, 2013 at 07:44:31AM -0400, Jason Cooper wrote:
>
>> 3) Jason, did you mean you would pull it to
>> http://git.infradead.org/users/jcooper/linux.git? Shall I change the SOB lines
>> and resubmit? Or should I submit it somewhere else instead?
>
> That needs to go through my tree, really. And please just post it to
> LKML with the relevant people CC'ed.
So drop linux-kernel-arm?
>> 4) About submitting to -stable, I guess it wouldn't make any sense until it
>> gets included upstream
>
> Right. Though I'm a bit concerned about the amount of change
> involved. So it's simpler to do:
>
> Cc: <stable@vger.kernel.org> # simple resolution will be sent in reply
You mean per-patch (in the SOB area)? Or just in the cover letter?
[Since when does the cover letter have a SOB area?]
Or just adding it as a plain "Cc:" recipient?
In any case, before waiting for mainstream inclusion?
I'm sorry for such stupid questions, but I'm getting even more confused...
> Then let the people who have this problem reply on that patch series
> with a simple revert of that generic_chip() conversion commit
> concering their particular subarchitecture instead of forcing a
> nightmare of complex (and maybe untested) changes onto stable.
I think I understand the idea, though you've lost me completely as far
as the process is concerned...
A pointer to a FMTR (assuming there is one that I could be RTFM-ed to)
would be very much appreciated. Sorry again for my newbieness.
Thanks again!
Gerlando
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-20 17:40 ` Gerlando Falauto
2013-03-20 21:42 ` Thomas Gleixner
@ 2013-03-21 10:59 ` Simon Guinot
1 sibling, 0 replies; 45+ messages in thread
From: Simon Guinot @ 2013-03-21 10:59 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 20, 2013 at 06:40:29PM +0100, Gerlando Falauto wrote:
> Hi,
>
> sorry about the delay (been busy with other stuff).
> First of all thanks for your hints. I have some questions.
> This is my first time, so please be gentle... :-)
>
> On 03/19/2013 12:56 PM, Jason Cooper wrote:
> >On Tue, Mar 19, 2013 at 07:44:31AM -0400, Jason Cooper wrote:
> >>Those commit IDs are going to change once LinusW (I presume) applies
> >>them to his tree, so he'll have to edit each commit message to point the
> >>the correct commit.
> >>
> >>LinusW, do you want me to handle this?
> >
> >Never mind, coffee underflow to /dev/brain. One drawback to mutt, can't
> >view thread while typing messages...
>
> 1) I had no idea who LinusW is, I assume Linus Walleij who should be
> the maintainer of linux-gpio. And linux-gpio should have nothing to
> do with this discussion... so I should assume you never mentioned
> him, right?
>
> 2) About the SOB part... most of this is inspired by Simon's
> original (single) patch and Holger's reworking. Should they be given
> credit or not? If yes, how? If I don't get an answer I would just
> assume no and I'll take all the blame and credit all by myself. :-)
Please drop all the SOBs with my name. Except for giving up a patch
almost two years, I am not involved in this patch series development.
I am quite sure there is no credit in that :)
Thanks.
Simon
>
> 3) Jason, did you mean you would pull it to
> http://git.infradead.org/users/jcooper/linux.git? Shall I change the
> SOB lines and resubmit? Or should I submit it somewhere else
> instead?
>
> 4) About submitting to -stable, I guess it wouldn't make any sense
> until it gets included upstream
> (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ so
> to speak). Is that right?
> Or at least to jcooper's tree, through which it should eventually
> make it mainline through a merge (therefore keeping its commit-id).
> That right?
>
> I did read Documentation/stable_kernel_rules.txt and what I
> understand is that it would be enough to submit to
> stable at vger.kernel.org only the last one, while providing a list of
>
> Cc: <stable@vger.kernel.org> # 3.0.x: 123456 first patch
> Cc: <stable@vger.kernel.org> # 3.0.x: 123457 second patch
> Cc: <stable@vger.kernel.org> # 3.0.x: 123458 third patch
>
> using the mainstream (or jcooper's) commit IDs.
>
> I don't know whether I'd have to repeat that for each version (3.0
> will include only a subset of this series, while 3.7 and following
> will need the whole nine yards, and what's in between... well,
> something in between).
>
> Please let me know what to do. Again, it's my first time so please
> be gentle. :-)
>
> Thanks again!
> Gerlando
>
> >>If you prefer to take it:
> >>
> >>Acked-by: Jason Cooper <jason@lakedaemon.net>
> >
> >for the plat-orion/gpio.c bits and if it helps, the gpio-mvebu.c bits.
> >
> >thx,
> >
> >Jason.
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130321/736911a4/attachment.sig>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-19 11:06 ` Jason Cooper
2013-03-19 11:10 ` Gerlando Falauto
@ 2013-03-19 11:19 ` Ezequiel Garcia
1 sibling, 0 replies; 45+ messages in thread
From: Ezequiel Garcia @ 2013-03-19 11:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jason,
On Tue, Mar 19, 2013 at 07:06:20AM -0400, Jason Cooper wrote:
> On Tue, Mar 19, 2013 at 07:03:53AM -0300, Ezequiel Garcia wrote:
> > On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> > > here is a patchset to address the issue found with Orion, in incremental
> > > stages as Thomas suggested.
> > > a) we introduce the new fields and pointer (though only the shared one is used)
> > > b) we convert all drivers to use it
> > > c) we rename the field so to force the use of the per-ct pointer
> > > d) we add per-ct mask cache, provided the new flag
> > > IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> > > e) we enable the flag for orion-gpio and mvebu drivers
> > >
> > > So even though I'm also providing changes for mvebu, I only
> > > tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
> >
> > Great job! Since this is a really old bug you're fixing I believe that the
> > patchset applies for stable as well as mainline.
> >
> > According to Documentation/stable_kernel_rules.txt all you need to do
> > is add a 'Cc: stable at vger.kernel.org' tag in your sign-off area.
> >
> > Stable people will take care of picking the patch when it hits
> > mainline. You should receive a mail notification about patches
> > being included in stable kernels.
>
> Yes, and if you have an idea of when the regression was introduced,
> perhaps even which commit, that would be *extremely* helpful.
> Otherwise, the stable folks have to expend a lot of time tracking it
> down.
>
Gerlando explains the problematic commit in the changelog of patch 8/9
of this series:
enable handling of separate mask registers for Orion SoC GPIOs,
fixing indeed the regression introduced by e59347a
"arm: orion: Use generic irq chip".
@Gerlando, perhaps you should add this comment to the cover-letter?
After all, this fix is the whole point of the patchset.
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (10 preceding siblings ...)
2013-03-19 10:03 ` Ezequiel Garcia
@ 2013-03-21 10:51 ` Simon Guinot
2013-03-21 11:24 ` Gerlando Falauto
2013-04-04 9:31 ` Ezequiel Garcia
12 siblings, 1 reply; 45+ messages in thread
From: Simon Guinot @ 2013-03-21 10:51 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> Hi everyone,
> here is a patchset to address the issue found with Orion, in incremental
> stages as Thomas suggested.
> a) we introduce the new fields and pointer (though only the shared one is used)
> b) we convert all drivers to use it
> c) we rename the field so to force the use of the per-ct pointer
> d) we add per-ct mask cache, provided the new flag
> IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> e) we enable the flag for orion-gpio and mvebu drivers
>
> So even though I'm also providing changes for mvebu, I only
> tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
> We currently do not have a working 3.6+ configuration for our Kirkwood
> boards (3.6 is apparently where this mvebu gpio driver was introduced),
> so I would be glad if someone could give it a try.
> I also have no idea whether the three Marvell variants all have separate
> mask registers (which is what the last patch assumes).
>
> Gerlando Falauto (9):
> genirq: cosmetic: remove cur_regs
> genirq: add mask_cache and pmask_cache into struct irq_chip_type
> gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type
> MIPS: JZ4740: convert to usage of *pmask_cache within irq_chip_type
> ARM: SAMSUNG: convert to usage of *pmask_cache within irq_chip_type
> genirq: rename mask_cache to shared_mask_cache
> genirq: handle separate mask registers
> orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS
> gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS
>
> arch/arm/plat-orion/gpio.c | 3 +-
> arch/arm/plat-samsung/irq-vic-timer.c | 6 ++--
> arch/mips/jz4740/irq.c | 3 +-
> drivers/gpio/gpio-mvebu.c | 23 ++++++++------
> include/linux/irq.h | 9 ++++--
> kernel/irq/generic-chip.c | 55 +++++++++++++++++++++------------
> 6 files changed, 64 insertions(+), 35 deletions(-)
Hi Gerlando,
On a Network Space v2 Max board (Kirkwood SoC), I have verified that
both the GPIO drivers mvebu-gpio and orion-gpio are impacted by the bug.
I have also checked that this patch series fixes the bug for each of
them.
Thanks
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130321/4a827868/attachment.sig>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-21 10:51 ` Simon Guinot
@ 2013-03-21 11:24 ` Gerlando Falauto
0 siblings, 0 replies; 45+ messages in thread
From: Gerlando Falauto @ 2013-03-21 11:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon,
On 03/21/2013 11:51 AM, Simon Guinot wrote:
> On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
>> Hi everyone,
>> here is a patchset to address the issue found with Orion, in incremental
>> stages as Thomas suggested.
>> a) we introduce the new fields and pointer (though only the shared one is used)
>> b) we convert all drivers to use it
>> c) we rename the field so to force the use of the per-ct pointer
>> d) we add per-ct mask cache, provided the new flag
>> IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
>> e) we enable the flag for orion-gpio and mvebu drivers
>>
>> So even though I'm also providing changes for mvebu, I only
>> tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
>> We currently do not have a working 3.6+ configuration for our Kirkwood
>> boards (3.6 is apparently where this mvebu gpio driver was introduced),
>> so I would be glad if someone could give it a try.
>> I also have no idea whether the three Marvell variants all have separate
>> mask registers (which is what the last patch assumes).
>>
>> Gerlando Falauto (9):
>> genirq: cosmetic: remove cur_regs
>> genirq: add mask_cache and pmask_cache into struct irq_chip_type
>> gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type
>> MIPS: JZ4740: convert to usage of *pmask_cache within irq_chip_type
>> ARM: SAMSUNG: convert to usage of *pmask_cache within irq_chip_type
>> genirq: rename mask_cache to shared_mask_cache
>> genirq: handle separate mask registers
>> orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS
>> gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS
>>
>> arch/arm/plat-orion/gpio.c | 3 +-
>> arch/arm/plat-samsung/irq-vic-timer.c | 6 ++--
>> arch/mips/jz4740/irq.c | 3 +-
>> drivers/gpio/gpio-mvebu.c | 23 ++++++++------
>> include/linux/irq.h | 9 ++++--
>> kernel/irq/generic-chip.c | 55 +++++++++++++++++++++------------
>> 6 files changed, 64 insertions(+), 35 deletions(-)
>
> Hi Gerlando,
>
> On a Network Space v2 Max board (Kirkwood SoC), I have verified that
> both the GPIO drivers mvebu-gpio and orion-gpio are impacted by the bug.
>
> I have also checked that this patch series fixes the bug for each of
> them.
>
> Thanks
Great!
Will you then offer a Tested-By? (on the last two patches, I guess)?
Thanks!
Gerlando
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v3 0/9] refactoring for mask_cache
2013-03-18 14:00 ` [PATCH v3 0/9] " Gerlando Falauto
` (11 preceding siblings ...)
2013-03-21 10:51 ` Simon Guinot
@ 2013-04-04 9:31 ` Ezequiel Garcia
12 siblings, 0 replies; 45+ messages in thread
From: Ezequiel Garcia @ 2013-04-04 9:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi Gerlando,
On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> Hi everyone,
> here is a patchset to address the issue found with Orion, in incremental
> stages as Thomas suggested.
> a) we introduce the new fields and pointer (though only the shared one is used)
> b) we convert all drivers to use it
> c) we rename the field so to force the use of the per-ct pointer
> d) we add per-ct mask cache, provided the new flag
> IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> e) we enable the flag for orion-gpio and mvebu drivers
>
> So even though I'm also providing changes for mvebu, I only
> tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
> We currently do not have a working 3.6+ configuration for our Kirkwood
> boards (3.6 is apparently where this mvebu gpio driver was introduced),
> so I would be glad if someone could give it a try.
> I also have no idea whether the three Marvell variants all have separate
> mask registers (which is what the last patch assumes).
>
> Gerlando Falauto (9):
> genirq: cosmetic: remove cur_regs
> genirq: add mask_cache and pmask_cache into struct irq_chip_type
> gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type
> MIPS: JZ4740: convert to usage of *pmask_cache within irq_chip_type
> ARM: SAMSUNG: convert to usage of *pmask_cache within irq_chip_type
> genirq: rename mask_cache to shared_mask_cache
> genirq: handle separate mask registers
> orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS
> gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS
>
> arch/arm/plat-orion/gpio.c | 3 +-
> arch/arm/plat-samsung/irq-vic-timer.c | 6 ++--
> arch/mips/jz4740/irq.c | 3 +-
> drivers/gpio/gpio-mvebu.c | 23 ++++++++------
> include/linux/irq.h | 9 ++++--
> kernel/irq/generic-chip.c | 55 +++++++++++++++++++++------------
> 6 files changed, 64 insertions(+), 35 deletions(-)
>
What's the plan for this patchset?
Given this fixes a long time issue, perhaps we might want to try to have
it included in v3.10, which is soon to come.
Thanks,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 45+ messages in thread