Re: [PATCH 01/28] powerpc: mpic irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
On Wed, Mar 09, 2011 at 06:51:44PM +1100, Benjamin Herrenschmidt wrote:

-static void mpic_unmask_ht_irq(unsigned int irq)
+static void mpic_unmask_ht_irq(struct irq_data *d)
 {
-   struct mpic *mpic = mpic_from_irq(irq);
-   unsigned int src = mpic_irq_to_hw(irq);
+   struct mpic *mpic = mpic_from_irq(d-irq);
+   unsigned int src = mpic_irq_to_hw(d-irq);
   
   It's a bit sad to have a pointerm turn it back to a irq number,
   look it up just to get back the chip data in there :-)
  
  ACK, how about the below?
 
 Much better. Do you want to fold it in and re-post only the affected
 patch (es) ?

Sure.  I've fixed the same thing in a couple more files (see
incremental patch below), so there'll be new versions of these coming
up shortly:

powerpc: mpic irq_data conversion.
powerpc: platforms/52xx irq_data conversion.
powerpc: platforms/82xx irq_data conversion.
powerpc: platforms/embedded6xx irq_data conversion.
powerpc: platforms/ps3 irq_data conversion.
powerpc: sysdev/mpc8xxx_gpio irq_data conversion.
powerpc: sysdev/qe_lib/qe_ic irq_data conversion.
powerpc: sysdev/uic irq_data conversion.
powerpc: sysdev/xilinx_intc irq_data conversion.

I've also updated the tree on git.kernel.org with these changes.



diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index fe6cc5d..c9290d8 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -137,7 +137,7 @@ DEFINE_MUTEX(mpc52xx_gpt_list_mutex);
 
 static void mpc52xx_gpt_irq_unmask(struct irq_data *d)
 {
-   struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(d-irq);
+   struct mpc52xx_gpt_priv *gpt = irq_data_get_irq_chip_data(d);
unsigned long flags;
 
spin_lock_irqsave(gpt-lock, flags);
@@ -147,7 +147,7 @@ static void mpc52xx_gpt_irq_unmask(struct irq_data *d)
 
 static void mpc52xx_gpt_irq_mask(struct irq_data *d)
 {
-   struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(d-irq);
+   struct mpc52xx_gpt_priv *gpt = irq_data_get_irq_chip_data(d);
unsigned long flags;
 
spin_lock_irqsave(gpt-lock, flags);
@@ -157,14 +157,14 @@ static void mpc52xx_gpt_irq_mask(struct irq_data *d)
 
 static void mpc52xx_gpt_irq_ack(struct irq_data *d)
 {
-   struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(d-irq);
+   struct mpc52xx_gpt_priv *gpt = irq_data_get_irq_chip_data(d);
 
out_be32(gpt-regs-status, MPC52xx_GPT_STATUS_IRQMASK);
 }
 
 static int mpc52xx_gpt_irq_set_type(struct irq_data *d, unsigned int flow_type)
 {
-   struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(d-irq);
+   struct mpc52xx_gpt_priv *gpt = irq_data_get_irq_chip_data(d);
unsigned long flags;
u32 reg;
 
diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c 
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
index a0cd8ae..926dfda 100644
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -41,7 +41,7 @@ struct pq2ads_pci_pic {
 
 static void pq2ads_pci_mask_irq(struct irq_data *d)
 {
-   struct pq2ads_pci_pic *priv = get_irq_chip_data(d-irq);
+   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) {
@@ -57,7 +57,7 @@ static void pq2ads_pci_mask_irq(struct irq_data *d)
 
 static void pq2ads_pci_unmask_irq(struct irq_data *d)
 {
-   struct pq2ads_pci_pic *priv = get_irq_chip_data(d-irq);
+   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) {
diff --git a/arch/powerpc/platforms/embedded6xx/flipper-pic.c 
b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
index d7287e8..0aca0e2 100644
--- a/arch/powerpc/platforms/embedded6xx/flipper-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
@@ -49,7 +49,7 @@
 static void flipper_pic_mask_and_ack(struct irq_data *d)
 {
int irq = virq_to_hw(d-irq);
-   void __iomem *io_base = get_irq_chip_data(d-irq);
+   void __iomem *io_base = irq_data_get_irq_chip_data(d);
u32 mask = 1  irq;
 
clrbits32(io_base + FLIPPER_IMR, mask);
@@ -60,7 +60,7 @@ static void flipper_pic_mask_and_ack(struct irq_data *d)
 static void flipper_pic_ack(struct irq_data *d)
 {
int irq = virq_to_hw(d-irq);
-   void __iomem *io_base = get_irq_chip_data(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);
@@ -69,7 +69,7 @@ static void flipper_pic_ack(struct irq_data *d)
 static void flipper_pic_mask(struct irq_data *d)
 {
int irq = virq_to_hw(d-irq);
-   void __iomem *io_base = get_irq_chip_data(d-irq);
+   void __iomem *io_base = irq_data_get_irq_chip_data(d);
 
clrbits32(io_base + FLIPPER_IMR, 1  

[PATCH v2 01/28] powerpc: mpic irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@secretlab.ca
---
v2: get_irq_chip_data(d-irq) = irq_data_get_irq_chip_data(d)

 arch/powerpc/include/asm/mpic.h   |6 +-
 arch/powerpc/platforms/pasemi/setup.c |4 +-
 arch/powerpc/sysdev/mpic.c|  137 +
 arch/powerpc/sysdev/mpic.h|5 +-
 arch/powerpc/sysdev/mpic_pasemi_msi.c |   18 ++--
 arch/powerpc/sysdev/mpic_u3msi.c  |   18 ++--
 6 files changed, 98 insertions(+), 90 deletions(-)

diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index e000cce..946ec49 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -467,11 +467,11 @@ extern void mpic_request_ipis(void);
 void smp_mpic_message_pass(int target, int msg);
 
 /* Unmask a specific virq */
-extern void mpic_unmask_irq(unsigned int irq);
+extern void mpic_unmask_irq(struct irq_data *d);
 /* Mask a specific virq */
-extern void mpic_mask_irq(unsigned int irq);
+extern void mpic_mask_irq(struct irq_data *d);
 /* EOI a specific virq */
-extern void mpic_end_irq(unsigned int irq);
+extern void mpic_end_irq(struct irq_data *d);
 
 /* Fetch interrupt from a given mpic */
 extern unsigned int mpic_get_one_irq(struct mpic *mpic);
diff --git a/arch/powerpc/platforms/pasemi/setup.c 
b/arch/powerpc/platforms/pasemi/setup.c
index f372ec1..a6067b3 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -240,7 +240,7 @@ static __init void pas_init_IRQ(void)
nmi_virq = irq_create_mapping(NULL, *nmiprop);
mpic_irq_set_priority(nmi_virq, 15);
set_irq_type(nmi_virq, IRQ_TYPE_EDGE_RISING);
-   mpic_unmask_irq(nmi_virq);
+   mpic_unmask_irq(irq_get_irq_data(nmi_virq));
}
 
of_node_put(mpic_node);
@@ -266,7 +266,7 @@ static int pas_machine_check_handler(struct pt_regs *regs)
if (nmi_virq != NO_IRQ  mpic_get_mcirq() == nmi_virq) {
printk(KERN_ERR NMI delivered\n);
debugger(regs);
-   mpic_end_irq(nmi_virq);
+   mpic_end_irq(irq_get_irq_data(nmi_virq));
goto out;
}
 
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index b0c8469..eb70218 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -611,7 +611,7 @@ static struct mpic *mpic_find(unsigned int irq)
if (irq  NUM_ISA_INTERRUPTS)
return NULL;
 
-   return irq_to_desc(irq)-chip_data;
+   return get_irq_chip_data(irq);
 }
 
 /* Determine if the linux irq is an IPI */
@@ -636,16 +636,22 @@ static inline u32 mpic_physmask(u32 cpumask)
 
 #ifdef CONFIG_SMP
 /* Get the mpic structure from the IPI number */
-static inline struct mpic * mpic_from_ipi(unsigned int ipi)
+static inline struct mpic * mpic_from_ipi(struct irq_data *d)
 {
-   return irq_to_desc(ipi)-chip_data;
+   return irq_data_get_irq_chip_data(d);
 }
 #endif
 
 /* Get the mpic structure from the irq number */
 static inline struct mpic * mpic_from_irq(unsigned int irq)
 {
-   return irq_to_desc(irq)-chip_data;
+   return get_irq_chip_data(irq);
+}
+
+/* Get the mpic structure from the irq data */
+static inline struct mpic * mpic_from_irq_data(struct irq_data *d)
+{
+   return irq_data_get_irq_chip_data(d);
 }
 
 /* Send an EOI */
@@ -660,13 +666,13 @@ static inline void mpic_eoi(struct mpic *mpic)
  */
 
 
-void mpic_unmask_irq(unsigned int irq)
+void mpic_unmask_irq(struct irq_data *d)
 {
unsigned int loops = 10;
-   struct mpic *mpic = mpic_from_irq(irq);
-   unsigned int src = mpic_irq_to_hw(irq);
+   struct mpic *mpic = mpic_from_irq_data(d);
+   unsigned int src = mpic_irq_to_hw(d-irq);
 
-   DBG(%p: %s: enable_irq: %d (src %d)\n, mpic, mpic-name, irq, src);
+   DBG(%p: %s: enable_irq: %d (src %d)\n, mpic, mpic-name, d-irq, src);
 
mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI),
   mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) 
@@ -681,13 +687,13 @@ void mpic_unmask_irq(unsigned int irq)
} while(mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI))  
MPIC_VECPRI_MASK);
 }
 
-void mpic_mask_irq(unsigned int irq)
+void mpic_mask_irq(struct irq_data *d)
 {
unsigned int loops = 10;
-   struct mpic *mpic = mpic_from_irq(irq);
-   unsigned int src = mpic_irq_to_hw(irq);
+   struct mpic *mpic = mpic_from_irq_data(d);
+   unsigned int src = mpic_irq_to_hw(d-irq);
 
-   DBG(%s: disable_irq: %d (src %d)\n, mpic-name, irq, src);
+   DBG(%s: disable_irq: %d (src %d)\n, mpic-name, d-irq, src);
 
mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI),
   mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) |
@@ -703,12 +709,12 @@ void mpic_mask_irq(unsigned int irq)
} while(!(mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI))  
MPIC_VECPRI_MASK));
 }
 
-void mpic_end_irq(unsigned 

[PATCH v2 03/28] powerpc: platforms/52xx irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@secretlab.ca
---
v2: get_irq_chip_data(d-irq) = irq_data_get_irq_chip_data(d)

 arch/powerpc/platforms/52xx/media5200.c   |   21 
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c |   26 +-
 arch/powerpc/platforms/52xx/mpc52xx_pic.c |   80 ++--
 3 files changed, 64 insertions(+), 63 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/media5200.c 
b/arch/powerpc/platforms/52xx/media5200.c
index 2c7780c..2bd1e6c 100644
--- a/arch/powerpc/platforms/52xx/media5200.c
+++ b/arch/powerpc/platforms/52xx/media5200.c
@@ -49,45 +49,46 @@ struct media5200_irq {
 };
 struct media5200_irq media5200_irq;
 
-static void media5200_irq_unmask(unsigned int virq)
+static void media5200_irq_unmask(struct irq_data *d)
 {
unsigned long flags;
u32 val;
 
spin_lock_irqsave(media5200_irq.lock, flags);
val = in_be32(media5200_irq.regs + MEDIA5200_IRQ_ENABLE);
-   val |= 1  (MEDIA5200_IRQ_SHIFT + irq_map[virq].hwirq);
+   val |= 1  (MEDIA5200_IRQ_SHIFT + irq_map[d-irq].hwirq);
out_be32(media5200_irq.regs + MEDIA5200_IRQ_ENABLE, val);
spin_unlock_irqrestore(media5200_irq.lock, flags);
 }
 
-static void media5200_irq_mask(unsigned int virq)
+static void media5200_irq_mask(struct irq_data *d)
 {
unsigned long flags;
u32 val;
 
spin_lock_irqsave(media5200_irq.lock, flags);
val = in_be32(media5200_irq.regs + MEDIA5200_IRQ_ENABLE);
-   val = ~(1  (MEDIA5200_IRQ_SHIFT + irq_map[virq].hwirq));
+   val = ~(1  (MEDIA5200_IRQ_SHIFT + irq_map[d-irq].hwirq));
out_be32(media5200_irq.regs + MEDIA5200_IRQ_ENABLE, val);
spin_unlock_irqrestore(media5200_irq.lock, flags);
 }
 
 static struct irq_chip media5200_irq_chip = {
.name = Media5200 FPGA,
-   .unmask = media5200_irq_unmask,
-   .mask = media5200_irq_mask,
-   .mask_ack = media5200_irq_mask,
+   .irq_unmask = media5200_irq_unmask,
+   .irq_mask = media5200_irq_mask,
+   .irq_mask_ack = media5200_irq_mask,
 };
 
 void media5200_irq_cascade(unsigned int virq, struct irq_desc *desc)
 {
+   struct irq_chip *chip = get_irq_desc_chip(desc);
int sub_virq, val;
u32 status, enable;
 
/* Mask off the cascaded IRQ */
raw_spin_lock(desc-lock);
-   desc-chip-mask(virq);
+   chip-irq_mask(desc-irq_data);
raw_spin_unlock(desc-lock);
 
/* Ask the FPGA for IRQ status.  If 'val' is 0, then no irqs
@@ -105,9 +106,9 @@ void media5200_irq_cascade(unsigned int virq, struct 
irq_desc *desc)
 
/* Processing done; can reenable the cascade now */
raw_spin_lock(desc-lock);
-   desc-chip-ack(virq);
+   chip-irq_ack(desc-irq_data);
if (!(desc-status  IRQ_DISABLED))
-   desc-chip-unmask(virq);
+   chip-irq_unmask(desc-irq_data);
raw_spin_unlock(desc-lock);
 }
 
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index e0d703c..c9290d8 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -135,9 +135,9 @@ DEFINE_MUTEX(mpc52xx_gpt_list_mutex);
  * Cascaded interrupt controller hooks
  */
 
-static void mpc52xx_gpt_irq_unmask(unsigned int virq)
+static void mpc52xx_gpt_irq_unmask(struct irq_data *d)
 {
-   struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(virq);
+   struct mpc52xx_gpt_priv *gpt = irq_data_get_irq_chip_data(d);
unsigned long flags;
 
spin_lock_irqsave(gpt-lock, flags);
@@ -145,9 +145,9 @@ static void mpc52xx_gpt_irq_unmask(unsigned int virq)
spin_unlock_irqrestore(gpt-lock, flags);
 }
 
-static void mpc52xx_gpt_irq_mask(unsigned int virq)
+static void mpc52xx_gpt_irq_mask(struct irq_data *d)
 {
-   struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(virq);
+   struct mpc52xx_gpt_priv *gpt = irq_data_get_irq_chip_data(d);
unsigned long flags;
 
spin_lock_irqsave(gpt-lock, flags);
@@ -155,20 +155,20 @@ static void mpc52xx_gpt_irq_mask(unsigned int virq)
spin_unlock_irqrestore(gpt-lock, flags);
 }
 
-static void mpc52xx_gpt_irq_ack(unsigned int virq)
+static void mpc52xx_gpt_irq_ack(struct irq_data *d)
 {
-   struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(virq);
+   struct mpc52xx_gpt_priv *gpt = irq_data_get_irq_chip_data(d);
 
out_be32(gpt-regs-status, MPC52xx_GPT_STATUS_IRQMASK);
 }
 
-static int mpc52xx_gpt_irq_set_type(unsigned int virq, unsigned int flow_type)
+static int mpc52xx_gpt_irq_set_type(struct irq_data *d, unsigned int flow_type)
 {
-   struct mpc52xx_gpt_priv *gpt = get_irq_chip_data(virq);
+   struct mpc52xx_gpt_priv *gpt = irq_data_get_irq_chip_data(d);
unsigned long flags;
u32 reg;
 
-   dev_dbg(gpt-dev, %s: virq=%i type=%x\n, __func__, virq, flow_type);
+   dev_dbg(gpt-dev, %s: virq=%i type=%x\n, __func__, d-irq, flow_type);
 

[PATCH v2 04/28] powerpc: platforms/82xx irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 10/28] powerpc: platforms/embedded6xx irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@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 = 

[PATCH v2 21/28] powerpc: sysdev/mpc8xxx_gpio irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@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)
- 

[PATCH v2 13/28] powerpc: platforms/ps3 irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 23/28] powerpc: sysdev/qe_lib/qe_ic irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@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 

[PATCH v2 25/28] powerpc: sysdev/uic irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@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)
-   

[PATCH v2 26/28] powerpc: sysdev/xilinx_intc irq_data conversion.

2011-03-09 Thread Lennert Buytenhek
Signed-off-by: Lennert Buytenhek buyt...@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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Peter Zijlstra
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=1024 which might
 increase the frequency of the problem but I don't think they are
 necessary to expose it.
 
 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).
 
 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. 

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. 

:-)

 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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Peter Zijlstra
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!
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden

2011-03-09 Thread Américo Wang
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 an...@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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden

2011-03-09 Thread Anton Blanchard

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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Peter Zijlstra
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. 

Gah, if only..
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Martin Schwidefsky
On Wed, 09 Mar 2011 12:33:49 +0100
Peter Zijlstra pet...@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.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Peter Zijlstra
On Wed, 2011-03-09 at 14:15 +0100, Martin Schwidefsky wrote:
 On Wed, 09 Mar 2011 12:33:49 +0100
 Peter Zijlstra pet...@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?


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Martin Schwidefsky
On Wed, 09 Mar 2011 14:19:29 +0100
Peter Zijlstra pet...@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 pet...@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.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Peter Zijlstra
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.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Martin Schwidefsky
On Wed, 09 Mar 2011 14:33:56 +0100
Peter Zijlstra pet...@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.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Peter Zijlstra
On Wed, 2011-03-09 at 14:46 +0100, Martin Schwidefsky wrote:
 On Wed, 09 Mar 2011 14:33:56 +0100
 Peter Zijlstra pet...@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.

Right, so I consider caches to be part of the memory topology, anyway,
if this all is very rare then yeah, that works out.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct

2011-03-09 Thread Stephen Wilson
On Wed, Mar 09, 2011 at 05:09:09AM -0800, Michel Lespinasse wrote:
 On Tue, Mar 8, 2011 at 4:31 PM, Stephen Wilson wils...@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 wal...@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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden

2011-03-09 Thread Américo Wang
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?

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [BUG] rebuild_sched_domains considered dangerous

2011-03-09 Thread Steven Rostedt
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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct

2011-03-09 Thread Michel Lespinasse
On Tue, Mar 8, 2011 at 4:31 PM, Stephen Wilson wils...@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 wal...@google.com

May I suggest ia32_compat instead of just compat for the flag name ?

-- 
Michel Walken Lespinasse
A program is never fully debugged until the last user dies.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[5200B/slightly ot] MPC52xx LPB FIFO memory requirements

2011-03-09 Thread Albrecht Dreß

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.


pgpxTthIqOPdu.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/pseries: Disable VPNH feature

2011-03-09 Thread Benjamin Herrenschmidt
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 b...@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;
 }


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/pseries: Disable VPNH feature

2011-03-09 Thread Benjamin Herrenschmidt
On Thu, 2011-03-10 at 10:00 +1100, Benjamin Herrenschmidt wrote:
 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 b...@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

Turning that into if (0  instead to avoid compiler warnings
and thus build failures

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: disable MSI using new interface if possible

2011-03-09 Thread Michael Ellerman
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 functionSpecifying 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 mich...@ellerman.id.au

cheers


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: disable MSI using new interface if possible

2011-03-09 Thread Michael Ellerman
On Thu, 2011-03-03 at 19:29 -0800, Joe Perches wrote:
 On Fri, 2011-03-04 at 14:06 +1100, Michael Ellerman wrote:
  On Thu, 2011-03-03 at 17:41 -0800, Nishanth Aravamudan wrote:
   On 04.03.2011 [12:05:29 +1100], Michael Ellerman wrote:
Cc: Me  :)
   Sorry! I was in a hurry to get this out the door, my fault. Note, you
   don't show up per scripts/get_maintainer.pl :)
  No worries, though I will remember never to use get_maintainer.pl, it is
  obviously utterly broken:
 
 Blah, blah, stupid tool doesn't work exactly as I want,
 and it doesn't credit me for my over 2 year old patches,
 therefore it's not only stupid, it's broken...

I do not give two shits about being given credit for this horrible
code, but if someone changes it I may have input.

True my last patch may have been two years ago, but I _wrote the entire
file_, and essentially no one else has ever touched it.

 $ ./scripts/get_maintainer.pl -f arch/powerpc/platforms/pseries/msi.c
 Benjamin Herrenschmidt b...@kernel.crashing.org (supporter:LINUX FOR 
 POWERPC...)
 Paul Mackerras pau...@samba.org (supporter:LINUX FOR POWERPC...)
 Grant Likely grant.lik...@secretlab.ca (maintainer:OPEN FIRMWARE AND...)
 linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
 linux-ker...@vger.kernel.org (open list)
 devicetree-disc...@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
 
 If you don't like how it currently works, suggest
 improvements.

I think I was suggesting that I should be in that list :)

In the life of this file there have been 553 lines changed (added or
deleted), of which I have written 551, and I signed off the other 2.

So I guess I'm suggesting that when someone has written a large number
of the changes to a file they should be CC'ed. I don't know what the cut
off for large number should be, but anything  50% would seem
reasonable (in terms of lines, not commits).

 How nice for you.  Last patch from you was 2 years ago.

Last patch from _anyone_ was 2 years ago. As much as I may have tried to
banish that code from my mind I can still remember some of the details,
even after 2 years :)

 CC'ing inactive non named maintainers via git
 history also draws complaints btw.

Yeah I can imagine. But that is a case of someone who is no longer
interested getting one extra email, ie. a false positive, whereas in
this case it's someone who does care _not_ seeing the patch, ie. a false
negative.

cheers



signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[git pull] Please pull powerpc.git merge branch

2011-03-09 Thread Benjamin Herrenschmidt
Hi Linus !

Here's a pair of regression fixes for 2.6.38. One fixes a 2.6.37
regression (I'll send it to -stable separately) that breaks booting on
legacy iSeries, and the other one disables a newly introduced features
as it triggers nasty races in the scheduler that causes hangs and seem
to be too much to fix for this release (working with PeterZ on it).

Cheers,
Ben.

The following changes since commit a5abba989deceb731047425812d268daf7536575:

  Linux 2.6.38-rc8 (2011-03-07 21:09:37 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

Benjamin Herrenschmidt (2):
  powerpc/iseries: Fix early init access to lppaca
  powerpc/pseries: Disable VPNH feature

 arch/powerpc/include/asm/lppaca.h  |   16 
 arch/powerpc/kernel/paca.c |   14 --
 arch/powerpc/mm/numa.c |3 ++-
 arch/powerpc/platforms/iseries/dt.c|6 +++---
 arch/powerpc/platforms/iseries/setup.c |1 +
 5 files changed, 22 insertions(+), 18 deletions(-)


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: disable MSI using new interface if possible

2011-03-09 Thread Joe Perches
On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
 True my last patch may have been two years ago, but I _wrote the entire
 file_, and essentially no one else has ever touched it.
 
  $ ./scripts/get_maintainer.pl -f arch/powerpc/platforms/pseries/msi.c
  Benjamin Herrenschmidt b...@kernel.crashing.org (supporter:LINUX FOR 
  POWERPC...)
  Paul Mackerras pau...@samba.org (supporter:LINUX FOR POWERPC...)
  Grant Likely grant.lik...@secretlab.ca (maintainer:OPEN FIRMWARE AND...)
  linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
  linux-ker...@vger.kernel.org (open list)
  devicetree-disc...@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
  
  If you don't like how it currently works, suggest
  improvements.
 
 I think I was suggesting that I should be in that list :)

$ ./scripts/get_maintainer.pl -f --git-blame 
arch/powerpc/platforms/pseries/msi.c
Benjamin Herrenschmidt b...@kernel.crashing.org (supporter:LINUX FOR 
POWERPC...,commits:8/11=73%)
Paul Mackerras pau...@samba.org (supporter:LINUX FOR 
POWERPC...,commits:4/11=36%)
Grant Likely grant.lik...@secretlab.ca (maintainer:OPEN FIRMWARE AND...)
Michael Ellerman mich...@ellerman.id.au (authored 
lines:481/481=100%,commits:11/11=100%)
Linas Vepstas li...@austin.ibm.com (commits:1/11=9%)
linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
linux-ker...@vger.kernel.org (open list)
devicetree-disc...@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)

cheers, Joe

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: disable MSI using new interface if possible

2011-03-09 Thread Nishanth Aravamudan
On 09.03.2011 [16:28:23 -0800], Joe Perches wrote:
 On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
  True my last patch may have been two years ago, but I _wrote the entire
  file_, and essentially no one else has ever touched it.
  
   $ ./scripts/get_maintainer.pl -f arch/powerpc/platforms/pseries/msi.c
   Benjamin Herrenschmidt b...@kernel.crashing.org (supporter:LINUX FOR 
   POWERPC...)
   Paul Mackerras pau...@samba.org (supporter:LINUX FOR POWERPC...)
   Grant Likely grant.lik...@secretlab.ca (maintainer:OPEN FIRMWARE AND...)
   linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
   linux-ker...@vger.kernel.org (open list)
   devicetree-disc...@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
   
   If you don't like how it currently works, suggest
   improvements.
  
  I think I was suggesting that I should be in that list :)
 
 $ ./scripts/get_maintainer.pl -f --git-blame 
 arch/powerpc/platforms/pseries/msi.c

Ah thanks, I didn't realize that flag existed, as I'd not needed to use
it before.

-Nish

-- 
Nishanth Aravamudan n...@us.ibm.com
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/3] crypto: add device tree bindings for the Freescale SEC4/CAAM

2011-03-09 Thread Kim Phillips
Add SEC4 device tree binding documentation and add a SEC4
device node to the P4080's dts.

Signed-off-by: Steve Cornelius s...@pobox.com
Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
 .../devicetree/bindings/crypto/fsl-sec4.txt|  409 
 arch/powerpc/boot/dts/p4080ds.dts  |   95 +-
 2 files changed, 503 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/crypto/fsl-sec4.txt

diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt 
b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
new file mode 100644
index 000..fce16a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -0,0 +1,409 @@
+=
+SEC 4 Device Tree Binding
+Copyright (C) 2008-2011 Freescale Semiconductor Inc.
+
+ CONTENTS
+   -Overview
+   -SEC 4 Node
+   -Job Ring Node
+   -Run Time Integrity Check (RTIC) Node
+   -Run Time Integrity Check (RTIC) Memory Node
+   -Secure Non-Volatile Storage (SNVS) Node
+   -Full Example
+
+NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
+Accelerator and Assurance Module (CAAM).
+
+=
+Overview
+
+DESCRIPTION
+
+SEC 4 h/w can process requests from 2 types of sources.
+1. DPAA Queue Interface (HW interface between Queue Manager  SEC 4).
+2. Job Rings (HW interface between cores  SEC 4 registers).
+
+High Speed Data Path Configuration:
+
+HW interface between QM  SEC 4 and also BM  SEC 4, on DPAA-enabled parts
+such as the P4080.  The number of simultaneous dequeues the QI can make is
+equal to the number of Descriptor Controller (DECO) engines in a particular
+SEC version.  E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus
+dequeue from 5 subportals simultaneously.
+
+Job Ring Data Path Configuration:
+
+Each JR is located on a separate 4k page, they may (or may not) be made visible
+in the memory partition devoted to a particular core.  The P4080 has 4 JRs, so
+up to 4 JRs can be configured; and all 4 JRs process requests in parallel.
+
+=
+P4080 SEC 4 Node
+
+Description
+
+Node defines the base address of the SEC 4 block.
+This block specifies the address range of all global
+configuration registers for the SEC 4 block.  It
+also receives interrupts from the Run Time Integrity Check
+(RTIC) function within the SEC 4 block.
+
+PROPERTIES
+
+   - compatible
+  Usage: required
+  Value type: string
+  Definition: Must include fsl,p4080-sec4.0,fsl,sec-4.0
+
+   - #address-cells
+   Usage: required
+   Value type: u32
+   Definition: A standard property.  Defines the number of cells
+   for representing physical addresses in child nodes.
+
+   - #size-cells
+   Usage: required
+   Value type: u32
+   Definition: A standard property.  Defines the number of cells
+   for representing the size of physical addresses in
+   child nodes.
+
+   - reg
+  Usage: required
+  Value type: prop-encoded-array
+  Definition: A standard property.  Specifies the physical
+  address and length of the SEC4.0 configuration registers.
+  registers
+
+   - ranges
+   Usage: required
+   Value type: prop-encoded-array
+   Definition: A standard property.  Specifies the physical address
+   range of the SEC 4.0 register space (-SNVS not included).  A
+   triplet that includes the child address, parent address, 
+   length.
+
+   - interrupts
+  Usage: required
+  Value type: prop_encoded-array
+  Definition:  Specifies the interrupts generated by this
+   device.  The value of the interrupts property
+   consists of one interrupt specifier. The format
+   of the specifier is defined by the binding document
+   describing the node's interrupt parent.
+
+   - interrupt-parent
+  Usage: (required if interrupt property is defined)
+  Value type: phandle
+  Definition: A single phandle value that points
+  to the interrupt parent to which the child domain
+  is being mapped.
+
+   Note: All other standard properties (see the ePAPR) are allowed
+   but are optional.
+
+
+EXAMPLE
+   crypto@30 {
+   compatible = fsl,p4080-sec4.0, fsl,sec4.0;
+   #address-cells = 1;
+   #size-cells = 1;
+   reg = 0x30 0x1;
+   ranges = 0 0x30 0x1;
+   interrupt-parent = mpic;
+   interrupts = 92 2;
+   };
+
+=
+P4080 Job Ring (JR) Node
+
+Child of the crypto node defines data processing interface to SEC 4
+across the peripheral bus for purposes of processing
+cryptographic descriptors. The specified 

[PATCH 0/3] crypto: add support for the Freescale SEC4/CAAM

2011-03-09 Thread Kim Phillips
splitting and resending due to apparent 100KB message limit imposed by
linux-crypto and devicetree-discuss mailing lists.

No content has been changed from the original post that made it through
linuxppc-dev's 400KB limit, available here:

http://patchwork.ozlabs.org/patch/86051/

 .../devicetree/bindings/crypto/fsl-sec4.txt|  409 +
 arch/powerpc/boot/dts/p4080ds.dts  |   95 ++-
 drivers/crypto/Kconfig |2 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/caam/Kconfig|   72 +
 drivers/crypto/caam/Makefile   |8 +
 drivers/crypto/caam/caamalg.c  | 1163 ++
 drivers/crypto/caam/compat.h   |   35 +
 drivers/crypto/caam/ctrl.c |  270 
 drivers/crypto/caam/desc.h | 1605 
 drivers/crypto/caam/desc_constr.h  |  204 +++
 drivers/crypto/caam/error.c|  248 +++
 drivers/crypto/caam/error.h|   10 +
 drivers/crypto/caam/intern.h   |  113 ++
 drivers/crypto/caam/jr.c   |  523 +++
 drivers/crypto/caam/jr.h   |   21 +
 drivers/crypto/caam/regs.h |  663 
 17 files changed, 5441 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/crypto/fsl-sec4.txt
 create mode 100644 drivers/crypto/caam/Kconfig
 create mode 100644 drivers/crypto/caam/Makefile
 create mode 100644 drivers/crypto/caam/caamalg.c
 create mode 100644 drivers/crypto/caam/compat.h
 create mode 100644 drivers/crypto/caam/ctrl.c
 create mode 100644 drivers/crypto/caam/desc.h
 create mode 100644 drivers/crypto/caam/desc_constr.h
 create mode 100644 drivers/crypto/caam/error.c
 create mode 100644 drivers/crypto/caam/error.h
 create mode 100644 drivers/crypto/caam/intern.h
 create mode 100644 drivers/crypto/caam/jr.c
 create mode 100644 drivers/crypto/caam/jr.h
 create mode 100644 drivers/crypto/caam/regs.h

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.

2011-03-09 Thread Jain Priyanka-B32167
Dear Wolfram,

Though register-set looks identical but features were different. And also 
manufacturer is different.
But still it might be possible that we can reuse ds1307.c with some 
modification.
But if I look at the drivers present in drivers/rtc folder. Most of them looks 
similar but still there are different drivers for different chips.

Please suggest which way is more preferred: modifying existing drivers(of 
different manufacturer) or writing new driver. 

Thanks
Priyanka

 -Original Message-
 From: Wolfram Sang [mailto:w.s...@pengutronix.de]
 Sent: Thursday, March 03, 2011 2:53 PM
 To: rtc-li...@googlegroups.com
 Cc: linuxppc-dev@lists.ozlabs.org; a.zu...@towertech.it;
 p_gortma...@yahoo.com; a...@linux-foundation.org; Jain Priyanka-B32167
 Subject: Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
 
 Hi,
 
  +/*
  + * This file provides Date  Time support (no alarms) for PT7C4338
 chip.
  + *
  + * This file is based on drivers/rtc/rtc-ds1307.c
 
 Please explain why you can't use rtc-ds1307 directly (or with slight
 modifications). I might have missed something but the register-set looks
 identical to me?
 
 Regards,
 
Wolfram
 
 --
 Pengutronix e.K.   | Wolfram Sang
 |
 Industrial Linux Solutions | http://www.pengutronix.de/
 |

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: disable MSI using new interface if possible

2011-03-09 Thread Michael Ellerman
On Wed, 2011-03-09 at 16:28 -0800, Joe Perches wrote:
 On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
  True my last patch may have been two years ago, but I _wrote the entire
  file_, and essentially no one else has ever touched it.
  
   $ ./scripts/get_maintainer.pl -f arch/powerpc/platforms/pseries/msi.c
   Benjamin Herrenschmidt b...@kernel.crashing.org (supporter:LINUX FOR 
   POWERPC...)
   Paul Mackerras pau...@samba.org (supporter:LINUX FOR POWERPC...)
   Grant Likely grant.lik...@secretlab.ca (maintainer:OPEN FIRMWARE AND...)
   linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
   linux-ker...@vger.kernel.org (open list)
   devicetree-disc...@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
   
   If you don't like how it currently works, suggest
   improvements.
  
  I think I was suggesting that I should be in that list :)
 
 $ ./scripts/get_maintainer.pl -f --git-blame 
 arch/powerpc/platforms/pseries/msi.c
 Benjamin Herrenschmidt b...@kernel.crashing.org (supporter:LINUX FOR 
 POWERPC...,commits:8/11=73%)
 Paul Mackerras pau...@samba.org (supporter:LINUX FOR 
 POWERPC...,commits:4/11=36%)
 Grant Likely grant.lik...@secretlab.ca (maintainer:OPEN FIRMWARE AND...)
 Michael Ellerman mich...@ellerman.id.au (authored 
 lines:481/481=100%,commits:11/11=100%)
 Linas Vepstas li...@austin.ibm.com (commits:1/11=9%)
 linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
 linux-ker...@vger.kernel.org (open list)
 devicetree-disc...@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)

That's awesome. But it's not the default, so hardly anyone will ever use
it :)

cheers


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 17/18] powerpc/smp: Increase vdso_data-processorCount, not just decrease it

2011-03-09 Thread Michael Ellerman
On Tue, 2011-03-08 at 17:37 +1100, Benjamin Herrenschmidt wrote:
 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 ---
  arch/powerpc/kernel/smp.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
 index e337073..6023395 100644
 --- a/arch/powerpc/kernel/smp.c
 +++ b/arch/powerpc/kernel/smp.c
 @@ -551,6 +551,10 @@ void __devinit start_secondary(void *unused)
  
   secondary_cpu_time_init();
  
 +#ifdef CONFIG_PPC64
 + if (system_state == SYSTEM_RUNNING)
 + vdso_data-processorCount++;
 +#endif

So the SYSTEM_RUNNING check is to avoid clashing with the logic in
smp_setup_cpu_maps() I presume:

arch/powerpc/kernel/setup-common.c: vdso_data-processorCount = 
num_present_cpus();


But why not remove that, and let the increment in start_secondary() do
all the work?

With the current code if a cpu is present but fails to come up the count
will be wrong I think.

cheers



signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: disable MSI using new interface if possible

2011-03-09 Thread Joe Perches
On Thu, 2011-03-10 at 14:35 +1100, Michael Ellerman wrote:
 On Wed, 2011-03-09 at 16:28 -0800, Joe Perches wrote:
  On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
   True my last patch may have been two years ago, but I _wrote the entire
   file_, and essentially no one else has ever touched it.
If you don't like how it currently works, suggest
improvements.
   I think I was suggesting that I should be in that list :)
  $ ./scripts/get_maintainer.pl -f --git-blame 
  arch/powerpc/platforms/pseries/msi.c
  Benjamin Herrenschmidt b...@kernel.crashing.org (supporter:LINUX FOR 
  POWERPC...,commits:8/11=73%)
  Paul Mackerras pau...@samba.org (supporter:LINUX FOR 
  POWERPC...,commits:4/11=36%)
  Grant Likely grant.lik...@secretlab.ca (maintainer:OPEN FIRMWARE AND...)
  Michael Ellerman mich...@ellerman.id.au (authored 
  lines:481/481=100%,commits:11/11=100%)
  Linas Vepstas li...@austin.ibm.com (commits:1/11=9%)
  linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
  linux-ker...@vger.kernel.org (open list)
  devicetree-disc...@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
 That's awesome. But it's not the default, so hardly anyone will ever use
 it :)

It's not the default for a few reasons:

o It can take a _long_ time to run
o Linus Torvalds is still the author of record
  for all the files in the initial commit
o For files with activity, it doesn't add very
  much useful as old commit authors do also tend
  to show up in the new commits.
o It can show maintainers that are no longer
  active.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 17/18] powerpc/smp: Increase vdso_data-processorCount, not just decrease it

2011-03-09 Thread Benjamin Herrenschmidt
On Thu, 2011-03-10 at 14:41 +1100, Michael Ellerman wrote:
 
 So the SYSTEM_RUNNING check is to avoid clashing with the logic in
 smp_setup_cpu_maps() I presume:
 
 arch/powerpc/kernel/setup-common.c: vdso_data-processorCount = 
 num_present_cpus();
 
 
 But why not remove that, and let the increment in start_secondary() do
 all the work?
 
 With the current code if a cpu is present but fails to come up the count
 will be wrong I think. 

I agree, on the other hand I'm worried about the way that things it
used in lparcfg.c (which looks bogus regardless) and it's not clear
to me what userspace uses it for (I bet some licencing stuff :-)

The lparcfg bit looks like something that should turn into counting
possible processors I suppose but it's hard to tell.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: disable MSI using new interface if possible

2011-03-09 Thread Florian Mickler
Am 10.03.2011 04:50 schrieb Joe Perches j...@perches.com:

 On Thu, 2011-03-10 at 14:35 +1100, Michael Ellerman wrote:
  On Wed, 2011-03-09 at 16:28 -0800, Joe Perches wrote:
   On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
True my last patch may have been two years ago, but I _wrote the
entire
file_, and essentially no one else has ever touched it.
 If you don't like how it currently works, suggest
 improvements.
I think I was suggesting that I should be in that list :)
   $ ./scripts/get_maintainer.pl -f --git-blame
arch/powerpc/platforms/pseries/msi.c
   Benjamin Herrenschmidt b...@kernel.crashing.org (supporter:LINUX FOR
POWERPC...,commits:8/11=73%)
   Paul Mackerras pau...@samba.org (supporter:LINUX FOR
POWERPC...,commits:4/11=36%)
   Grant Likely grant.lik...@secretlab.ca (maintainer:OPEN FIRMWARE
AND...)
   Michael Ellerman mich...@ellerman.id.au (authored
lines:481/481=100%,commits:11/11=100%)
   Linas Vepstas li...@austin.ibm.com (commits:1/11=9%)
   linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
   linux-ker...@vger.kernel.org (open list)
   devicetree-disc...@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
  That's awesome. But it's not the default, so hardly anyone will ever use
  it :)

 It's not the default for a few reasons:

 o It can take a _long_ time to run
 o Linus Torvalds is still the author of record
  for all the files in the initial commit
 o For files with activity, it doesn't add very
  much useful as old commit authors do also tend
  to show up in the new commits.
 o It can show maintainers that are no longer
  active.

Michael, maybe I'm missing something,  but why don't you have a MAINTAINERS
entry for that file? That would fix it for you.

Regards, Flo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev