* [PATCH] hvc_console: display printk messages on console.
From: Miche Baker-Harvey @ 2011-10-05 17:48 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Miche Baker-Harvey, linuxppc-dev, linux-kernel
printk only works for "registered consoles." Currently, the hvc_console
code calls register_console() from hvc_instantiate(), but that's only
used in the early console case. In hvc_alloc(), register_console() was
not called.
Add a call to register_console() in hvc_alloc(), set up the index in
the hvc_console, and set up the necessary vtermnos[] and cons_op[]
entries so that printk functions work.
Signed-off-by: Miche Baker-Harvey <miche@google.com>
---
However, I'm not sure how this is supposed to be working, and not at all
sure how this should tie in with command line selection of the console,
or if there are other related issues I may have missed. I'd really
appreciate your comments.
---
drivers/tty/hvc/hvc_console.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index e9cba13..6add6cd 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -790,7 +790,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
* find index to use:
* see if this vterm id matches one registered for console.
*/
- for (i=0; i < MAX_NR_HVC_CONSOLES; i++)
+ for (i = 0; i < MAX_NR_HVC_CONSOLES; i++)
if (vtermnos[i] == hp->vtermno &&
cons_ops[i] == hp->ops)
break;
@@ -800,9 +800,13 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
i = ++last_hvc;
hp->index = i;
+ hvc_console.index = i;
+ vtermnos[i] = vtermno;
+ cons_ops[i] = ops;
list_add_tail(&(hp->next), &hvc_structs);
spin_unlock(&hvc_structs_lock);
+ register_console(&hvc_console);
return hp;
}
@@ -813,6 +817,7 @@ int hvc_remove(struct hvc_struct *hp)
unsigned long flags;
struct tty_struct *tty;
+ unregister_console(&hvc_console);
spin_lock_irqsave(&hp->lock, flags);
tty = tty_kref_get(hp->tty);
--
1.7.3.1
^ permalink raw reply related
* Re: BUG: scheduling while atomic:
From: Scott Wood @ 2011-10-05 17:43 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE014A35@HYD-MKD-MBX4.wipro.com>
On 10/05/2011 06:24 AM, smitha.vanga@wipro.com wrote:
> Hi Scoot,
>
> When my ISR gets exeuted I get a below BUG. Could let me what I am
> doing wrong in the ISR?
>
>
> BUG: scheduling while atomic: IRQ-20/0x0fff0000/108
> Call Trace:
> [C3AEFEC0] [C0007CCC] (unreliable)
> [C3AEFEF0] [C0017F10]
> [C3AEFF00] [C0268818]
> [C3AEFF50] [C0017F44]
> [C3AEFF60] [C0018044]
> [C3AEFF70] [C0046A90]
> [C3AEFF90] [C0046D90]
> [C3AEFFC0] [C0032AFC]
> [C3AEFFF0] [C000F5AC]
This trace is useless without debugging symbols from your kernel image.
Please enable kallsyms.
> Below is the code :
> *My ISR*
>
> irqreturn_t cpld_irq_handler(int irq, void * dev_id, struct pt_regs *regs)
>
> {
>
> wake_up(&cpld_intr_wait);
>
> atomic_inc(&cpld_intr_data); /* incrementing this will indicate the
> poll() that the interrupt is occured */
None of this should schedule when run in interrupt context.
The only thing that comes to mind is possibly wake_up(), if you're
running the RT patch but somehow the interrupt isn't in a thread.
> return 0;
Not related, but return IRQ_HANDLED;
-Scott
^ permalink raw reply
* Re: Defintion of kernstart_addr
From: Dave Hansen @ 2011-10-05 16:51 UTC (permalink / raw)
To: Suzuki Poulose; +Cc: Josh Boyer, linux ppc dev
In-Reply-To: <4E8C525F.4090000@in.ibm.com>
On Wed, 2011-10-05 at 18:19 +0530, Suzuki Poulose wrote:
> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) -
> PHYSICAL_START + KERNELBASE)
>
> where,
> PHYSICAL_START is #define'd to kernstart_addr variable, updated at boot
Where kernstart_addr is the physical address of where we loaded the
kernel. But, this has the side-effect of also shifting the kernel's
identity mapping (the 1:1 virtual-to-physical map) up by that amount.
I'm unconvinced that this movement of the identity mapping is necessary.
Even if it is, Suzuki mentions:
> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) -
> PHYSICAL_START + KERNELBASE)
> where:
> PHYSICAL_START is kernstart_addr - a variable updated at runtime.
> KERNELBASE is the compile time Virtual base address of kernel.
>
> This won't work for us, as the kernstart_addr may change at runtime, even
> though the mapping doesn't change.
That seems to tell me that PHYSICAL_START and kernstart_addr shouldn't
be the same variable. We should break them apart so that we can move
the kernel's starting physical address without changing the virt/phys
mapping.
Which, I'm fearing, was what Suzuki's first patch did, and I failed to
grok it.
-- Dave
^ permalink raw reply
* RE: scheduling while atomic:
From: David Laight @ 2011-10-05 16:05 UTC (permalink / raw)
To: smitha.vanga, scottwood; +Cc: linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE014A35@HYD-MKD-MBX4.wipro.com>
Not entirely relevant to the error you are seeing,
but your ISR is:
> irqreturn_t cpld_irq_handler(int irq, void * dev_id, struct
pt_regs *regs)
> {
> wake_up(&cpld_intr_wait);
> atomic_inc(&cpld_intr_data); /* incrementing this will
indicate the poll() that the interrupt is occured */
> return 0;
> }
You need to set 'cpld_intr_data' before clling wake_up() otherwise
the sleeping process might run on another cpu before the data item
changes.
You also don't need to use the 'atomic' functions.
Writing to a 'volatile' data item is sufficent.
You don't want to count interrupts, just mark they have happened.
Maybe your problem it that the ISR doesn't do anything to
cause the hardware to drop its IRQ.
David
^ permalink raw reply
* Re: [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD
From: Thomas Gleixner @ 2011-10-05 15:31 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20111005132949.GA25028@iram.es>
On Wed, 5 Oct 2011, Gabriel Paubert wrote:
> On Wed, Oct 05, 2011 at 12:30:49PM -0000, Thomas Gleixner wrote:
> > The following series marks the obvious interrupts IRQF_NO_THREAD to
> > prevent forced interrupt threading - no guarantee of completeness :)
> >
> > The last patch enables the forced threading mechanism in the core
> > code, which in turn enables the "irqthreaded" commandline option.
>
> Is there any description of what "interrupt threading" means?
That means that the interrupt handler is running in a thread. The
interrupt itself merily wakes the thread. That's a debugging option in
mainline - it comes handy when interrupt handlers crash as the system
just kills the thread, but stays otherwise alive. If the same
situation happens in the normal hard interrupt context, then it takes
them machine down completely.
Aside of that it's a prerequisite to support PREEMPT_RT on your
arch/machine.
> I'm only looking for a pointer to a web page, a mailing list thread
https://lwn.net/Articles/429690/
> (I am no more subscribed to lkml, too many things to do, so maybe
> it has been discussed but it comes out of the blue on linuxppc-dev),
> or a well commented git commit?
>
> >From followups, I see that cascaded interrupt controller should
> not be threaded. I suspect that the private VME bridge driver
> (Universe chip) I maintain here will need it: clients request
> a given VME interrupt (level/vector) and specify an interrupt
> handler which is called by the handler for the PCI interrupt.
Can't tell as I don't know how your code looks like. If your
subinterrupts are registered with the core interrupt system and the
drivers install their handlers via request_irq(), then yes. If you
just have your own registration and handling stuff (which you
shouldn't) then you might be better off to let the dispatch interrupt
handler be threaded so that all the demuxed ones run in that same
thread.
Thanks,
tglx
^ permalink raw reply
* Re: [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD
From: Gabriel Paubert @ 2011-10-05 13:29 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev
In-Reply-To: <20111005122122.553832402@linutronix.de>
On Wed, Oct 05, 2011 at 12:30:49PM -0000, Thomas Gleixner wrote:
> The following series marks the obvious interrupts IRQF_NO_THREAD to
> prevent forced interrupt threading - no guarantee of completeness :)
>
> The last patch enables the forced threading mechanism in the core
> code, which in turn enables the "irqthreaded" commandline option.
Is there any description of what "interrupt threading" means?
I'm only looking for a pointer to a web page, a mailing list thread
(I am no more subscribed to lkml, too many things to do, so maybe
it has been discussed but it comes out of the blue on linuxppc-dev),
or a well commented git commit?
>From followups, I see that cascaded interrupt controller should
not be threaded. I suspect that the private VME bridge driver
(Universe chip) I maintain here will need it: clients request
a given VME interrupt (level/vector) and specify an interrupt
handler which is called by the handler for the PCI interrupt.
Regards,
Gabriel
^ permalink raw reply
* Defintion of kernstart_addr
From: Suzuki Poulose @ 2011-10-05 12:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: Josh Boyer, linux ppc dev, Dave Hansen
Hi Kumar,
I have been working on the CONFIG_RELOCATABLE support for PPC44x, trying to process
the relocations generated by the compiler. Since the TLB size is 256M, we cannot
enforce a page aligned kernel load address.
I came across some issues with the __va() / __pa() translations, while the kernel
load address is not page aligned.
We have the following definition :
#define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) -
PHYSICAL_START + KERNELBASE)
where,
PHYSICAL_START is #define'd to kernstart_addr variable, updated at boot
time.
I would like to know the exact meaning of the value in kerstart_addr.
For e.g:
When we have :
PAGE_OFFSET = KERNELBASE = 0xc0000000,
and
kernel loaded at 64M (0x4000000)
and
we map Physical address 0 to Virtual address 0xc0000000.
What should be the value of kernstart_addr ? Should it be
0 ? Or should it be 0x4000000 ?
If we choose, 0x4000000, we get the translations wrong :
__va(0x1) = 0x1 - 0x4000000 + 0xc0000000
= 0xbc000001
If we select 0, we have problems at other places where we assume,
PHYSICAL_START to be the va() of _stext.
Thanks
Suzuki
^ permalink raw reply
* [patch 2/4] powerpc: wsp: Mark opb cascade handler IRQF_NO_THREAD
From: Thomas Gleixner @ 2011-10-05 12:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20111005122122.553832402@linutronix.de>
Cascade handlers must run in hard interrupt context.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/powerpc/platforms/wsp/opb_pic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/powerpc/platforms/wsp/opb_pic.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/wsp/opb_pic.c
+++ linux-2.6/arch/powerpc/platforms/wsp/opb_pic.c
@@ -320,7 +320,8 @@ void __init opb_pic_init(void)
}
/* Attach opb interrupt handler to new virtual IRQ */
- rc = request_irq(virq, opb_irq_handler, 0, "OPB LS Cascade", opb);
+ rc = request_irq(virq, opb_irq_handler, IRQF_NO_THREAD,
+ "OPB LS Cascade", opb);
if (rc) {
printk("opb: request_irq failed: %d\n", rc);
continue;
^ permalink raw reply
* [patch 1/4] powerpc: 85xx: Mark cascade irq IRQF_NO_THREAD
From: Thomas Gleixner @ 2011-10-05 12:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20111005122122.553832402@linutronix.de>
Cascade interrupt must run in hard interrupt context.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_cds.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -178,7 +178,7 @@ static irqreturn_t mpc85xx_8259_cascade_
static struct irqaction mpc85xxcds_8259_irqaction = {
.handler = mpc85xx_8259_cascade_action,
- .flags = IRQF_SHARED,
+ .flags = IRQF_SHARED | IRQF_NO_THREAD,
.name = "8259 cascade",
};
#endif /* PPC_I8259 */
^ permalink raw reply
* [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD
From: Thomas Gleixner @ 2011-10-05 12:30 UTC (permalink / raw)
To: linuxppc-dev
The following series marks the obvious interrupts IRQF_NO_THREAD to
prevent forced interrupt threading - no guarantee of completeness :)
The last patch enables the forced threading mechanism in the core
code, which in turn enables the "irqthreaded" commandline option.
Thanks,
tglx
^ permalink raw reply
* [patch 3/4] powerpc: Mark IPI interrupts IRQF_NO_THREAD
From: Thomas Gleixner @ 2011-10-05 12:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20111005122122.553832402@linutronix.de>
IPI handlers cannot be threaded. Remove the obsolete IRQF_DISABLED
flag (see commit e58aa3d2) while at it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/powerpc/kernel/smp.c | 2 +-
arch/powerpc/platforms/powermac/smp.c | 4 ++--
arch/powerpc/sysdev/xics/xics-common.c | 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6/arch/powerpc/kernel/smp.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6/arch/powerpc/kernel/smp.c
@@ -170,7 +170,7 @@ int smp_request_message_ipi(int virq, in
return 1;
}
#endif
- err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
+ err = request_irq(virq, smp_ipi_action[msg], IRQF_NO_THREAD|IRQF_PERCPU,
smp_ipi_name[msg], 0);
WARN(err < 0, "unable to request_irq %d for %s (rc %d)\n",
virq, smp_ipi_name[msg], err);
Index: linux-2.6/arch/powerpc/platforms/powermac/smp.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/smp.c
+++ linux-2.6/arch/powerpc/platforms/powermac/smp.c
@@ -200,7 +200,7 @@ static int psurge_secondary_ipi_init(voi
if (psurge_secondary_virq)
rc = request_irq(psurge_secondary_virq, psurge_ipi_intr,
- IRQF_DISABLED|IRQF_PERCPU, "IPI", NULL);
+ IRQF_NO_THREAD|IRQF_PERCPU, "IPI", NULL);
if (rc)
pr_err("Failed to setup secondary cpu IPI\n");
@@ -408,7 +408,7 @@ static int __init smp_psurge_kick_cpu(in
static struct irqaction psurge_irqaction = {
.handler = psurge_ipi_intr,
- .flags = IRQF_DISABLED|IRQF_PERCPU,
+ .flags = IRQF_NO_THREAD|IRQF_PERCPU,
.name = "primary IPI",
};
Index: linux-2.6/arch/powerpc/sysdev/xics/xics-common.c
===================================================================
--- linux-2.6.orig/arch/powerpc/sysdev/xics/xics-common.c
+++ linux-2.6/arch/powerpc/sysdev/xics/xics-common.c
@@ -134,11 +134,11 @@ static void xics_request_ipi(void)
BUG_ON(ipi == NO_IRQ);
/*
- * IPIs are marked IRQF_DISABLED as they must run with irqs
- * disabled, and PERCPU. The handler was set in map.
+ * IPIs are marked PERCPU and also IRQF_NO_THREAD as they must
+ * run in hard interrupt context. The handler was set in map.
*/
BUG_ON(request_irq(ipi, icp_ops->ipi_action,
- IRQF_DISABLED|IRQF_PERCPU, "IPI", NULL));
+ IRQF_NO_THREAD|IRQF_PERCPU, "IPI", NULL));
}
int __init xics_smp_probe(void)
^ permalink raw reply
* [patch 4/4] powerpc: Allow irq threading
From: Thomas Gleixner @ 2011-10-05 12:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20111005122122.553832402@linutronix.de>
All interrupts which must be non threaded are marked
IRQF_NO_THREAD. So it's safe to allow force threaded handlers.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -132,6 +132,7 @@ config PPC
select IRQ_PER_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
+ select IRQ_FORCED_THREADING
select HAVE_RCU_TABLE_FREE if SMP
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_BPF_JIT if (PPC64 && NET)
^ permalink raw reply
* BUG: scheduling while atomic:
From: smitha.vanga @ 2011-10-05 11:24 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]
Hi Scoot,
When my ISR gets exeuted I get a below BUG. Could let me what I am doing wrong in the ISR?
BUG: scheduling while atomic: IRQ-20/0x0fff0000/108
Call Trace:
[C3AEFEC0] [C0007CCC] (unreliable)
[C3AEFEF0] [C0017F10]
[C3AEFF00] [C0268818]
[C3AEFF50] [C0017F44]
[C3AEFF60] [C0018044]
[C3AEFF70] [C0046A90]
[C3AEFF90] [C0046D90]
[C3AEFFC0] [C0032AFC]
[C3AEFFF0] [C000F5AC]
Below is the code :
My ISR
irqreturn_t cpld_irq_handler(int irq, void * dev_id, struct pt_regs *regs)
{
wake_up(&cpld_intr_wait);
atomic_inc(&cpld_intr_data); /* incrementing this will indicate the poll() that the interrupt is occured */
return 0;
}
DRIVER_INIT
static int __init gpio_init(void)
{
int ret = 0;
int virq;
atomic_set(&cpld_intr_data, 0); /* initialize the Interrupt indicator */
init_waitqueue_head(&cpld_intr_wait); /* Initialize the wait queue */
virq = irq_create_mapping(NULL, CPLD1_INTERRUPT);
if ((ret = request_irq(virq,cpld_irq_handler, 0, GPIO_CHAR_PATH, NULL))!=0)
{
printk(KERN_ERR "gpio_init: Could not grab IRQ line for CPLD ret = %d\n",ret);
goto err1;
}
if((s_nGPIOMajor = register_chrdev(MPC8247_DEVICE_MAJOR_NUM, GPIO_CHAR_PATH, &gpio_fops))<0)
{
GPIO_DBG2("GPIO_DRIVER : unable to get major %d\n", s_nGPIOMajor);
return s_nGPIOMajor;
}else{
GPIO_DBG2("GPIO_DRIVER : major = %x\n", s_nGPIOMajor );
}
return 0;
}
Thanks in Advance
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: Type: text/html, Size: 5576 bytes --]
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Eli Cohen @ 2011-10-05 8:15 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Eli Cohen, netdev@vger.kernel.org, linuxppc-dev, Yevgeny Petrilin
In-Reply-To: <20111004202620.GA3455@oc1711230544.ibm.com>
On Tue, Oct 04, 2011 at 05:26:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
I believe we have an endianess problem here. The source buffer is in
big endian - in x86 archs, it will rich the pci device unswapped since
both x86 and pci are little endian. In ppc, it wil be swapped by the
chipset so it will reach the device in little endian which is wrong.
So, in mlx4_bf_copy, you could loop over the buffer and swap32 the all
the dwords before the call to __iowrite64_copy. Of course which should
fix this in an arch independent manner. Let me know this works for
you.
> On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
> > On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
> >
> > .../...
> >
> > > > Can you also send me the output of ethtool -i?
> > > > It seems that there is a problem with write combining on Power processors, we will check this issue.
> > > >
> > > > Yevgeny
> > >
> > > Hello, Yevgeny.
> > >
> > > You will find the output of ethtool -i below.
> > >
> > > I am copying Ben and powerpc list, in case this is an issue with Power
> > > processors. They can provide us some more insight into this.
> >
> > May I get some background please ? :-)
> >
> > I'm not aware of a specific issue with write combining but I'd need to
> > know more about what you are doing and the code to do it to comment on
> > whether it should work or not.
> >
> > Cheers,
> > Ben.
> >
> >
>
> Hello, Ben.
>
> Sorry for that. I am testing mlx4_en driver on a POWER. Yevgeny has
> added blue frame support, that does not require writing to the device
> memory to indicate a new packet (the doorbell register as it is called).
>
> Well, the ring is getting full with no interrupt or packets transmitted.
> I simply added a write to the doorbell register and it works for me.
> Yevgeny says this is not the right fix, claiming there is a problem with
> write combining on POWER. The code uses memory barriers, so I don't know
> why there is any problem.
>
> I am posting the code here to show better what the situation is.
> Yevgeny can tell more about the device and the driver.
>
> The code below is the driver as of now, including a diff with what I
> changed and had resulted OK for me. Before the blue frame support, the
> only code executed was the else part. I can't tell much what the device
> should be seeing and doing after the blue frame part of the code is
> executed. But it does send the packet if I write to the doorbell
> register.
>
> Yevgeny, can you tell us what the device should be doing and why you
> think this is a problem on POWER? Is it possible that this is simply a
> problem with the firmware version?
>
> Thanks,
> Cascardo.
>
> ---
> if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
> !vlan_tag) {
> *(u32 *) (&tx_desc->ctrl.vlan_tag) |=
> ring->doorbell_qpn;
> op_own |= htonl((bf_index & 0xffff) << 8);
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
>
> wmb();
>
> mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
> long *) &tx_desc->ctrl,
> desc_size);
>
> wmb();
>
> ring->bf.offset ^= ring->bf.buf_size;
> } else {
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
> - wmb();
> - writel(ring->doorbell_qpn, ring->bf.uar->map +
> MLX4_SEND_DOORBELL);
> }
>
> + wmb();
> + writel(ring->doorbell_qpn, ring->bf.uar->map +
> MLX4_SEND_DOORBELL);
> +
> ---
^ permalink raw reply
* RE: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Bounine, Alexandre @ 2011-10-05 2:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: Vinod Koul, linuxppc-dev, linux-kernel
In-Reply-To: <20111004185718.a5806a7e.akpm00@gmail.com>
Andrew Morton wrote:
>=20
> > > No, it can be used all over the place:
> drivers/net/irda/w83977af_ir.c,
> > > drivers/scsi/bnx2fc/bnx2fc_tgt.c,
> > > drivers/net/wireless/rt2x00/rt2x00pci.c,
> > > drivers/crypto/amcc/crypto4xx_core.c and many nmore.
> >
> > In this case I will happily use dma_zalloc_coherent() as soon as
> > it is available
>=20
> geeze, which of us is more lazy?
>=20
> Here we go...
>=20
I have an excuse - I am on vacation. Back to the office in almost two
weeks.
WebMail is the only tool for me right now ;)=20
^ permalink raw reply
* Re: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Andrew Morton @ 2011-10-05 1:57 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: Vinod Koul, linuxppc-dev, linux-kernel
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552022D6319@CORPEXCH1.na.ads.idt.com>
On Tue, 4 Oct 2011 18:38:09 -0700 "Bounine, Alexandre" <Alexandre.Bounine@idt.com> wrote:
> > No, it can be used all over the place: drivers/net/irda/w83977af_ir.c,
> > drivers/scsi/bnx2fc/bnx2fc_tgt.c,
> > drivers/net/wireless/rt2x00/rt2x00pci.c,
> > drivers/crypto/amcc/crypto4xx_core.c and many nmore.
>
> In this case I will happily use dma_zalloc_coherent() as soon as
> it is available
geeze, which of us is more lazy?
Here we go...
From: Andrew Morton <akpm@linux-foundation.org>
Subject: include/linux/dma-mapping.h: add dma_zalloc_coherent()
Lots of driver code does a dma_alloc_coherent() and then zeroes out the
memory with a memset. Make it easy for them.
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
From: Andrew Morton <akpm@linux-foundation.org>
Subject: include-linux-dma-mappingh-add-dma_zalloc_coherent
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/DMA-API.txt | 7 +++++++
include/linux/dma-mapping.h | 10 ++++++++++
2 files changed, 17 insertions(+)
diff -puN include/linux/dma-mapping.h~include-linux-dma-mappingh-add-dma_zalloc_coherent include/linux/dma-mapping.h
--- a/include/linux/dma-mapping.h~include-linux-dma-mappingh-add-dma_zalloc_coherent
+++ a/include/linux/dma-mapping.h
@@ -1,6 +1,7 @@
#ifndef _LINUX_DMA_MAPPING_H
#define _LINUX_DMA_MAPPING_H
+#include <linux/string.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/dma-attrs.h>
@@ -117,6 +118,15 @@ static inline int dma_set_seg_boundary(s
return -EIO;
}
+static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+{
+ void *ret = dma_alloc_coherent(dev, size, dma_handle, flag);
+ if (ret)
+ memset(ret, 0, size);
+ return ret;
+}
+
#ifdef CONFIG_HAS_DMA
static inline int dma_get_cache_alignment(void)
{
diff -puN Documentation/DMA-API.txt~include-linux-dma-mappingh-add-dma_zalloc_coherent Documentation/DMA-API.txt
--- a/Documentation/DMA-API.txt~include-linux-dma-mappingh-add-dma_zalloc_coherent
+++ a/Documentation/DMA-API.txt
@@ -50,6 +50,13 @@ specify the GFP_ flags (see kmalloc) for
implementation may choose to ignore flags that affect the location of
the returned memory, like GFP_DMA).
+void *
+dma_zalloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+
+Wraps dma_alloc_coherent() and also zeroes the returned memory if the
+allocation attempt succeeded.
+
void
dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_handle)
_
^ permalink raw reply
* RE: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Bounine, Alexandre @ 2011-10-05 1:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: Vinod Koul, linuxppc-dev, linux-kernel
In-Reply-To: <20111004144353.18087914.akpm00@gmail.com>
Andrew Morton wrote:
>=20
> On Mon, 3 Oct 2011 10:53:45 -0700
> "Bounine, Alexandre" <Alexandre.Bounine@idt.com> wrote:
>=20
> > > > + memset(bd_ptr, 0, bd_num * sizeof(struct
tsi721_dma_desc));
> > > > +
> > > > + dev_dbg(dev, "DMA descriptors @ %p (phys =3D %llx)\n",
> > > > + bd_ptr, (unsigned long long)bd_phys);
> > > > +
> > > > + /* Allocate space for descriptor status FIFO */
> > > > + sts_size =3D (bd_num >=3D TSI721_DMA_MINSTSSZ) ?
> > > > + bd_num :
TSI721_DMA_MINSTSSZ;
> > > > + sts_size =3D roundup_pow_of_two(sts_size);
> > > > + sts_ptr =3D dma_alloc_coherent(dev,
> > > > + sts_size * sizeof(struct
> > tsi721_dma_sts),
> > > > + &sts_phys, GFP_KERNEL);
> > > > + if (!sts_ptr) {
> > > > + /* Free space allocated for DMA descriptors */
> > > > + dma_free_coherent(dev,
> > > > + bd_num * sizeof(struct
> > tsi721_dma_desc),
> > > > + bd_ptr, bd_phys);
> > > > + chan->bd_base =3D NULL;
> > > > + return -ENOMEM;
> > > > + }
> > > > +
> > > > + chan->sts_phys =3D sts_phys;
> > > > + chan->sts_base =3D sts_ptr;
> > > > + chan->sts_size =3D sts_size;
> > > > +
> > > > + memset(sts_ptr, 0, sts_size);
> > >
> > > You meant
> >
> > I really need it here. That status block tracks progress by keeping
> > non-zero addresses of processed descriptors.
>=20
> Confused. Are you saying that the use of "sts_size" there was
> intentional?
Sorry, somehow I mistakenly linked this comment to dma_zalloc_coherent()
because of use of memset.
Yes, it should be "sts_size * sizeof(struct tsi721_dma_sts)" as
allocated.
> > >
> > > --- a/drivers/rapidio/devices/tsi721.c~rapidio-tsi721-add-dma-
> engine-
> > > support-fix
> > > +++ a/drivers/rapidio/devices/tsi721.c
> > > @@ -1006,7 +1006,7 @@ static int tsi721_bdma_maint_init(struct
> > > priv->mdma.sts_base =3D sts_ptr;
> > > priv->mdma.sts_size =3D sts_size;
> > >
> > > - memset(sts_ptr, 0, sts_size);
> > > + memset(sts_ptr, 0, sts_size * sizeof(struct tsi721_dma_sts));
> > >
> > > dev_dbg(&priv->pdev->dev,
> > > "desc status FIFO @ %p (phys =3D %llx) size=3D0x%x\n",
> > >
> > > However that's at least two instances where you wanted a
> > > dma_zalloc_coherent(). How's about we give ourselves one?
> >
> > Does this mean that I am on hook for it as a "most frequent user"?
>=20
> No, it can be used all over the place: drivers/net/irda/w83977af_ir.c,
> drivers/scsi/bnx2fc/bnx2fc_tgt.c,
> drivers/net/wireless/rt2x00/rt2x00pci.c,
> drivers/crypto/amcc/crypto4xx_core.c and many nmore.
In this case I will happily use dma_zalloc_coherent() as soon as
it is available
^ permalink raw reply
* Re: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Andrew Morton @ 2011-10-04 21:43 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: Vinod Koul, linux-kernel, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55202291E8D@CORPEXCH1.na.ads.idt.com>
On Mon, 3 Oct 2011 10:53:45 -0700
"Bounine, Alexandre" <Alexandre.Bounine@idt.com> wrote:
> > > + memset(bd_ptr, 0, bd_num * sizeof(struct tsi721_dma_desc));
> > > +
> > > + dev_dbg(dev, "DMA descriptors @ %p (phys = %llx)\n",
> > > + bd_ptr, (unsigned long long)bd_phys);
> > > +
> > > + /* Allocate space for descriptor status FIFO */
> > > + sts_size = (bd_num >= TSI721_DMA_MINSTSSZ) ?
> > > + bd_num : TSI721_DMA_MINSTSSZ;
> > > + sts_size = roundup_pow_of_two(sts_size);
> > > + sts_ptr = dma_alloc_coherent(dev,
> > > + sts_size * sizeof(struct
> tsi721_dma_sts),
> > > + &sts_phys, GFP_KERNEL);
> > > + if (!sts_ptr) {
> > > + /* Free space allocated for DMA descriptors */
> > > + dma_free_coherent(dev,
> > > + bd_num * sizeof(struct
> tsi721_dma_desc),
> > > + bd_ptr, bd_phys);
> > > + chan->bd_base = NULL;
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + chan->sts_phys = sts_phys;
> > > + chan->sts_base = sts_ptr;
> > > + chan->sts_size = sts_size;
> > > +
> > > + memset(sts_ptr, 0, sts_size);
> >
> > You meant
>
> I really need it here. That status block tracks progress by keeping
> non-zero addresses of processed descriptors.
Confused. Are you saying that the use of "sts_size" there was
intentional?
> >
> > --- a/drivers/rapidio/devices/tsi721.c~rapidio-tsi721-add-dma-engine-
> > support-fix
> > +++ a/drivers/rapidio/devices/tsi721.c
> > @@ -1006,7 +1006,7 @@ static int tsi721_bdma_maint_init(struct
> > priv->mdma.sts_base = sts_ptr;
> > priv->mdma.sts_size = sts_size;
> >
> > - memset(sts_ptr, 0, sts_size);
> > + memset(sts_ptr, 0, sts_size * sizeof(struct tsi721_dma_sts));
> >
> > dev_dbg(&priv->pdev->dev,
> > "desc status FIFO @ %p (phys = %llx) size=0x%x\n",
> >
> > However that's at least two instances where you wanted a
> > dma_zalloc_coherent(). How's about we give ourselves one?
>
> Does this mean that I am on hook for it as a "most frequent user"?
No, it can be used all over the place: drivers/net/irda/w83977af_ir.c,
drivers/scsi/bnx2fc/bnx2fc_tgt.c,
drivers/net/wireless/rt2x00/rt2x00pci.c,
drivers/crypto/amcc/crypto4xx_core.c and many nmore.
^ permalink raw reply
* Re: [PATCH 49/55] video: irq: Remove IRQF_DISABLED
From: Florian Tobias Schandinat @ 2011-10-04 20:20 UTC (permalink / raw)
To: Yong Zhang
Cc: linux-fbdev, Paul Gortmaker, Laurent Pinchart, Daniel Walker,
linux-arch, Kukjin Kim, Tomi Valkeinen, Archit Taneja,
David Brown, Anatolij Gustschin, cbe-oss-dev, Wan ZongShun,
linux-arm-msm, Ben Dooks, tglx, linux-omap, linux-arm-kernel,
Geoff Levand, Jiri Kosina, linux-kernel, Bryan Huntsman,
Andrew Morton, linuxppc-dev
In-Reply-To: <1316681962-8217-50-git-send-email-yong.zhang0@gmail.com>
On 09/22/2011 08:59 AM, Yong Zhang wrote:
> Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> Acked-by: David Brown <davidb@codeaurora.org>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/au1200fb.c | 2 +-
> drivers/video/bf54x-lq043fb.c | 2 +-
> drivers/video/bfin-lq035q1-fb.c | 2 +-
> drivers/video/bfin-t350mcqb-fb.c | 2 +-
> drivers/video/bfin_adv7393fb.c | 2 +-
> drivers/video/mb862xx/mb862xxfbdrv.c | 4 ++--
> drivers/video/msm/mddi.c | 2 +-
> drivers/video/msm/mdp.c | 2 +-
> drivers/video/nuc900fb.c | 2 +-
> drivers/video/omap2/displays/panel-taal.c | 2 +-
> drivers/video/ps3fb.c | 2 +-
> drivers/video/pxa3xx-gcu.c | 2 +-
> drivers/video/pxafb.c | 2 +-
> drivers/video/s3c2410fb.c | 2 +-
> drivers/video/sa1100fb.c | 3 +--
> drivers/video/sh_mobile_lcdcfb.c | 2 +-
> drivers/video/tmiofb.c | 2 +-
> drivers/video/vt8500lcdfb.c | 2 +-
> 18 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/au1200fb.c b/drivers/video/au1200fb.c
> index a19a40e..7200559 100644
> --- a/drivers/video/au1200fb.c
> +++ b/drivers/video/au1200fb.c
> @@ -1673,7 +1673,7 @@ static int __devinit au1200fb_drv_probe(struct platform_device *dev)
> /* Now hook interrupt too */
> irq = platform_get_irq(dev, 0);
> ret = request_irq(irq, au1200fb_handle_irq,
> - IRQF_DISABLED | IRQF_SHARED, "lcd", (void *)dev);
> + IRQF_SHARED, "lcd", (void *)dev);
> if (ret) {
> print_err("fail to request interrupt line %d (err: %d)",
> irq, ret);
> diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
> index 2464b91..56720fb 100644
> --- a/drivers/video/bf54x-lq043fb.c
> +++ b/drivers/video/bf54x-lq043fb.c
> @@ -633,7 +633,7 @@ static int __devinit bfin_bf54x_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - if (request_irq(info->irq, bfin_bf54x_irq_error, IRQF_DISABLED,
> + if (request_irq(info->irq, bfin_bf54x_irq_error, 0,
> "PPI ERROR", info) < 0) {
> printk(KERN_ERR DRIVER_NAME
> ": unable to request PPI ERROR IRQ\n");
> diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
> index 23b6c4b..c633068 100644
> --- a/drivers/video/bfin-lq035q1-fb.c
> +++ b/drivers/video/bfin-lq035q1-fb.c
> @@ -695,7 +695,7 @@ static int __devinit bfin_lq035q1_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - ret = request_irq(info->irq, bfin_lq035q1_irq_error, IRQF_DISABLED,
> + ret = request_irq(info->irq, bfin_lq035q1_irq_error, 0,
> DRIVER_NAME" PPI ERROR", info);
> if (ret < 0) {
> dev_err(&pdev->dev, "unable to request PPI ERROR IRQ\n");
> diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
> index d8de29f..d5e1267 100644
> --- a/drivers/video/bfin-t350mcqb-fb.c
> +++ b/drivers/video/bfin-t350mcqb-fb.c
> @@ -529,7 +529,7 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - ret = request_irq(info->irq, bfin_t350mcqb_irq_error, IRQF_DISABLED,
> + ret = request_irq(info->irq, bfin_t350mcqb_irq_error, 0,
> "PPI ERROR", info);
> if (ret < 0) {
> printk(KERN_ERR DRIVER_NAME
> diff --git a/drivers/video/bfin_adv7393fb.c b/drivers/video/bfin_adv7393fb.c
> index 8486f54..811dd7f 100644
> --- a/drivers/video/bfin_adv7393fb.c
> +++ b/drivers/video/bfin_adv7393fb.c
> @@ -481,7 +481,7 @@ static int __devinit bfin_adv7393_fb_probe(struct i2c_client *client,
> goto out_4;
> }
>
> - if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, IRQF_DISABLED,
> + if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, 0,
> "PPI ERROR", fbdev) < 0) {
> dev_err(&client->dev, "unable to request PPI ERROR IRQ\n");
> ret = -EFAULT;
> diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
> index 12a634a..11a7a33 100644
> --- a/drivers/video/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/mb862xx/mb862xxfbdrv.c
> @@ -738,7 +738,7 @@ static int __devinit of_platform_mb862xx_probe(struct platform_device *ofdev)
> if (mb862xx_gdc_init(par))
> goto io_unmap;
>
> - if (request_irq(par->irq, mb862xx_intr, IRQF_DISABLED,
> + if (request_irq(par->irq, mb862xx_intr, 0,
> DRV_NAME, (void *)par)) {
> dev_err(dev, "Cannot request irq\n");
> goto io_unmap;
> @@ -1074,7 +1074,7 @@ static int __devinit mb862xx_pci_probe(struct pci_dev *pdev,
> if (mb862xx_pci_gdc_init(par))
> goto io_unmap;
>
> - if (request_irq(par->irq, mb862xx_intr, IRQF_DISABLED | IRQF_SHARED,
> + if (request_irq(par->irq, mb862xx_intr, IRQF_SHARED,
> DRV_NAME, (void *)par)) {
> dev_err(dev, "Cannot request irq\n");
> goto io_unmap;
> diff --git a/drivers/video/msm/mddi.c b/drivers/video/msm/mddi.c
> index 178b072..4527cbf 100644
> --- a/drivers/video/msm/mddi.c
> +++ b/drivers/video/msm/mddi.c
> @@ -715,7 +715,7 @@ static int __devinit mddi_probe(struct platform_device *pdev)
>
> mddi->int_enable = 0;
> mddi_writel(mddi->int_enable, INTEN);
> - ret = request_irq(mddi->irq, mddi_isr, IRQF_DISABLED, "mddi",
> + ret = request_irq(mddi->irq, mddi_isr, 0, "mddi",
> &mddi->client_data);
> if (ret) {
> printk(KERN_ERR "mddi: failed to request enable irq!\n");
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 2750ed2..cb2ddf1 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -426,7 +426,7 @@ int mdp_probe(struct platform_device *pdev)
> goto error_get_clk;
> }
>
> - ret = request_irq(mdp->irq, mdp_isr, IRQF_DISABLED, "msm_mdp", mdp);
> + ret = request_irq(mdp->irq, mdp_isr, 0, "msm_mdp", mdp);
> if (ret)
> goto error_request_irq;
> disable_irq(mdp->irq);
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index 37dd850..d1fbbd8 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -587,7 +587,7 @@ static int __devinit nuc900fb_probe(struct platform_device *pdev)
> fbinfo->flags = FBINFO_FLAG_DEFAULT;
> fbinfo->pseudo_palette = &fbi->pseudo_pal;
>
> - ret = request_irq(irq, nuc900fb_irqhandler, IRQF_DISABLED,
> + ret = request_irq(irq, nuc900fb_irqhandler, 0,
> pdev->name, fbinfo);
> if (ret) {
> dev_err(&pdev->dev, "cannot register irq handler %d -err %d\n",
> diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
> index 7f91002..80c3f6a 100644
> --- a/drivers/video/omap2/displays/panel-taal.c
> +++ b/drivers/video/omap2/displays/panel-taal.c
> @@ -1034,7 +1034,7 @@ static int taal_probe(struct omap_dss_device *dssdev)
> gpio_direction_input(gpio);
>
> r = request_irq(gpio_to_irq(gpio), taal_te_isr,
> - IRQF_DISABLED | IRQF_TRIGGER_RISING,
> + IRQF_TRIGGER_RISING,
> "taal vsync", dssdev);
>
> if (r) {
> diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> index 65560a1..213fbbc 100644
> --- a/drivers/video/ps3fb.c
> +++ b/drivers/video/ps3fb.c
> @@ -1082,7 +1082,7 @@ static int __devinit ps3fb_probe(struct ps3_system_bus_device *dev)
> }
>
> retval = request_irq(ps3fb.irq_no, ps3fb_vsync_interrupt,
> - IRQF_DISABLED, DEVICE_NAME, &dev->core);
> + 0, DEVICE_NAME, &dev->core);
> if (retval) {
> dev_err(&dev->core, "%s: request_irq failed %d\n", __func__,
> retval);
> diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
> index d8de557..1ed8b36 100644
> --- a/drivers/video/pxa3xx-gcu.c
> +++ b/drivers/video/pxa3xx-gcu.c
> @@ -676,7 +676,7 @@ pxa3xx_gcu_probe(struct platform_device *dev)
> }
>
> ret = request_irq(irq, pxa3xx_gcu_handle_irq,
> - IRQF_DISABLED, DRV_NAME, priv);
> + 0, DRV_NAME, priv);
> if (ret) {
> dev_err(&dev->dev, "request_irq failed\n");
> ret = -EBUSY;
> diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
> index 0f4e8c9..e89778f 100644
> --- a/drivers/video/pxafb.c
> +++ b/drivers/video/pxafb.c
> @@ -2191,7 +2191,7 @@ static int __devinit pxafb_probe(struct platform_device *dev)
> goto failed_free_mem;
> }
>
> - ret = request_irq(irq, pxafb_handle_irq, IRQF_DISABLED, "LCD", fbi);
> + ret = request_irq(irq, pxafb_handle_irq, 0, "LCD", fbi);
> if (ret) {
> dev_err(&dev->dev, "request_irq failed: %d\n", ret);
> ret = -EBUSY;
> diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
> index 798144a..ee4c0df 100644
> --- a/drivers/video/s3c2410fb.c
> +++ b/drivers/video/s3c2410fb.c
> @@ -910,7 +910,7 @@ static int __devinit s3c24xxfb_probe(struct platform_device *pdev,
> for (i = 0; i < 256; i++)
> info->palette_buffer[i] = PALETTE_BUFF_CLEAR;
>
> - ret = request_irq(irq, s3c2410fb_irq, IRQF_DISABLED, pdev->name, info);
> + ret = request_irq(irq, s3c2410fb_irq, 0, pdev->name, info);
> if (ret) {
> dev_err(&pdev->dev, "cannot get irq %d - err %d\n", irq, ret);
> ret = -EBUSY;
> diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
> index e8b76d6..98d55d0 100644
> --- a/drivers/video/sa1100fb.c
> +++ b/drivers/video/sa1100fb.c
> @@ -1457,8 +1457,7 @@ static int __devinit sa1100fb_probe(struct platform_device *pdev)
> if (ret)
> goto failed;
>
> - ret = request_irq(irq, sa1100fb_handle_irq, IRQF_DISABLED,
> - "LCD", fbi);
> + ret = request_irq(irq, sa1100fb_handle_irq, 0, "LCD", fbi);
> if (ret) {
> printk(KERN_ERR "sa1100fb: request_irq failed: %d\n", ret);
> goto failed;
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 4636f9d..facffc2 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -1577,7 +1577,7 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, priv);
>
> - error = request_irq(i, sh_mobile_lcdc_irq, IRQF_DISABLED,
> + error = request_irq(i, sh_mobile_lcdc_irq, 0,
> dev_name(&pdev->dev), priv);
> if (error) {
> dev_err(&pdev->dev, "unable to request irq\n");
> diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
> index cd1c4dc..8e4a446 100644
> --- a/drivers/video/tmiofb.c
> +++ b/drivers/video/tmiofb.c
> @@ -744,7 +744,7 @@ static int __devinit tmiofb_probe(struct platform_device *dev)
> goto err_ioremap_vram;
> }
>
> - retval = request_irq(irq, &tmiofb_irq, IRQF_DISABLED,
> + retval = request_irq(irq, &tmiofb_irq, 0,
> dev_name(&dev->dev), info);
>
> if (retval)
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index c13c246..777c21d 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -355,7 +355,7 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
> goto failed_free_palette;
> }
>
> - ret = request_irq(irq, vt8500lcd_handle_irq, IRQF_DISABLED, "LCD", fbi);
> + ret = request_irq(irq, vt8500lcd_handle_irq, 0, "LCD", fbi);
> if (ret) {
> dev_err(&pdev->dev, "request_irq failed: %d\n", ret);
> ret = -EBUSY;
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Thadeu Lima de Souza Cascardo @ 2011-10-04 20:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: netdev@vger.kernel.org, Eli Cohen, eli@dev.mellanox.co.il,
linuxppc-dev, Yevgeny Petrilin
In-Reply-To: <1317708132.29415.213.camel@pasglop>
On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
>
> .../...
>
> > > Can you also send me the output of ethtool -i?
> > > It seems that there is a problem with write combining on Power processors, we will check this issue.
> > >
> > > Yevgeny
> >
> > Hello, Yevgeny.
> >
> > You will find the output of ethtool -i below.
> >
> > I am copying Ben and powerpc list, in case this is an issue with Power
> > processors. They can provide us some more insight into this.
>
> May I get some background please ? :-)
>
> I'm not aware of a specific issue with write combining but I'd need to
> know more about what you are doing and the code to do it to comment on
> whether it should work or not.
>
> Cheers,
> Ben.
>
>
Hello, Ben.
Sorry for that. I am testing mlx4_en driver on a POWER. Yevgeny has
added blue frame support, that does not require writing to the device
memory to indicate a new packet (the doorbell register as it is called).
Well, the ring is getting full with no interrupt or packets transmitted.
I simply added a write to the doorbell register and it works for me.
Yevgeny says this is not the right fix, claiming there is a problem with
write combining on POWER. The code uses memory barriers, so I don't know
why there is any problem.
I am posting the code here to show better what the situation is.
Yevgeny can tell more about the device and the driver.
The code below is the driver as of now, including a diff with what I
changed and had resulted OK for me. Before the blue frame support, the
only code executed was the else part. I can't tell much what the device
should be seeing and doing after the blue frame part of the code is
executed. But it does send the packet if I write to the doorbell
register.
Yevgeny, can you tell us what the device should be doing and why you
think this is a problem on POWER? Is it possible that this is simply a
problem with the firmware version?
Thanks,
Cascardo.
---
if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
!vlan_tag) {
*(u32 *) (&tx_desc->ctrl.vlan_tag) |=
ring->doorbell_qpn;
op_own |= htonl((bf_index & 0xffff) << 8);
/* Ensure new descirptor hits memory
* before setting ownership of this descriptor to HW */
wmb();
tx_desc->ctrl.owner_opcode = op_own;
wmb();
mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
long *) &tx_desc->ctrl,
desc_size);
wmb();
ring->bf.offset ^= ring->bf.buf_size;
} else {
/* Ensure new descirptor hits memory
* before setting ownership of this descriptor to HW */
wmb();
tx_desc->ctrl.owner_opcode = op_own;
- wmb();
- writel(ring->doorbell_qpn, ring->bf.uar->map +
MLX4_SEND_DOORBELL);
}
+ wmb();
+ writel(ring->doorbell_qpn, ring->bf.uar->map +
MLX4_SEND_DOORBELL);
+
---
^ permalink raw reply
* Re: Request_irq fails for IRQ2
From: Scott Wood @ 2011-10-04 15:30 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE014773@HYD-MKD-MBX4.wipro.com>
On 10/04/2011 06:21 AM, smitha.vanga@wipro.com wrote:
> Hi Scott,
>
> I am able to register the IRQ now once I add the call irq_set_default_host in cpm2_pic.
> But when I call enable_irq the code throws the below warning and gives exception in enable irq at
> spin_unlock_irqrestore(&desc->lock, flags); in enable_irq.
>
>
> printk(KERN_WARNING "Unbalanced enable for IRQ %d\n", irq);
The IRQ is automatically enabled when you request it. Only call
enable_irq() if you previously called disable_irq().
-Scott
^ permalink raw reply
* Re: [PATCH] memory hotplug: Correct page reservation checking
From: Nathan Fontenot @ 2011-10-04 14:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: Greg KH, linuxppc-dev, linux-kernel
In-Reply-To: <20111003175022.50cbef7f.akpm00@gmail.com>
On 10/03/2011 07:50 PM, Andrew Morton wrote:
> On Mon, 26 Sep 2011 10:22:33 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> The check to ensure that pages of recently added memory sections are correctly
>> marked as reserved before trying to online the memory is broken. The request
>> to online the memory fails with the following:
>>
>> kernel: section number XXX page number 256 not reserved, was it already online?
>>
>> This updates the page reservation checking to check the pages of each memory
>> section of the memory block being onlined individually.
>
> Why was this only noticed now? Is there something unusual about the
> way in which you're using it, or has nobody ever used this code, or...?
>
As far as I know it is only the powerpc/pseries code that uses the feature that
allows memory blocks in sysfs to span multiple memory sections. We do this
because on pseries memory add/remove is done on a per LMB basis and we can have
machine where an LMB spans multiple memory sections.
This was just noticed due to a lack of testing between the 2.6.38/39 kernels where
this feature originally went in and the current mainline kernel.
-Nathan
^ permalink raw reply
* RE: Request_irq fails for IRQ2
From: smitha.vanga @ 2011-10-04 13:55 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E89EFB2.6060704@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]
Hi Scoot,
When I try to use a atomic varaible in my ISR I see a kernel crash . with mesage BUG: scheduling while atomic:
Below is the code :
My ISR
irqreturn_t cpld_irq_handler(int irq, void * dev_id, struct pt_regs *regs)
{
wake_up(&cpld_intr_wait);
atomic_inc(&cpld_intr_data); /* incrementing this will indicate the poll() that the interrupt is occured */
return 0;
}
DRIVER_INIT
static int __init gpio_init(void)
{
int ret = 0;
int virq;
atomic_set(&cpld_intr_data, 0); /* initialize the Interrupt indicator */
init_waitqueue_head(&cpld_intr_wait); /* Initialize the wait queue */
virq = irq_create_mapping(NULL, CPLD1_INTERRUPT);
if ((ret = request_irq(virq,cpld_irq_handler, 0, GPIO_CHAR_PATH, NULL))!=0)
{
printk(KERN_ERR "gpio_init: Could not grab IRQ line for CPLD ret = %d\n",ret);
goto err1;
}
if((s_nGPIOMajor = register_chrdev(MPC8247_DEVICE_MAJOR_NUM, GPIO_CHAR_PATH, &gpio_fops))<0)
{
GPIO_DBG2("GPIO_DRIVER : unable to get major %d\n", s_nGPIOMajor);
return s_nGPIOMajor;
}else{
GPIO_DBG2("GPIO_DRIVER : major = %x\n", s_nGPIOMajor );
}
return 0;
}
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: Type: text/html, Size: 4372 bytes --]
^ permalink raw reply
* RE: Request_irq fails for IRQ2
From: smitha.vanga @ 2011-10-04 11:21 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E89EFB2.6060704@freescale.com>
Hi Scott,
I am able to register the IRQ now once I add the call irq_set_default_host i=
n cpm2_pic.
But when I call enable_irq the code throws the below warning and gives excep=
tion in enable irq at
spin_unlock_irqrestore(&desc->lock, flags); in enable_irq.
printk(KERN_WARNING "Unbalanced enable for IRQ %d\n", irq);
Regards,
Smitha
Please do not print this email unless it is absolutely necessary. =0A=
=0A=
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments. =0A=
=0A=
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email. =0A=
=0A=
www.wipro.com
^ permalink raw reply
* ping: [PATCH] GXT4000P and GXT6500P support
From: nello martuscielli @ 2011-10-04 11:56 UTC (permalink / raw)
To: linuxppc-dev, linux-fbdev-devel; +Cc: Nico Macrionitisl
ping for: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072678.html
This patch adds support for GXT4000P and GXT6500P cards found on some
IBM pSeries machines.
GXT4000P/6000P and GXT4500P/6500P couples are identical from
software's point of view and are based on the same Raster Engine
(RC1000), except for a different reference clock for the PLL.
GXT6x00P models are equipped with an additional Geometry Engine
(GT1000) but this driver doesn't use it.
I see that even after 2 years, this patch still hasn't been added to
the official Linux kernel.
You will appreciate how little code this took to save everybody with a
GXT6500P card some trouble.
cheers,
Nello
--
CRUX PPC user on IBM POWER4+
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox