* [PATCH v14 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: tmarri @ 2011-10-07 2:30 UTC (permalink / raw)
To: linux-usb, linuxppc-dev; +Cc: tmarri, greg
From: Tirumala Marri <tmarri@apm.com>
v14:
1. Modifying dwc_reg_read/write functions to accepts offset as arg.
2. Adding spin_lock to common interrupt function.
3. Adding start/stop, vbus_power functions to gadget_opst struct.
4. Removed some unnecessary comments and prints.
5. op_state_str() replace with common function.
6. Removed some unnecessary checks from apmppc.c file.
v13:
1. Remove redundant CONFIG VARIABLE from drivers/usb/dwc/Kconfig.
Tirumala Marri (10):
USB/ppc4xx: Add Synopsys DesignWare HS USB OTG Register definitions
USB/ppc4xx: Add Synopsys DesignWare HS USB OTG driver framework
USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer (CIL)
USB/ppc4xx: Add Synopsys DWC OTG HCD function
USB/ppc4xx: Add Synopsys DWC OTG HCD interrupt function
USB/ppc4xx: Add Synopsys DWC OTG HCD queue function
USB/ppc4xx: Add Synopsys DWC OTG PCD function
USB ppc4xx: Add Synopsys DWC OTG PCD interrupt function
Add Synopsys DWC OTG driver kernel configuration and Makefile
USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
drivers/usb/Kconfig | 2 +
drivers/usb/Makefile | 1 +
drivers/usb/dwc/Kconfig | 84 ++
drivers/usb/dwc/Makefile | 19 +
drivers/usb/dwc/apmppc.c | 353 ++++++
drivers/usb/dwc/cil.c | 889 +++++++++++++
drivers/usb/dwc/cil.h | 1174 ++++++++++++++++++
drivers/usb/dwc/cil_intr.c | 616 +++++++++
drivers/usb/dwc/driver.h | 76 ++
drivers/usb/dwc/hcd.c | 2465 +++++++++++++++++++++++++++++++++++++
drivers/usb/dwc/hcd.h | 416 +++++++
drivers/usb/dwc/hcd_intr.c | 1477 ++++++++++++++++++++++
drivers/usb/dwc/hcd_queue.c | 696 +++++++++++
drivers/usb/dwc/param.c | 180 +++
drivers/usb/dwc/pcd.c | 1791 +++++++++++++++++++++++++++
drivers/usb/dwc/pcd.h | 139 +++
drivers/usb/dwc/pcd_intr.c | 2311 ++++++++++++++++++++++++++++++++++
drivers/usb/dwc/regs.h | 1326 ++++++++++++++++++++
drivers/usb/gadget/Kconfig | 11 +
drivers/usb/gadget/gadget_chips.h | 3 +
20 files changed, 14029 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc/Kconfig
create mode 100644 drivers/usb/dwc/Makefile
create mode 100644 drivers/usb/dwc/apmppc.c
create mode 100644 drivers/usb/dwc/cil.c
create mode 100644 drivers/usb/dwc/cil.h
create mode 100644 drivers/usb/dwc/cil_intr.c
create mode 100644 drivers/usb/dwc/driver.h
create mode 100644 drivers/usb/dwc/hcd.c
create mode 100644 drivers/usb/dwc/hcd.h
create mode 100644 drivers/usb/dwc/hcd_intr.c
create mode 100644 drivers/usb/dwc/hcd_queue.c
create mode 100644 drivers/usb/dwc/param.c
create mode 100644 drivers/usb/dwc/pcd.c
create mode 100644 drivers/usb/dwc/pcd.h
create mode 100644 drivers/usb/dwc/pcd_intr.c
create mode 100644 drivers/usb/dwc/regs.h
^ permalink raw reply
* RE: [PATCH] mlx4_en: fix transmit of packages when blue frame isenabled
From: David Laight @ 2011-10-06 14:10 UTC (permalink / raw)
To: Eli Cohen, Thadeu Lima de Souza Cascardo
Cc: Eli Cohen, Yevgeny Petrilin, linuxppc-dev, netdev
In-Reply-To: <20111006135759.GH2681@mtldesk30>
=20
> static void mlx4_bf_copy(unsigned long *dst, unsigned long *src,
unsigned bytecnt) {
> + int i;
> + __le32 *psrc =3D (__le32 *)src;
> +
> + /*
> + * the buffer is already in big endian. For little endian
machines that's
> + * fine. For big endain machines we must swap since the chipset
swaps again
> + */
> + for (i =3D 0; i < bytecnt / 4; ++i)
> + psrc[i] =3D le32_to_cpu(psrc[i]);
> +
> __iowrite64_copy(dst, src, bytecnt / 8);
> }
That code looks horrid...
1) I'm not sure the caller expects the buffer to be corrupted.
2) It contains a lot of memory cycles.
3) It looked from the calls that this code is copying descriptors,
so the transfer length is probably 1 or 2 words - so the loop
is inefficient.
4) ppc doesn't have a fast byteswap instruction (very new gcc might
use the byteswapping memery access for the le32_to_cpu() though),
so it would be better getting the byteswap done inside
__iowrite64_copy() - since that is probably requesting a byteswap
anyway.
OTOH I'm not at all clear about the 64bit xfers....
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Eli Cohen @ 2011-10-06 13:57 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Eli Cohen, netdev@vger.kernel.org, linuxppc-dev, Yevgeny Petrilin
In-Reply-To: <20111005081502.GB2681@mtldesk30>
On Wed, Oct 05, 2011 at 10:15:02AM +0200, Eli Cohen wrote:
How about this patch - can you give it a try?
>From dee60547aa9e35a02835451d9e694cd80dd3072f Mon Sep 17 00:00:00 2001
From: Eli Cohen <eli@mellanox.co.il>
Date: Thu, 6 Oct 2011 15:50:02 +0200
Subject: [PATCH] mlx4_en: Fix blue flame on powerpc
The source buffer used for copying into the blue flame register is already in
big endian. However, when copying to device on powerpc, the endianess is
swapped so the data reaches th device in little endian which is wrong. On x86
based platform no swapping occurs so it reaches the device with the correct
endianess. Fix this by calling le32_to_cpu() on the buffer. On LE systems there
is no change; on BE there will be a swap.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
---
drivers/net/mlx4/en_tx.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/mlx4/en_tx.c b/drivers/net/mlx4/en_tx.c
index 16337fb..3743acc 100644
--- a/drivers/net/mlx4/en_tx.c
+++ b/drivers/net/mlx4/en_tx.c
@@ -601,6 +601,16 @@ u16 mlx4_en_select_queue(struct net_device *dev, struct sk_buff *skb)
static void mlx4_bf_copy(unsigned long *dst, unsigned long *src, unsigned bytecnt)
{
+ int i;
+ __le32 *psrc = (__le32 *)src;
+
+ /*
+ * the buffer is already in big endian. For little endian machines that's
+ * fine. For big endain machines we must swap since the chipset swaps again
+ */
+ for (i = 0; i < bytecnt / 4; ++i)
+ psrc[i] = le32_to_cpu(psrc[i]);
+
__iowrite64_copy(dst, src, bytecnt / 8);
}
--
1.7.7.rc0.70.g82660
> 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 related
* [PATCH 4/4] powerpc/booke: Re-organize debug code
From: Kumar Gala @ 2011-10-06 12:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1317905621-5537-3-git-send-email-galak@kernel.crashing.org>
* set_dabr/do_dabr are no longer used when CNFIG_PPC_ADV_DEBUG_REGS is set
refactor code a bit such that we only build the dabr code for
!CONFIG_PPC_ADV_DEBUG_REGS and removed some CONFIG_PPC_ADV_DEBUG_REGS
code in set_dabr that would never get built.
* Move do_send_trap into traps.c as its only used there
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/system.h | 5 +--
arch/powerpc/kernel/process.c | 97 +++++++++++++-----------------------
arch/powerpc/kernel/traps.c | 17 +++++++
3 files changed, 53 insertions(+), 66 deletions(-)
diff --git a/arch/powerpc/include/asm/system.h b/arch/powerpc/include/asm/system.h
index e30a13d..1dc5d9c 100644
--- a/arch/powerpc/include/asm/system.h
+++ b/arch/powerpc/include/asm/system.h
@@ -111,11 +111,8 @@ static inline int debugger_dabr_match(struct pt_regs *regs) { return 0; }
static inline int debugger_fault_handler(struct pt_regs *regs) { return 0; }
#endif
+#ifndef CONFIG_PPC_ADV_DEBUG_REGS
extern int set_dabr(unsigned long dabr);
-#ifdef CONFIG_PPC_ADV_DEBUG_REGS
-extern void do_send_trap(struct pt_regs *regs, unsigned long address,
- unsigned long error_code, int signal_code, int brkpt);
-#else
extern void do_dabr(struct pt_regs *regs, unsigned long address,
unsigned long error_code);
#endif
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 269a309..989e574 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -251,50 +251,6 @@ void discard_lazy_cpu_state(void)
#endif /* CONFIG_SMP */
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
-void do_send_trap(struct pt_regs *regs, unsigned long address,
- unsigned long error_code, int signal_code, int breakpt)
-{
- siginfo_t info;
-
- if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
- 11, SIGSEGV) == NOTIFY_STOP)
- return;
-
- /* Deliver the signal to userspace */
- info.si_signo = SIGTRAP;
- info.si_errno = breakpt; /* breakpoint or watchpoint id */
- info.si_code = signal_code;
- info.si_addr = (void __user *)address;
- force_sig_info(SIGTRAP, &info, current);
-}
-#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
-void do_dabr(struct pt_regs *regs, unsigned long address,
- unsigned long error_code)
-{
- siginfo_t info;
-
- if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
- 11, SIGSEGV) == NOTIFY_STOP)
- return;
-
- if (debugger_dabr_match(regs))
- return;
-
- /* Clear the DABR */
- set_dabr(0);
-
- /* Deliver the signal to userspace */
- info.si_signo = SIGTRAP;
- info.si_errno = 0;
- info.si_code = TRAP_HWBKPT;
- info.si_addr = (void __user *)address;
- force_sig_info(SIGTRAP, &info, current);
-}
-#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
-
-static DEFINE_PER_CPU(unsigned long, current_dabr);
-
-#ifdef CONFIG_PPC_ADV_DEBUG_REGS
/*
* Set the debug registers back to their default "safe" values.
*/
@@ -357,16 +313,7 @@ static void switch_booke_debug_regs(struct thread_struct *new_thread)
prime_debug_regs(new_thread);
}
#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
-#ifndef CONFIG_HAVE_HW_BREAKPOINT
-static void set_debug_reg_defaults(struct thread_struct *thread)
-{
- if (thread->dabr) {
- thread->dabr = 0;
- set_dabr(0);
- }
-}
-#endif /* !CONFIG_HAVE_HW_BREAKPOINT */
-#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
+static DEFINE_PER_CPU(unsigned long, current_dabr);
int set_dabr(unsigned long dabr)
{
@@ -376,19 +323,45 @@ int set_dabr(unsigned long dabr)
return ppc_md.set_dabr(dabr);
/* XXX should we have a CPU_FTR_HAS_DABR ? */
-#ifdef CONFIG_PPC_ADV_DEBUG_REGS
- mtspr(SPRN_DAC1, dabr);
-#ifdef CONFIG_PPC_47x
- isync();
-#endif
-#elif defined(CONFIG_PPC_BOOK3S)
mtspr(SPRN_DABR, dabr);
-#endif
-
return 0;
}
+void do_dabr(struct pt_regs *regs, unsigned long address,
+ unsigned long error_code)
+{
+ siginfo_t info;
+
+ if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
+ 11, SIGSEGV) == NOTIFY_STOP)
+ return;
+
+ if (debugger_dabr_match(regs))
+ return;
+
+ /* Clear the DABR */
+ set_dabr(0);
+
+ /* Deliver the signal to userspace */
+ info.si_signo = SIGTRAP;
+ info.si_errno = 0;
+ info.si_code = TRAP_HWBKPT;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGTRAP, &info, current);
+}
+
+#ifndef CONFIG_HAVE_HW_BREAKPOINT
+static void set_debug_reg_defaults(struct thread_struct *thread)
+{
+ if (thread->dabr) {
+ thread->dabr = 0;
+ set_dabr(0);
+ }
+}
+#endif /* !CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
+
#ifdef CONFIG_PPC64
DEFINE_PER_CPU(struct cpu_usage, cpu_usage_array);
#endif
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index db733d3..edc1108 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1184,6 +1184,23 @@ void SoftwareEmulation(struct pt_regs *regs)
#endif /* CONFIG_8xx */
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
+static void do_send_trap(struct pt_regs *regs, unsigned long address,
+ unsigned long error_code, int signal_code, int breakpt)
+{
+ siginfo_t info;
+
+ if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
+ 11, SIGSEGV) == NOTIFY_STOP)
+ return;
+
+ /* Deliver the signal to userspace */
+ info.si_signo = SIGTRAP;
+ info.si_errno = breakpt; /* breakpoint or watchpoint id */
+ info.si_code = signal_code;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGTRAP, &info, current);
+}
+
static void handle_debug(struct pt_regs *regs, unsigned long debug_status)
{
int changed = 0;
--
1.7.3.4
^ permalink raw reply related
* [PATCH 3/4] powerpc/book3e-64: Fix debug support for userspace
From: Kumar Gala @ 2011-10-06 12:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1317905621-5537-2-git-send-email-galak@kernel.crashing.org>
With the introduction of CONFIG_PPC_ADV_DEBUG_REGS user space debug is
broken on Book-E 64-bit parts that support delayed debug events. When
switch_booke_debug_regs() sets DBCR0 we'll start getting debug events as
MSR_DE is also set and we aren't able to handle debug events from kernel
space.
We can remove the hack that always enables MSR_DE and loads up DBCR0 and
just utilize switch_booke_debug_regs() to get user space debug working
again.
We still need to handle critical/debug exception stacks & proper
save/restore of state for those exception levles to support debug events
from kernel space like we have on 32-bit.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/reg_booke.h | 2 +-
arch/powerpc/kernel/process.c | 22 ----------------------
2 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 9ec0b39..4dfa21c 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -31,7 +31,7 @@
#define MSR_ MSR_ME | MSR_CE
#define MSR_KERNEL MSR_ | MSR_64BIT
-#define MSR_USER32 MSR_ | MSR_PR | MSR_EE | MSR_DE
+#define MSR_USER32 MSR_ | MSR_PR | MSR_EE
#define MSR_USER64 MSR_USER32 | MSR_64BIT
#elif defined (CONFIG_40x)
#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index a1b5981..269a309 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -486,28 +486,6 @@ struct task_struct *__switch_to(struct task_struct *prev,
new_thread = &new->thread;
old_thread = ¤t->thread;
-#if defined(CONFIG_PPC_BOOK3E_64)
- /* XXX Current Book3E code doesn't deal with kernel side DBCR0,
- * we always hold the user values, so we set it now.
- *
- * However, we ensure the kernel MSR:DE is appropriately cleared too
- * to avoid spurrious single step exceptions in the kernel.
- *
- * This will have to change to merge with the ppc32 code at some point,
- * but I don't like much what ppc32 is doing today so there's some
- * thinking needed there
- */
- if ((new_thread->dbcr0 | old_thread->dbcr0) & DBCR0_IDM) {
- u32 dbcr0;
-
- mtmsr(mfmsr() & ~MSR_DE);
- isync();
- dbcr0 = mfspr(SPRN_DBCR0);
- dbcr0 = (dbcr0 & DBCR0_EDM) | new_thread->dbcr0;
- mtspr(SPRN_DBCR0, dbcr0);
- }
-#endif /* CONFIG_PPC64_BOOK3E */
-
#ifdef CONFIG_PPC64
/*
* Collect processor utilization data per process
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/4] powerpc: Remove extraneous CONFIG_PPC_ADV_DEBUG_REGS define
From: Kumar Gala @ 2011-10-06 12:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1317905621-5537-1-git-send-email-galak@kernel.crashing.org>
All of DebugException is already protected by CONFIG_PPC_ADV_DEBUG_REGS
there is no need to have another such ifdef inside the function.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/traps.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index f19d977..db733d3 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1291,14 +1291,12 @@ void __kprobes DebugException(struct pt_regs *regs, unsigned long debug_status)
if (user_mode(regs)) {
current->thread.dbcr0 &= ~DBCR0_IC;
-#ifdef CONFIG_PPC_ADV_DEBUG_REGS
if (DBCR_ACTIVE_EVENTS(current->thread.dbcr0,
current->thread.dbcr1))
regs->msr |= MSR_DE;
else
/* Make sure the IDM bit is off */
current->thread.dbcr0 &= ~DBCR0_IDM;
-#endif
}
_exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/4] powerpc: Revert show_regs() define for readability
From: Kumar Gala @ 2011-10-06 12:53 UTC (permalink / raw)
To: linuxppc-dev
We had an existing ifdef for 4xx & BOOKE processors that got changed to
CONFIG_PPC_ADV_DEBUG_REGS. The define has nothing to do with
CONFIG_PPC_ADV_DEBUG_REGS. The define really should be:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
and not
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/process.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 8f53954..a1b5981 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -657,7 +657,7 @@ void show_regs(struct pt_regs * regs)
if ((regs->trap != 0xc00) && cpu_has_feature(CPU_FTR_CFAR))
printk("CFAR: "REG"\n", regs->orig_gpr3);
if (trap == 0x300 || trap == 0x600)
-#ifdef CONFIG_PPC_ADV_DEBUG_REGS
+#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
printk("DEAR: "REG", ESR: "REG"\n", regs->dar, regs->dsisr);
#else
printk("DAR: "REG", DSISR: %08lx\n", regs->dar, regs->dsisr);
--
1.7.3.4
^ permalink raw reply related
* Re: [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD
From: Gabriel Paubert @ 2011-10-06 11:06 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev
In-Reply-To: <alpine.LFD.2.02.1110051722140.18778@ionos>
On Wed, Oct 05, 2011 at 05:31:48PM +0200, Thomas Gleixner wrote:
> 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/
Thanks.
>
> > (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.
Well, for now I have my own registration, because when I originally wrote
the code (over a decade ago), there was no simple way to add potentially
~1800 additional interrupt sources (and the size of the interrupt descriptor
array on a machine with 16MB of RAM was not negligible, it became several
percent of the, minimalistic, kernel).
This might be feasible now, but I still have boards with the first release
of the bridge, which has very nasty interrupt related bugs (sometimes it
incorrectly reports the level, only the vector is correct).
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] libata: Convert LED disk trigger from IDE to libata
From: Sergei Shtylyov @ 2011-10-06 10:53 UTC (permalink / raw)
To: Jörg Sommer
Cc: linux-kernel, linux-ide, Richard Purdie, Jeff Garzik,
Paul Mackerras, linuxppc-dev, David S. Miller
In-Reply-To: <38bd3a0590c6b069e2e6ff63d2bc4d039a703f02.1317657893.git.joerg@alea.gnuu.de>
Hello.
On 03-10-2011 20:07, Jörg Sommer wrote:
> This patch converts the trigger for the LED at the front of Apple's
> iBooks to libata. It's merely a replacement of the string ide by disk.
> The patch is taken from http://dev.gentoo.org/~josejx/ata.patch. I've
> asked Joseph Jezak if he intends to send this patch upstream, but as he
> did not reply I'll do so.
The patch needs to be signed off, it cannot be applied otherwise.
> ---
> arch/powerpc/configs/pmac32_defconfig | 2 +-
> arch/powerpc/configs/ppc6xx_defconfig | 2 +-
> drivers/ata/libata-core.c | 4 ++
> drivers/ide/ide-disk.c | 2 +-
> drivers/leds/Kconfig | 10 +++---
> drivers/leds/Makefile | 2 +-
> drivers/leds/ledtrig-disk.c | 64 +++++++++++++++++++++++++++++++++
> drivers/leds/ledtrig-ide-disk.c | 64 ---------------------------------
> drivers/macintosh/Kconfig | 11 +++---
> drivers/macintosh/via-pmu-led.c | 4 +-
> include/linux/leds.h | 6 ++--
> 11 files changed, 87 insertions(+), 84 deletions(-)
> create mode 100644 drivers/leds/ledtrig-disk.c
> delete mode 100644 drivers/leds/ledtrig-ide-disk.c
You should use -C/-M git options to detect file renames.
> diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
> index f8b394a..cff5d4e 100644
> --- a/arch/powerpc/configs/pmac32_defconfig
> +++ b/arch/powerpc/configs/pmac32_defconfig
> @@ -180,7 +180,7 @@ CONFIG_ADB=y
> CONFIG_ADB_CUDA=y
> CONFIG_ADB_PMU=y
> CONFIG_ADB_PMU_LED=y
> -CONFIG_ADB_PMU_LED_IDE=y
> +CONFIG_ADB_PMU_LED_DISK=y
> CONFIG_PMAC_APM_EMU=m
> CONFIG_PMAC_MEDIABAY=y
> CONFIG_PMAC_BACKLIGHT=y
> diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
> index 04360f9..c56464d 100644
> --- a/arch/powerpc/configs/ppc6xx_defconfig
> +++ b/arch/powerpc/configs/ppc6xx_defconfig
> @@ -471,7 +471,7 @@ CONFIG_ADB=y
> CONFIG_ADB_CUDA=y
> CONFIG_ADB_PMU=y
> CONFIG_ADB_PMU_LED=y
> -CONFIG_ADB_PMU_LED_IDE=y
> +CONFIG_ADB_PMU_LED_DISK=y
> CONFIG_PMAC_APM_EMU=y
> CONFIG_PMAC_MEDIABAY=y
> CONFIG_PMAC_BACKLIGHT=y
Defconfigs should be changed by a separate patch.
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 4a3a5ae..d37e3a2 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -66,6 +66,7 @@
> #include<asm/byteorder.h>
> #include<linux/cdrom.h>
> #include<linux/ratelimit.h>
> +#include<linux/leds.h>
>
> #include "libata.h"
> #include "libata-transport.h"
> @@ -4823,6 +4824,9 @@ void ata_qc_complete(struct ata_queued_cmd *qc)
> {
> struct ata_port *ap = qc->ap;
>
> + /* Trigger the LED (if available) */
> + ledtrig_disk_activity();
> +
> /* XXX: New EH and old EH use different mechanisms to
> * synchronize EH with regular execution path.
> *
This also seems a material for the separate patch. You should first do a
file/function rename and then add support for libata, I think.
> diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
> index 2747980..cb25bd6 100644
> --- a/drivers/ide/ide-disk.c
> +++ b/drivers/ide/ide-disk.c
> @@ -186,7 +186,7 @@ static ide_startstop_t ide_do_rw_disk(ide_drive_t *drive, struct request *rq,
> BUG_ON(drive->dev_flags& IDE_DFLAG_BLOCKED);
> BUG_ON(rq->cmd_type != REQ_TYPE_FS);
>
> - ledtrig_ide_activity();
> + ledtrig_disk_activity();
Hm, the trigger point seems asymmetric to that one you added to libata.
Here you trigger before executing a request, and in libata after a command
completes; also, in libata you also trigger on ATAPI devices, while here only
on ATA devices...
WBR, Sergei
^ permalink raw reply
* Re: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers
From: Williams, Dan J @ 2011-10-05 20:38 UTC (permalink / raw)
To: Bounine, Alexandre
Cc: Dave Jiang, Vinod Koul, linux-kernel, akpm, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55202291E40@CORPEXCH1.na.ads.idt.com>
On Mon, Oct 3, 2011 at 9:52 AM, Bounine, Alexandre
<Alexandre.Bounine@idt.com> wrote:
> Vinod Koul wrote:
>>
>> On Fri, 2011-09-30 at 17:38 -0400, Alexandre Bounine wrote:
>> Please CC *maintainers* on your patches, get_maintainers.pl will tell
>> you who. Adding Dan here
>
> Based on https://lkml.org/lkml/2011/2/14/67 and use of DMA_SLAVE in this
> patch I decided that you are the best match among two and there is no rea=
son
> to disturb Dan ;)
>
>> > Adds DMA Engine framework support into RapidIO subsystem.
>> > Uses DMA Engine DMA_SLAVE interface to generate data transfers to/from=
remote
>> > RapidIO target devices. Uses scatterlist to describe local data buffer=
and
>> > dma_chan.private member to pass target specific information. Supports =
flat
>> > data buffer only for a remote side.
>> The way dmaengine works today is that it doesn't know anything about
>> client subsystem. But this brings in a subsystem details to dmaengine
>> which I don't agree with yet.
>> Why can't we abstract this out??
>
> The only thing that brings subsystem knowledge into dmaengine is DMA_RAPI=
DIO flag.
> I am actually on the fence about this. From RapidIO side point of view I =
do not
> need that flag at all.
> RapidIO uses a filter routine that is sufficient to identify dmaengine ch=
annels
> associated with specific RapidIO mport. Use of DMA_SLAVE flag is safe her=
e.
> Use of private member of dma_chan is "private" business of RapidIO and do=
es
> not break anything.
>
> My concern here is that other subsystems may use/request DMA_SLAVE channe=
l(s) as well
> and wrongfully acquire one that belongs to RapidIO. In this case separati=
on with another
> flag may have a sense - it is possible to have a system that uses RapidIO
> and other "traditional" DMA slave channel.
>
> This is why I put that proposed interface for discussion instead of keepi=
ng everything
> inside of RapidIO.
> If you think that situation above will not happen I will be happy to remo=
ve
> that subsystem knowledge from dmaengine files.
I don't think that situation will happen, even on the same arch I
don't think DMA_SLAVE is ready to be enabled generically. So you're
probably safe here.
> My most recent test implementation runs without DMA_RAPIDIO flag though.
>
>>
>> After going thru the patch, I do not believe that this this is case of
>> SLAVE transfers, Dan can you please take a look at this patch
>
> I agree, this is not a case of "pure" slave transfers but existing DMA_SL=
AVE
> interface fits well into the RapidIO operations.
>
> First, we have only one memory mapped location on the host side. We trans=
fer
> data to/from location that is not mapped into memory on the same side.
>
> Second, having ability to pass private target information allows me to pa=
ss
> information about remote target device on per-transfer basis.
...but there is no expectation that these engines will be generically
useful to other subsytems. To be clear you are just using dmaengine
as a match making service for your dma providers to clients, right?
>
>>
>>
>> > Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
>> > Cc: Vinod Koul <vinod.koul@intel.com>
>> > Cc: Kumar Gala <galak@kernel.crashing.org>
>> > Cc: Matt Porter <mporter@kernel.crashing.org>
>> > Cc: Li Yang <leoli@freescale.com>
>> > ---
>> > =A0drivers/dma/dmaengine.c =A0 | =A0 =A04 ++
> ... skip ...
>> > +#ifdef CONFIG_RAPIDIO_DMA_ENGINE
>> > +
>> > +#include <linux/dmaengine.h>
>> > +
> ... skip ...
>> > + */
>> > +struct dma_async_tx_descriptor *rio_dma_prep_slave_sg(struct rio_dev =
*rdev,
>> > + =A0 struct dma_chan *dchan, struct rio_dma_data *data,
>> > + =A0 enum dma_data_direction direction, unsigned long flags)
>> > +{
>> > + =A0 struct dma_async_tx_descriptor *txd =3D NULL;
>> > + =A0 struct rio_dma_ext rio_ext;
>> > +
>> > + =A0 rio_ext.destid =3D rdev->destid;
>> > + =A0 rio_ext.rio_addr_u =3D data->rio_addr_u;
>> > + =A0 rio_ext.rio_addr =3D data->rio_addr;
>> > + =A0 rio_ext.wr_type =3D data->wr_type;
>> > + =A0 dchan->private =3D &rio_ext;
>> > +
>> > + =A0 txd =3D dchan->device->device_prep_slave_sg(dchan, data->sg, dat=
a-
>> >sg_len,
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 direction, flags);
>> > +
>> > + =A0 return txd;
>> > +}
>> > +EXPORT_SYMBOL_GPL(rio_dma_prep_slave_sg);
>> You should move the rdev and data to dma_slave_config, that way you
>> should be able to use the existing _prep_slave_sg function.
>
> RapidIO network usually has more than one device attached to it and
> single DMA channel may service data transfers to/from several devices.
> In this case device information should be passed on per-transfer basis.
>
You could maybe do what async_tx does and just apply the extra context
after the ->prep(), but before ->submit(), but it looks like that
context is critical to setting up the operation.
This looks pretty dangerous without knowing the other details. What
prevents another thread from changing dchan->private before the the
prep routine reads it?
DMA_SLAVE assumes a static relationship between dma device and
slave-device, instead this rapid-io case is a per-operation slave
context. It sounds like you really do want a new dma operation type
that is just an extra-parameter version of the current
->device_prep_slave_sg. But now we're getting into to
dma_transaction_type proliferation again. This is probably more fuel
for the fire of creating a structure transfer template that defines
multiple possible operation types and clients just fill in the fields
that they need, rather than adding new operation types for every
possible permutation of copy operation (DMA_SLAVE, DMA_MEMCPY,
DMA_CYCLIC, DMA_SG, DMA_INTERLEAVE, DMA_RAPIDIO), it's getting to be a
bit much.
As a starting point, since this the first driver proposal to have
per-operation slave context and there are other rapid-io specific
considerations, maybe it's ok to have a rio_dma_prep_slave_sg() that
does something like:
struct tsi721_bdma_chan *bdma_chan =3D to_tsi721_chan(dchan);
bdma_chan->prep_sg(rext, sgl, sg_len, direction, flags);
Thoughts?
^ permalink raw reply
* Re: Enabling MBX in MPC5121
From: Tabi Timur-B04825 @ 2011-10-05 20:39 UTC (permalink / raw)
To: Einar Már Björgvinsson; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <76E1146DEE728E4E95C1C6D1EEA1DBA96F159623@GRBSR0004.marel.net>
2011/9/30 Einar M=E1r Bj=F6rgvinsson <Einar.Bjorgvinsson@marel.com>:
> Hi all
>
> I am interested in enabling the GPU on the MPC5121 for 2d/3d acceleration=
.
> I've read some misleading informations about the status of support in Lin=
ux
> for this.
> What is the status today ? is it easily possible ? if so, how ?
There may be some support for the GPU in the BSP for the MPC5121, but
I don't think there's anything in the mainline kernel.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [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
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