* [PATCH] powerpc/pseries: Rename RAS_VECTOR_OFFSET to RTAS_VECTOR_EXTERNAL_INTERRUPT and move to rtas.h
From: Mark Nelson @ 2010-05-27 7:40 UTC (permalink / raw)
To: linuxppc-dev
The RAS code has a #define, RAS_VECTOR_OFFSET, that's used in the
check-exception RTAS call for the vector offset of the exception.
We'll be using this same vector offset for the upcoming IO Event interrupts
code (0x500) so let's move it to include/asm/rtas.h and call it
RTAS_VECTOR_EXTERNAL_INTERRUPT.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/powerpc/include/asm/rtas.h | 3 +++
arch/powerpc/platforms/pseries/ras.c | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
Index: upstream/arch/powerpc/include/asm/rtas.h
===================================================================
--- upstream.orig/arch/powerpc/include/asm/rtas.h
+++ upstream/arch/powerpc/include/asm/rtas.h
@@ -137,6 +137,9 @@ struct rtas_t {
#define RTAS_TYPE_PMGM_CONFIG_CHANGE 0x70
#define RTAS_TYPE_PMGM_SERVICE_PROC 0x71
+/* RTAS check-exception vector offset */
+#define RTAS_VECTOR_EXTERNAL_INTERRUPT 0x500
+
struct rtas_error_log {
unsigned long version:8; /* Architectural version */
unsigned long severity:3; /* Severity level of error */
Index: upstream/arch/powerpc/platforms/pseries/ras.c
===================================================================
--- upstream.orig/arch/powerpc/platforms/pseries/ras.c
+++ upstream/arch/powerpc/platforms/pseries/ras.c
@@ -61,7 +61,6 @@ static int ras_check_exception_token;
#define EPOW_SENSOR_TOKEN 9
#define EPOW_SENSOR_INDEX 0
-#define RAS_VECTOR_OFFSET 0x500
static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
@@ -121,7 +120,7 @@ static irqreturn_t ras_epow_interrupt(in
spin_lock(&ras_log_buf_lock);
status = rtas_call(ras_check_exception_token, 6, 1, NULL,
- RAS_VECTOR_OFFSET,
+ RTAS_VECTOR_EXTERNAL_INTERRUPT,
irq_map[irq].hwirq,
RTAS_EPOW_WARNING | RTAS_POWERMGM_EVENTS,
critical, __pa(&ras_log_buf),
@@ -156,7 +155,7 @@ static irqreturn_t ras_error_interrupt(i
spin_lock(&ras_log_buf_lock);
status = rtas_call(ras_check_exception_token, 6, 1, NULL,
- RAS_VECTOR_OFFSET,
+ RTAS_VECTOR_EXTERNAL_INTERRUPT,
irq_map[irq].hwirq,
RTAS_INTERNAL_ERROR, 1 /*Time Critical */,
__pa(&ras_log_buf),
^ permalink raw reply
* powerpc/pseries: Add WARN_ON() to request_event_sources_irqs() on irq allocation/request failure
From: Mark Nelson @ 2010-05-27 6:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Tseng-hui Lin
In-Reply-To: <201005191654.42483.markn@au1.ibm.com>
At the moment if request_event_sources_irqs() can't allocate or request
the interrupt, it just does a KERN_ERR printk. This may be fine for the
existing RAS code where if we miss an EPOW event it just means that the
event won't be logged and if we miss one of the RAS errors then we could
miss an event that we perhaps should take action on.
But, for the upcoming IO events code that will use event-sources if we
can't allocate or request the interrupt it means we'd potentially miss
an interrupt from the device. So, let's add a WARN_ON() in this error
case so that we're a bit more vocal when something's amiss.
While we're at it, also use pr_err() to neaten the code up a bit.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/powerpc/platforms/pseries/event_sources.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
Index: upstream/arch/powerpc/platforms/pseries/event_sources.c
===================================================================
--- upstream.orig/arch/powerpc/platforms/pseries/event_sources.c
+++ upstream/arch/powerpc/platforms/pseries/event_sources.c
@@ -41,9 +41,12 @@ void request_event_sources_irqs(struct d
if (count > 15)
break;
virqs[count] = irq_create_mapping(NULL, *(opicprop++));
- if (virqs[count] == NO_IRQ)
- printk(KERN_ERR "Unable to allocate interrupt "
- "number for %s\n", np->full_name);
+ if (virqs[count] == NO_IRQ) {
+ pr_err("event-sources: Unable to allocate "
+ "interrupt number for %s\n",
+ np->full_name);
+ WARN_ON(1);
+ }
else
count++;
@@ -59,9 +62,12 @@ void request_event_sources_irqs(struct d
virqs[count] = irq_create_of_mapping(oirq.controller,
oirq.specifier,
oirq.size);
- if (virqs[count] == NO_IRQ)
- printk(KERN_ERR "Unable to allocate interrupt "
- "number for %s\n", np->full_name);
+ if (virqs[count] == NO_IRQ) {
+ pr_err("event-sources: Unable to allocate "
+ "interrupt number for %s\n",
+ np->full_name);
+ WARN_ON(1);
+ }
else
count++;
}
@@ -70,8 +76,9 @@ void request_event_sources_irqs(struct d
/* Now request them */
for (i = 0; i < count; i++) {
if (request_irq(virqs[i], handler, 0, name, NULL)) {
- printk(KERN_ERR "Unable to request interrupt %d for "
- "%s\n", virqs[i], np->full_name);
+ pr_err("event-sources: Unable to request interrupt "
+ "%d for %s\n", virqs[i], np->full_name);
+ WARN_ON(1);
return;
}
}
^ permalink raw reply
* Re: [Patch 4/4] PPC64-HWBKPT: Enable hw-breakpoints while handling intervening signals
From: Paul Mackerras @ 2010-05-27 6:32 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, linuxppc-dev@ozlabs.org,
Alan Stern, Roland McGrath
In-Reply-To: <20100525091505.GE29003@in.ibm.com>
On Tue, May 25, 2010 at 02:45:05PM +0530, K.Prasad wrote:
> A signal delivered between a hw_breakpoint_handler() and the
> single_step_dabr_instruction() will not have the breakpoint active during
> signal handling (since breakpoint will not be restored through single-stepping
> due to absence of MSR_SE bit on the signal frame). Enable breakpoints before
> signal delivery.
>
> Restore hw-breakpoints if the user-context is altered in the signal handler.
...
> /*
> + * Restores the breakpoint on the debug registers.
> + * Invoke this function if it is known that the execution context is about to
> + * change to cause loss of MSR_SE settings.
> + */
> +void thread_change_pc(struct task_struct *tsk)
> +{
> + struct arch_hw_breakpoint *info;
> +
> + if (likely(!tsk->thread.last_hit_ubp))
> + return;
> +
> + info = counter_arch_bp(tsk->thread.last_hit_ubp);
> + set_dabr(info->address | info->type | DABR_TRANSLATION);
> +}
I think this function needs to clear current->thread.last_hit_ubp.
You also need to pass the regs to it so it can clear MSR_SE from
regs->msr.
> Index: linux-2.6.ppc64_test/arch/powerpc/kernel/signal_64.c
> ===================================================================
> --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/signal_64.c
> +++ linux-2.6.ppc64_test/arch/powerpc/kernel/signal_64.c
> @@ -33,6 +33,7 @@
> #include <asm/cacheflush.h>
> #include <asm/syscalls.h>
> #include <asm/vdso.h>
> +#include <asm/hw_breakpoint.h>
>
> #include "signal.h"
>
> @@ -312,6 +313,7 @@ int sys_swapcontext(struct ucontext __us
> || __copy_to_user(&old_ctx->uc_sigmask,
> ¤t->blocked, sizeof(sigset_t)))
> return -EFAULT;
> + thread_change_pc(current);
This is in the part of the code that is saving the old context, after
the old context has been saved. We need to do it before saving the
old context so that the saved context doesn't have the MSR_SE bit set
in its MSR image. And similarly in the 32-bit version.
In fact, we probably don't need to do anything here. We should never
get into a system call (such as sys_swapcontext or sys_sigreturn) when
single-stepping a load or store that caused a DABR match. If we do,
something very strange is happening. So I would leave out the
swapcontext changes for this version.
Paul.
^ permalink raw reply
* Re: [Patch 3/4] PPC64-HWBKPT: Handle concurrent alignment interrupts
From: Paul Mackerras @ 2010-05-27 6:20 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, linuxppc-dev@ozlabs.org,
Alan Stern, Roland McGrath
In-Reply-To: <20100525091435.GD29003@in.ibm.com>
On Tue, May 25, 2010 at 02:44:35PM +0530, K.Prasad wrote:
> An alignment interrupt may intervene between a DSI/hw-breakpoint exception
> and the single-step exception. Enable the alignment interrupt (through
> modifications to emulate_single_step()) to notify the single-step exception
> handler for proper restoration of hw-breakpoints.
>
> Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/traps.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> Index: linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
> ===================================================================
> --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/traps.c
> +++ linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
> @@ -602,7 +602,7 @@ void RunModeException(struct pt_regs *re
>
> void __kprobes single_step_exception(struct pt_regs *regs)
> {
> - regs->msr &= ~(MSR_SE | MSR_BE); /* Turn off 'trace' bits */
> + clear_single_step(regs);
>
> if (notify_die(DIE_SSTEP, "single_step", regs, 5,
> 5, SIGTRAP) == NOTIFY_STOP)
> @@ -621,10 +621,7 @@ void __kprobes single_step_exception(str
> */
> static void emulate_single_step(struct pt_regs *regs)
> {
> - if (single_stepping(regs)) {
> - clear_single_step(regs);
> - _exception(SIGTRAP, regs, TRAP_TRACE, 0);
> - }
> + single_step_exception(regs);
> }
We still need the if (single_stepping(regs)) in emulate_single_step.
We don't want to send the process a SIGTRAP every time it gets an
alignment interrupt. :)
Paul.
^ permalink raw reply
* Re: [Patch 2/4] PPC64-HWBKPT: Implement hw-breakpoints for PowerPC BookIII S
From: Paul Mackerras @ 2010-05-27 6:19 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, linuxppc-dev@ozlabs.org,
Alan Stern, Roland McGrath
In-Reply-To: <20100525091420.GC29003@in.ibm.com>
On Tue, May 25, 2010 at 02:44:20PM +0530, K.Prasad wrote:
> Implement perf-events based hw-breakpoint interfaces for PowerPC Book III S
> processors. These interfaces help arbitrate requests from various users and
> schedules them as appropriate.
A few comments on the code below...
> +int __kprobes hw_breakpoint_handler(struct die_args *args)
> +{
> + bool is_ptrace_bp = false;
> + int rc = NOTIFY_STOP;
> + struct perf_event *bp;
> + struct pt_regs *regs = args->regs;
> + unsigned long dar = regs->dar;
> + int stepped = 1;
> + struct arch_hw_breakpoint *info;
> +
> + /* Disable breakpoints during exception handling */
> + set_dabr(0);
> + /*
> + * The counter may be concurrently released but that can only
> + * occur from a call_rcu() path. We can then safely fetch
> + * the breakpoint, use its callback, touch its counter
> + * while we are in an rcu_read_lock() path.
> + */
> + rcu_read_lock();
> +
> + bp = __get_cpu_var(bp_per_reg);
> + if (!bp)
> + goto out;
> + info = counter_arch_bp(bp);
> + is_ptrace_bp = (bp->overflow_handler == ptrace_triggered) ?
> + true : false;
> +
> + /*
> + * Verify if dar lies within the address range occupied by the symbol
> + * being watched to filter extraneous exceptions.
> + */
> + if (!((bp->attr.bp_addr <= dar) &&
> + (dar <= (bp->attr.bp_addr + bp->attr.bp_len))) &&
> + (!is_ptrace_bp))
> + /*
> + * This exception is triggered not because of a memory access on
> + * the monitored variable but in the double-word address range
> + * in which it is contained. We will consume this exception,
> + * considering it as 'noise'.
> + */
> + goto restore_bp;
At this point we have to do the single-stepping, because the NIP is
still pointing at the instruction that caused the exception, and if we
just return to it with DABR set we won't make any progress, we'll just
take the same exception again immediately.
> +/*
> + * Handle single-step exceptions following a DABR hit.
> + */
> +int __kprobes single_step_dabr_instruction(struct die_args *args)
> +{
> + struct pt_regs *regs = args->regs;
> + struct perf_event *bp = NULL;
> + struct arch_hw_breakpoint *bp_info;
> +
> + bp = current->thread.last_hit_ubp;
> + /*
> + * Check if we are single-stepping as a result of a
> + * previous HW Breakpoint exception
> + */
> + if (!bp)
> + return NOTIFY_DONE;
> +
> + bp_info = counter_arch_bp(bp);
> +
> + /*
> + * We shall invoke the user-defined callback function in the single
> + * stepping handler to confirm to 'trigger-after-execute' semantics
> + */
> + perf_bp_event(bp, regs);
> +
> + /*
> + * Do not disable MSR_SE if the process was already in
> + * single-stepping mode.
> + */
> + if (!test_thread_flag(TIF_SINGLESTEP))
> + regs->msr &= ~MSR_SE;
> +
> + set_dabr(bp_info->address | bp_info->type | DABR_TRANSLATION);
> + return NOTIFY_STOP;
> +}
Nowhere in here do we reset current->thread.last_hit_ubp, yet other
parts of the code assume that .last_hit_ubp != NULL means that we are
currently single-stepping. I think we need to clear .last_hit_ubp
here.
> Index: linux-2.6.ppc64_test/arch/powerpc/kernel/process.c
> ===================================================================
> --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/process.c
> +++ linux-2.6.ppc64_test/arch/powerpc/kernel/process.c
> @@ -462,8 +462,14 @@ struct task_struct *__switch_to(struct t
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> switch_booke_debug_regs(&new->thread);
> #else
> +/*
> + * For PPC_BOOK3S_64, we use the hw-breakpoint interfaces that would
> + * schedule DABR
> + */
> +#ifndef CONFIG_HAVE_HW_BREAKPOINT
> if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
> set_dabr(new->thread.dabr);
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> #endif
Have you checked all the places that set_dabr is called to see whether
they are still needed with CONFIG_HAVE_HW_BREAKPOINT?
> Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h
> ===================================================================
> --- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/cputable.h
> +++ linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h
> @@ -516,6 +516,10 @@ static inline int cpu_has_feature(unsign
> & feature);
> }
>
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> +#define HBP_NUM 1
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
Why is this defined here, not in <asm/hw_breakpoint.h> ?
Paul.
^ permalink raw reply
* Re: [PATCH 1/2] net: ll_temac: fix interrupt bug when interrupt 0 is used
From: John Williams @ 2010-05-27 4:12 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev, netdev, Brian Hill, michal.simek
In-Reply-To: <6f264a7a-e5da-494a-a24d-1578ca422807@VA3EHSMHS016.ehs.local>
On Thu, May 27, 2010 at 3:29 AM, John Linn <john.linn@xilinx.com> wrote:
> The code is not checking the interrupt for DMA correctly so that an
> interrupt number of 0 will cause a false error.
>
> Signed-off-by: Brian Hill <brian.hill@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
> =A0drivers/net/ll_temac_main.c | =A0 =A02 +-
> =A01 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
> index fa7620e..0615737 100644
> --- a/drivers/net/ll_temac_main.c
> +++ b/drivers/net/ll_temac_main.c
> @@ -950,7 +950,7 @@ temac_of_probe(struct of_device *op, const struct of_=
device_id *match)
>
> =A0 =A0 =A0 =A0lp->rx_irq =3D irq_of_parse_and_map(np, 0);
> =A0 =A0 =A0 =A0lp->tx_irq =3D irq_of_parse_and_map(np, 1);
> - =A0 =A0 =A0 if (!lp->rx_irq || !lp->tx_irq) {
> + =A0 =A0 =A0 if ((lp->rx_irq =3D=3D NO_IRQ) || (lp->tx_irq =3D=3D NO_IRQ=
)) {
Personally I think this is the right thing to do. But, I thought the
IRQ 0 =3D=3D NO_IRQ (AKA "all-the-world's-an-x86-and-if-not-it-should-be")
holy war was already fought and won (or lost, depending on your
perspective)?
I seem to recall giving reluctant assent to a patch from Grant a few
months ago that touched MicroBlaze thus?
John
^ permalink raw reply
* Re: [PATCH 2/2] net: ll_temac: fix checksum offload logic
From: David Miller @ 2010-05-27 3:45 UTC (permalink / raw)
To: john.linn; +Cc: linuxppc-dev, netdev, brian.hill, michal.simek, john.williams
In-Reply-To: <0690e798-1e5e-4416-90dc-04a9df16600f@SG2EHSMHS005.ehs.local>
aFrom: John Linn <john.linn@xilinx.com>
Date: Wed, 26 May 2010 11:29:19 -0600
> The current checksum offload code does not work and this corrects
> that functionality. It also updates the interrupt coallescing
> initialization so than there are fewer interrupts and performance
> is increased.
>
> Signed-off-by: Brian Hill <brian.hill@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Applied, although I changed "temac_features" to be explicitly
"unsigned int" instead of just plain "unsigned"
^ permalink raw reply
* Re: [PATCH 1/2] net: ll_temac: fix interrupt bug when interrupt 0 is used
From: David Miller @ 2010-05-27 3:44 UTC (permalink / raw)
To: john.linn; +Cc: linuxppc-dev, netdev, brian.hill, michal.simek, john.williams
In-Reply-To: <6f264a7a-e5da-494a-a24d-1578ca422807@VA3EHSMHS016.ehs.local>
From: John Linn <john.linn@xilinx.com>
Date: Wed, 26 May 2010 11:29:18 -0600
> The code is not checking the interrupt for DMA correctly so that an
> interrupt number of 0 will cause a false error.
>
> Signed-off-by: Brian Hill <brian.hill@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Applied.
^ permalink raw reply
* mpc8248 usb driver
From: 方宇 @ 2010-05-27 2:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 130 bytes --]
Does anyone have usb host driver for mpc8248? The Linux FHCI routine is too
hard to understand and seems not suitable for mpc8248
[-- Attachment #2: Type: text/html, Size: 130 bytes --]
^ permalink raw reply
* [PATCH] fs_enet: Adjust BDs after tx error
From: Mark Ware @ 2010-05-27 1:12 UTC (permalink / raw)
To: Linuxppc-dev Development, netdev; +Cc: Vitaly Bordug
This patch fixes an occasional transmit lockup in the mac-fcc which
occurs after a tx error. The test scenario had the local port set
to autoneg and the other end fixed at 100FD, resulting in a large
number of late collisions.
According to the MPC8280RM 30.10.1.3 (also 8272RM 29.10.1.3), after
a tx error occurs, TBPTR may sometimes point beyond BDs still marked
as ready. This patch walks back through the BDs and points TBPTR to
the earliest one marked as ready.
Tested on a custom board with a MPC8280.
Signed-off-by: Mark Ware <mware@elphinstone.net>
---
drivers/net/fs_enet/mac-fcc.c | 49 ++++++++++++++++++++++++++++++++++++-----
1 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index 22e5a84..6023f15 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -503,17 +503,54 @@ static int get_regs_len(struct net_device *dev)
}
/* Some transmit errors cause the transmitter to shut
- * down. We now issue a restart transmit. Since the
- * errors close the BD and update the pointers, the restart
- * _should_ pick up without having to reset any of our
- * pointers either. Also, To workaround 8260 device erratum
- * CPM37, we must disable and then re-enable the transmitter
- * following a Late Collision, Underrun, or Retry Limit error.
+ * down. We now issue a restart transmit.
+ * Also, to workaround 8260 device erratum CPM37, we must
+ * disable and then re-enable the transmitterfollowing a
+ * Late Collision, Underrun, or Retry Limit error.
+ * In addition, tbptr may point beyond BDs beyond still marked
+ * as ready due to internal pipelining, so we need to look back
+ * through the BDs and adjust tbptr to point to the last BD
+ * marked as ready. This may result in some buffers being
+ * retransmitted.
*/
static void tx_restart(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
fcc_t __iomem *fccp = fep->fcc.fccp;
+ const struct fs_platform_info *fpi = fep->fpi;
+ fcc_enet_t __iomem *ep = fep->fcc.ep;
+ cbd_t __iomem *curr_tbptr;
+ cbd_t __iomem *recheck_bd;
+ cbd_t __iomem *prev_bd;
+ cbd_t __iomem *last_tx_bd;
+
+ last_tx_bd = fep->tx_bd_base + (fpi->tx_ring * sizeof(cbd_t));
+
+ /* get the current bd held in TBPTR and scan back from this point */
+ recheck_bd = curr_tbptr = (cbd_t __iomem *)
+ ((R32(ep, fen_genfcc.fcc_tbptr) - fep->ring_mem_addr) +
+ fep->ring_base);
+
+ prev_bd = (recheck_bd == fep->tx_bd_base) ? last_tx_bd : recheck_bd - 1;
+
+ /* Move through the bds in reverse, look for the earliest buffer
+ * that is not ready. Adjust TBPTR to the following buffer */
+ while ((CBDR_SC(prev_bd) & BD_ENET_TX_READY) != 0) {
+ /* Go back one buffer */
+ recheck_bd = prev_bd;
+
+ /* update the previous buffer */
+ prev_bd = (prev_bd == fep->tx_bd_base) ? last_tx_bd : prev_bd - 1;
+
+ /* We should never see all bds marked as ready, check anyway */
+ if (recheck_bd == curr_tbptr)
+ break;
+ }
+ /* Now update the TBPTR and dirty flag to the current buffer */
+ W32(ep, fen_genfcc.fcc_tbptr,
+ (uint) (((void *)recheck_bd - fep->ring_base) +
+ fep->ring_mem_addr));
+ fep->dirty_tx = recheck_bd;
C32(fccp, fcc_gfmr, FCC_GFMR_ENT);
udelay(10);
--
1.5.6.5
^ permalink raw reply related
* Re: Build failure on PPC32 due to 60adec6226bbcf0
From: Michael Neuling @ 2010-05-26 21:00 UTC (permalink / raw)
To: Michael Guntsche; +Cc: linuxppc-dev
In-Reply-To: <20100526073017.GA24005@gibson.comsick.at>
> I recently started a test build of the current git tree for one of my
> PPC machines. I got a build error about crash_kexec_wait_realmode
> being implicitly declared. Looking at the changes I saw that your
> "powerpc/kdump: Fix race in kdump shutdown" patch introduced this
> function but only if CONFIG_SMP is defined. This is not the case in my
> config (single CPU).
Yep, this is known. Kumar is going to clean it up soon.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082631.html
Mikey
^ permalink raw reply
* [PATCH 1/2] net: ll_temac: fix interrupt bug when interrupt 0 is used
From: John Linn @ 2010-05-26 17:29 UTC (permalink / raw)
To: netdev, linuxppc-dev, grant.likely, jwboyer
Cc: michal.simek, John Linn, john.williams, Brian Hill
The code is not checking the interrupt for DMA correctly so that an
interrupt number of 0 will cause a false error.
Signed-off-by: Brian Hill <brian.hill@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/net/ll_temac_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index fa7620e..0615737 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -950,7 +950,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
lp->rx_irq = irq_of_parse_and_map(np, 0);
lp->tx_irq = irq_of_parse_and_map(np, 1);
- if (!lp->rx_irq || !lp->tx_irq) {
+ if ((lp->rx_irq == NO_IRQ) || (lp->tx_irq == NO_IRQ)) {
dev_err(&op->dev, "could not determine irqs\n");
rc = -ENOMEM;
goto nodev;
--
1.6.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 2/2] net: ll_temac: fix checksum offload logic
From: John Linn @ 2010-05-26 17:29 UTC (permalink / raw)
To: netdev, linuxppc-dev, grant.likely, jwboyer
Cc: michal.simek, John Linn, john.williams, Brian Hill
In-Reply-To: <1274894959-27473-1-git-send-email-john.linn@xilinx.com>
The current checksum offload code does not work and this corrects
that functionality. It also updates the interrupt coallescing
initialization so than there are fewer interrupts and performance
is increased.
Signed-off-by: Brian Hill <brian.hill@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/net/ll_temac.h | 5 +++
drivers/net/ll_temac_main.c | 82 ++++++++++++++++++++++++++++++------------
2 files changed, 63 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index c033584..2e0c9cc 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -295,6 +295,10 @@ This option defaults to enabled (set) */
#define MULTICAST_CAM_TABLE_NUM 4
+/* TEMAC Synthesis features */
+#define TEMAC_FEATURE_RX_CSUM (1 << 0)
+#define TEMAC_FEATURE_TX_CSUM (1 << 1)
+
/* TX/RX CURDESC_PTR points to first descriptor */
/* TX/RX TAILDESC_PTR points to last descriptor in linked list */
@@ -353,6 +357,7 @@ struct temac_local {
struct mutex indirect_mutex;
u32 options; /* Current options word */
int last_link;
+ unsigned temac_features;
/* Buffer descriptors */
struct cdmac_bd *tx_bd_v;
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 0615737..52dcc84 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -245,7 +245,7 @@ static int temac_dma_bd_init(struct net_device *ndev)
CHNL_CTRL_IRQ_COAL_EN);
/* 0x10220483 */
/* 0x00100483 */
- lp->dma_out(lp, RX_CHNL_CTRL, 0xff010000 |
+ lp->dma_out(lp, RX_CHNL_CTRL, 0xff070000 |
CHNL_CTRL_IRQ_EN |
CHNL_CTRL_IRQ_DLY_EN |
CHNL_CTRL_IRQ_COAL_EN |
@@ -574,6 +574,10 @@ static void temac_start_xmit_done(struct net_device *ndev)
if (cur_p->app4)
dev_kfree_skb_irq((struct sk_buff *)cur_p->app4);
cur_p->app0 = 0;
+ cur_p->app1 = 0;
+ cur_p->app2 = 0;
+ cur_p->app3 = 0;
+ cur_p->app4 = 0;
ndev->stats.tx_packets++;
ndev->stats.tx_bytes += cur_p->len;
@@ -589,6 +593,29 @@ static void temac_start_xmit_done(struct net_device *ndev)
netif_wake_queue(ndev);
}
+static inline int temac_check_tx_bd_space(struct temac_local *lp, int num_frag)
+{
+ struct cdmac_bd *cur_p;
+ int tail;
+
+ tail = lp->tx_bd_tail;
+ cur_p = &lp->tx_bd_v[tail];
+
+ do {
+ if (cur_p->app0)
+ return NETDEV_TX_BUSY;
+
+ tail++;
+ if (tail >= TX_BD_NUM)
+ tail = 0;
+
+ cur_p = &lp->tx_bd_v[tail];
+ num_frag--;
+ } while (num_frag >= 0);
+
+ return 0;
+}
+
static int temac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct temac_local *lp = netdev_priv(ndev);
@@ -603,7 +630,7 @@ static int temac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
start_p = lp->tx_bd_p + sizeof(*lp->tx_bd_v) * lp->tx_bd_tail;
cur_p = &lp->tx_bd_v[lp->tx_bd_tail];
- if (cur_p->app0 & STS_CTRL_APP0_CMPLT) {
+ if (temac_check_tx_bd_space(lp, num_frag)) {
if (!netif_queue_stopped(ndev)) {
netif_stop_queue(ndev);
return NETDEV_TX_BUSY;
@@ -613,29 +640,14 @@ static int temac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
cur_p->app0 = 0;
if (skb->ip_summed == CHECKSUM_PARTIAL) {
- const struct iphdr *ip = ip_hdr(skb);
- int length = 0, start = 0, insert = 0;
-
- switch (ip->protocol) {
- case IPPROTO_TCP:
- start = sizeof(struct iphdr) + ETH_HLEN;
- insert = sizeof(struct iphdr) + ETH_HLEN + 16;
- length = ip->tot_len - sizeof(struct iphdr);
- break;
- case IPPROTO_UDP:
- start = sizeof(struct iphdr) + ETH_HLEN;
- insert = sizeof(struct iphdr) + ETH_HLEN + 6;
- length = ip->tot_len - sizeof(struct iphdr);
- break;
- default:
- break;
- }
- cur_p->app1 = ((start << 16) | insert);
- cur_p->app2 = csum_tcpudp_magic(ip->saddr, ip->daddr,
- length, ip->protocol, 0);
- skb->data[insert] = 0;
- skb->data[insert + 1] = 0;
+ unsigned int csum_start_off = skb_transport_offset(skb);
+ unsigned int csum_index_off = csum_start_off + skb->csum_offset;
+
+ cur_p->app0 |= 1; /* TX Checksum Enabled */
+ cur_p->app1 = (csum_start_off << 16) | csum_index_off;
+ cur_p->app2 = 0; /* initial checksum seed */
}
+
cur_p->app0 |= STS_CTRL_APP0_SOP;
cur_p->len = skb_headlen(skb);
cur_p->phys = dma_map_single(ndev->dev.parent, skb->data, skb->len,
@@ -699,6 +711,15 @@ static void ll_temac_recv(struct net_device *ndev)
skb->protocol = eth_type_trans(skb, ndev);
skb->ip_summed = CHECKSUM_NONE;
+ /* if we're doing rx csum offload, set it up */
+ if (((lp->temac_features & TEMAC_FEATURE_RX_CSUM) != 0) &&
+ (skb->protocol == __constant_htons(ETH_P_IP)) &&
+ (skb->len > 64)) {
+
+ skb->csum = cur_p->app3 & 0xFFFF;
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ }
+
netif_rx(skb);
ndev->stats.rx_packets++;
@@ -883,6 +904,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
struct temac_local *lp;
struct net_device *ndev;
const void *addr;
+ __be32 *p;
int size, rc = 0;
/* Init network device structure */
@@ -926,6 +948,18 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
goto nodev;
}
+ /* Setup checksum offload, but default to off if not specified */
+ lp->temac_features = 0;
+ p = (__be32 *)of_get_property(op->dev.of_node, "xlnx,txcsum", NULL);
+ if (p && be32_to_cpu(*p)) {
+ lp->temac_features |= TEMAC_FEATURE_TX_CSUM;
+ /* Can checksum TCP/UDP over IPv4. */
+ ndev->features |= NETIF_F_IP_CSUM;
+ }
+ p = (__be32 *)of_get_property(op->dev.of_node, "xlnx,rxcsum", NULL);
+ if (p && be32_to_cpu(*p))
+ lp->temac_features |= TEMAC_FEATURE_RX_CSUM;
+
/* Find the DMA node, map the DMA registers, and decode the DMA IRQs */
np = of_parse_phandle(op->dev.of_node, "llink-connected", 0);
if (!np) {
--
1.6.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
From: Frederic Weisbecker @ 2010-05-26 17:35 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Linux Kernel Mailing List, Millton Miller, David Gibson,
linuxppc-dev@ozlabs.org, Alan Stern, Paul Mackerras,
Andrew Morton, Roland McGrath
In-Reply-To: <20100526173124.GA8283@in.ibm.com>
On Wed, May 26, 2010 at 11:01:24PM +0530, K.Prasad wrote:
> On Wed, May 26, 2010 at 07:23:15PM +0200, Frederic Weisbecker wrote:
> > On Wed, May 26, 2010 at 10:47:42PM +0530, K.Prasad wrote:
> > > On Wed, May 26, 2010 at 10:54:41AM +0100, David Howells wrote:
> > > > K.Prasad <prasad@linux.vnet.ibm.com> wrote:
> > > >
> > > > > > My understanding is weak function definitions must appear in a different C
> > > > > > file than their call sites to work on some toolchains.
> > > > > >
> > > > >
> > > > > Atleast, there are quite a few precedents inside the Linux kernel for
> > > > > __weak functions being invoked from the file in which they are defined
> > > > > (arch_hwblk_init, arch_enable_nonboot_cpus_begin and hw_perf_disable to
> > > > > name a few).
> > > > > Moreover the online GCC docs haven't any such constraints mentioned.
> > > >
> > > > I've seen problems in this area. gcc sometimes inlines a weak function that's
> > > > in the same file as the call point.
> > > >
> > >
> > > We've seen such behaviour even otherwise....even with noinline attribute
> > > in place. I'm not sure if this gcc fix
> > > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16922) helped correct the
> > > behaviour, but the lesson has been to not trust a function to be
> > > inlined/remain non-inline consistently.
> >
> >
> > If we can't put the call to the function in the same file of its weak
> > definition, then perf is totally screwed.
> >
> > And in fact it makes __weak basically useless and unusable. I guess
> > that happened in old gcc versions that have been fixed now.
> >
> > Anyway, I'm personally fine with this patch (you can put my hack
> > if you want).
> >
>
> I guess you meant "Acked-by:" :-)
Oops, right :)
^ permalink raw reply
* Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
From: K.Prasad @ 2010-05-26 17:31 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Linux Kernel Mailing List, Millton Miller, David Gibson,
linuxppc-dev@ozlabs.org, Alan Stern, Paul Mackerras,
Andrew Morton, Roland McGrath
In-Reply-To: <20100526172314.GD5299@nowhere>
On Wed, May 26, 2010 at 07:23:15PM +0200, Frederic Weisbecker wrote:
> On Wed, May 26, 2010 at 10:47:42PM +0530, K.Prasad wrote:
> > On Wed, May 26, 2010 at 10:54:41AM +0100, David Howells wrote:
> > > K.Prasad <prasad@linux.vnet.ibm.com> wrote:
> > >
> > > > > My understanding is weak function definitions must appear in a different C
> > > > > file than their call sites to work on some toolchains.
> > > > >
> > > >
> > > > Atleast, there are quite a few precedents inside the Linux kernel for
> > > > __weak functions being invoked from the file in which they are defined
> > > > (arch_hwblk_init, arch_enable_nonboot_cpus_begin and hw_perf_disable to
> > > > name a few).
> > > > Moreover the online GCC docs haven't any such constraints mentioned.
> > >
> > > I've seen problems in this area. gcc sometimes inlines a weak function that's
> > > in the same file as the call point.
> > >
> >
> > We've seen such behaviour even otherwise....even with noinline attribute
> > in place. I'm not sure if this gcc fix
> > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16922) helped correct the
> > behaviour, but the lesson has been to not trust a function to be
> > inlined/remain non-inline consistently.
>
>
> If we can't put the call to the function in the same file of its weak
> definition, then perf is totally screwed.
>
> And in fact it makes __weak basically useless and unusable. I guess
> that happened in old gcc versions that have been fixed now.
>
> Anyway, I'm personally fine with this patch (you can put my hack
> if you want).
>
I guess you meant "Acked-by:" :-)
Thanks, I'll add the same.
--K.Prasad
^ permalink raw reply
* Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
From: K.Prasad @ 2010-05-26 17:28 UTC (permalink / raw)
To: David Howells
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, Linux Kernel Mailing List, Millton Miller,
David Gibson, linuxppc-dev@ozlabs.org, Alan Stern, Paul Mackerras,
Andrew Morton, Roland McGrath
In-Reply-To: <20100526171742.GA5563@in.ibm.com>
On Wed, May 26, 2010 at 10:47:42PM +0530, K.Prasad wrote:
> On Wed, May 26, 2010 at 10:54:41AM +0100, David Howells wrote:
> > K.Prasad <prasad@linux.vnet.ibm.com> wrote:
> >
> > > > My understanding is weak function definitions must appear in a different C
> > > > file than their call sites to work on some toolchains.
> > > >
> > >
> > > Atleast, there are quite a few precedents inside the Linux kernel for
> > > __weak functions being invoked from the file in which they are defined
> > > (arch_hwblk_init, arch_enable_nonboot_cpus_begin and hw_perf_disable to
> > > name a few).
> > > Moreover the online GCC docs haven't any such constraints mentioned.
> >
> > I've seen problems in this area. gcc sometimes inlines a weak function that's
> > in the same file as the call point.
> >
>
> We've seen such behaviour even otherwise....even with noinline attribute
> in place. I'm not sure if this gcc fix
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16922) helped correct the
Looks like I cited the wrong bug. The appropriate one is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34563.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
From: Frederic Weisbecker @ 2010-05-26 17:23 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Linux Kernel Mailing List, Millton Miller, David Gibson,
linuxppc-dev@ozlabs.org, Alan Stern, Paul Mackerras,
Andrew Morton, Roland McGrath
In-Reply-To: <20100526171742.GA5563@in.ibm.com>
On Wed, May 26, 2010 at 10:47:42PM +0530, K.Prasad wrote:
> On Wed, May 26, 2010 at 10:54:41AM +0100, David Howells wrote:
> > K.Prasad <prasad@linux.vnet.ibm.com> wrote:
> >
> > > > My understanding is weak function definitions must appear in a different C
> > > > file than their call sites to work on some toolchains.
> > > >
> > >
> > > Atleast, there are quite a few precedents inside the Linux kernel for
> > > __weak functions being invoked from the file in which they are defined
> > > (arch_hwblk_init, arch_enable_nonboot_cpus_begin and hw_perf_disable to
> > > name a few).
> > > Moreover the online GCC docs haven't any such constraints mentioned.
> >
> > I've seen problems in this area. gcc sometimes inlines a weak function that's
> > in the same file as the call point.
> >
>
> We've seen such behaviour even otherwise....even with noinline attribute
> in place. I'm not sure if this gcc fix
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16922) helped correct the
> behaviour, but the lesson has been to not trust a function to be
> inlined/remain non-inline consistently.
If we can't put the call to the function in the same file of its weak
definition, then perf is totally screwed.
And in fact it makes __weak basically useless and unusable. I guess
that happened in old gcc versions that have been fixed now.
Anyway, I'm personally fine with this patch (you can put my hack
if you want).
Thanks.
^ permalink raw reply
* Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
From: K.Prasad @ 2010-05-26 17:17 UTC (permalink / raw)
To: David Howells
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, Linux Kernel Mailing List, Millton Miller,
David Gibson, linuxppc-dev@ozlabs.org, Alan Stern, Paul Mackerras,
Andrew Morton, Roland McGrath
In-Reply-To: <4250.1274867681@redhat.com>
On Wed, May 26, 2010 at 10:54:41AM +0100, David Howells wrote:
> K.Prasad <prasad@linux.vnet.ibm.com> wrote:
>
> > > My understanding is weak function definitions must appear in a different C
> > > file than their call sites to work on some toolchains.
> > >
> >
> > Atleast, there are quite a few precedents inside the Linux kernel for
> > __weak functions being invoked from the file in which they are defined
> > (arch_hwblk_init, arch_enable_nonboot_cpus_begin and hw_perf_disable to
> > name a few).
> > Moreover the online GCC docs haven't any such constraints mentioned.
>
> I've seen problems in this area. gcc sometimes inlines a weak function that's
> in the same file as the call point.
>
We've seen such behaviour even otherwise....even with noinline attribute
in place. I'm not sure if this gcc fix
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16922) helped correct the
behaviour, but the lesson has been to not trust a function to be
inlined/remain non-inline consistently.
> David
Thanks,
K.Prasad
^ permalink raw reply
* [PATCHv3] [RFC] Xilinx Virtex 4 FX Soft FPU support
From: Sergey Temerkhanov @ 2010-05-26 17:04 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Josh Boyer, John Linn
This patch enables support for Xilinx Virtex 4 FX singe-float FPU.
Changelog v2-v3:
-Fixed whitespaces for SAVE_FPR/REST_FPR.
-Changed description of MSR_AP bit.
-Removed the stub for APU unavailable exception.
Changelog v1->v2:
-Added MSR_AP bit definition
-Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to
'Platform support' and made it Virtex4-FX-only.
-Changed SAVE_FPR/REST_FPR definition style.
Caveats:
- Hard-float binaries which rely on in-kernel math emulation will
give wrong results since they expect 64-bit double-precision instead of
32-bit single-precision numbers which Xilinx V4-FX Soft FPU produces.
Signed-off-by: Sergey Temerkhanov<temerkhanov@cifronik.ru>
diff -r 626de0d94469 arch/powerpc/include/asm/ppc_asm.h
--- a/arch/powerpc/include/asm/ppc_asm.h Wed May 26 15:33:32 2010 +0400
+++ b/arch/powerpc/include/asm/ppc_asm.h Wed May 26 20:30:43 2010 +0400
@@ -85,13 +85,21 @@
#define REST_8GPRS(n, base) REST_4GPRS(n, base); REST_4GPRS(n+4, base)
#define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base)
+
+#ifdef CONFIG_XILINX_SOFTFPU
+#define SAVE_FPR(n, base) stfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base) lfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#else
#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#endif
+
#define SAVE_2FPRS(n, base) SAVE_FPR(n, base); SAVE_FPR(n+1, base)
#define SAVE_4FPRS(n, base) SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
#define SAVE_8FPRS(n, base) SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
#define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
#define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base)
-#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+
#define REST_2FPRS(n, base) REST_FPR(n, base); REST_FPR(n+1, base)
#define REST_4FPRS(n, base) REST_2FPRS(n, base); REST_2FPRS(n+2, base)
#define REST_8FPRS(n, base) REST_4FPRS(n, base); REST_4FPRS(n+4, base)
diff -r 626de0d94469 arch/powerpc/include/asm/reg.h
--- a/arch/powerpc/include/asm/reg.h Wed May 26 15:33:32 2010 +0400
+++ b/arch/powerpc/include/asm/reg.h Wed May 26 20:30:43 2010 +0400
@@ -30,6 +30,7 @@
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
#define MSR_HV_LG 60 /* Hypervisor state */
#define MSR_VEC_LG 25 /* Enable AltiVec */
+#define MSR_AP_LG 25 /* Enable PPC405 APU */
#define MSR_VSX_LG 23 /* Enable VSX */
#define MSR_POW_LG 18 /* Enable Power Management */
#define MSR_WE_LG 18 /* Wait State Enable */
@@ -71,6 +72,7 @@
#define MSR_HV 0
#endif
+#define MSR_AP __MASK(MSR_AP_LG) /* Enable PPC405 APU */
#define MSR_VEC __MASK(MSR_VEC_LG) /* Enable AltiVec */
#define MSR_VSX __MASK(MSR_VSX_LG) /* Enable VSX */
#define MSR_POW __MASK(MSR_POW_LG) /* Enable Power Management */
diff -r 626de0d94469 arch/powerpc/kernel/fpu.S
--- a/arch/powerpc/kernel/fpu.S Wed May 26 15:33:32 2010 +0400
+++ b/arch/powerpc/kernel/fpu.S Wed May 26 20:30:43 2010 +0400
@@ -57,6 +57,9 @@
_GLOBAL(load_up_fpu)
mfmsr r5
ori r5,r5,MSR_FP
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r5,r5,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
@@ -85,6 +88,9 @@
toreal(r5)
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r10,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r10,r10,MSR_AP@h
+#endif
andc r4,r4,r10 /* disable FP for previous task */
PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
1:
@@ -94,6 +100,9 @@
mfspr r5,SPRN_SPRG3 /* current task's THREAD (phys) */
lwz r4,THREAD_FPEXC_MODE(r5)
ori r9,r9,MSR_FP /* enable FP for current */
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r9,r9,MSR_AP@h
+#endif
or r9,r9,r4
#else
ld r4,PACACURRENT(r13)
@@ -124,6 +133,9 @@
_GLOBAL(giveup_fpu)
mfmsr r5
ori r5,r5,MSR_FP
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r5,r5,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
@@ -145,6 +157,9 @@
beq 1f
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r3,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r3,r3,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r3,r3,MSR_VSX@h
diff -r 626de0d94469 arch/powerpc/kernel/head_40x.S
--- a/arch/powerpc/kernel/head_40x.S Wed May 26 15:33:32 2010 +0400
+++ b/arch/powerpc/kernel/head_40x.S Wed May 26 20:30:43 2010 +0400
@@ -420,7 +420,19 @@
addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_STD(0x700, program_check_exception)
+/* 0x0800 - FPU unavailable Exception */
+#ifdef CONFIG_PPC_FPU
+ START_EXCEPTION(0x0800, FloatingPointUnavailable)
+ NORMAL_EXCEPTION_PROLOG
+ beq 1f; \
+ bl load_up_fpu; /* if from user, just load it up */ \
+ b fast_exception_return; \
+1: addi r3,r1,STACK_FRAME_OVERHEAD; \
+ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
+#else
EXCEPTION(0x0800, Trap_08, unknown_exception, EXC_XFER_EE)
+#endif
+
EXCEPTION(0x0900, Trap_09, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0A00, Trap_0A, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0B00, Trap_0B, unknown_exception, EXC_XFER_EE)
@@ -821,8 +833,10 @@
* The PowerPC 4xx family of processors do not have an FPU, so this just
* returns.
*/
+#ifndef CONFIG_PPC_FPU
_ENTRY(giveup_fpu)
blr
+#endif
/* This is where the main kernel code starts.
*/
diff -r 626de0d94469 arch/powerpc/platforms/Kconfig
--- a/arch/powerpc/platforms/Kconfig Wed May 26 15:33:32 2010 +0400
+++ b/arch/powerpc/platforms/Kconfig Wed May 26 20:30:43 2010 +0400
@@ -333,4 +333,9 @@
bool "Xilinx PCI host bridge support"
depends on PCI && XILINX_VIRTEX
+config XILINX_SOFTFPU
+ bool "Xilinx Soft FPU"
+ select PPC_FPU
+ depends on XILINX_VIRTEX_4_FX && !PPC40x_SIMPLE && !405GP && !405GPR
+
endmenu
--
Regards, Sergey Temerkhanov,
Cifronic ZAO
^ permalink raw reply
* Re: [PATCHv2] [RFC] Xilinx Virtex 4 FX Soft FPU support
From: Sergey Temerkhanov @ 2010-05-26 16:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, John Linn
In-Reply-To: <AANLkTimJUqD6n9LHGZcWEkHFKvSRJsHJ9gQYMNBsIBu1@mail.gmail.com>
On Wednesday 26 May 2010 01:38:47 Grant Likely wrote:
> (cc'ing Josh Boyer and John Linn)
>
> On Thu, May 20, 2010 at 4:01 AM, Sergey Temerkhanov
>
> <temerkhanov@cifronik.ru> wrote:
> > This patch enables support for Xilinx Virtex 4 FX singe-float FPU.
> >
> > Changelog v1->v2:
> > -Added MSR_AP bit definition
> > -Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to
> > 'Platform support' and made it Virtex4-FX-only.
> > -Changed SAVE_FPR/REST_FPR definition style.
> >
> > Caveats:
> > - Hard-float binaries which rely on in-kernel math emulation will
> > give wrong results since they expect 64-bit double-precision instead of
> > 32-bit single-precision numbers which Xilinx V4-FX Soft FPU produces.
> >
> > Regards, Sergey Temerkhanov
>
> Hi Sergey. Comments below.
>
> First off, see if you can use 'git mail' or some other way to inline
> your patches. Patches as attachments are awkward to deal with and the
> patch description is getting separated from the patch itself.
>
> > Signed-off-by: Sergey Temerkhanov<temerkhanov@cifronik.ru>
> >
> > diff -r b59861a64e13 arch/powerpc/include/asm/ppc_asm.h
> > --- a/arch/powerpc/include/asm/ppc_asm.h Thu May 20 13:24:53 2010 +0400
> > +++ b/arch/powerpc/include/asm/ppc_asm.h Thu May 20 13:55:10 2010 +0400
> > @@ -85,13 +85,21 @@
> > #define REST_8GPRS(n, base) REST_4GPRS(n, base); REST_4GPRS(n+4, base)
> > #define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base)
> >
> > -#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> > +
> > +#ifdef CONFIG_XILINX_SOFTFPU
> > +#define SAVE_FPR(n, base) stfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> > +#define REST_FPR(n, base) lfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> > +#else
> > +#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> > +#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> > +#endif
> > +
>
> Hint: If you don't change the whitespace on the SAVE_FPR() line, then diff
> will realize it is unchanged and reviewers will have more context queues
> as to what you are doing.
>
> Otherwise, this looks better.
Agreed, I've missed it somehow.
>
> > #define SAVE_2FPRS(n, base) SAVE_FPR(n, base); SAVE_FPR(n+1, base)
> > #define SAVE_4FPRS(n, base) SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
> > #define SAVE_8FPRS(n, base) SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
> > #define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
> > #define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16,
> > base) -#define REST_FPR(n,
> > base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) +
> > #define REST_2FPRS(n, base) REST_FPR(n, base); REST_FPR(n+1, base)
> > #define REST_4FPRS(n, base) REST_2FPRS(n, base); REST_2FPRS(n+2, base)
> > #define REST_8FPRS(n, base) REST_4FPRS(n, base); REST_4FPRS(n+4, base)
> > diff -r b59861a64e13 arch/powerpc/include/asm/reg.h
> > --- a/arch/powerpc/include/asm/reg.h Thu May 20 13:24:53 2010 +0400
> > +++ b/arch/powerpc/include/asm/reg.h Thu May 20 13:55:10 2010 +0400
> > @@ -30,6 +30,7 @@
> > #define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
> > #define MSR_HV_LG 60 /* Hypervisor state */
> > #define MSR_VEC_LG 25 /* Enable AltiVec */
> > +#define MSR_AP_LG 25 /* Enable APU */
> > #define MSR_VSX_LG 23 /* Enable VSX */
> > #define MSR_POW_LG 18 /* Enable Power Management */
> > #define MSR_WE_LG 18 /* Wait State Enable */
> > @@ -71,6 +72,7 @@
> > #define MSR_HV 0
> > #endif
> >
> > +#define MSR_AP __MASK(MSR_AP_LG) /* Enable APU */
>
> Need to be more specific: "Enable Xilinx Virtex 405 APU". Same goes
> for MSR_AP_LG line above.
This bit is also defined for PPC405 cores other than Xilinx, so I think it
will be better as "Enable PPC405 APU".
>
> > #define MSR_VEC __MASK(MSR_VEC_LG) /* Enable AltiVec */
> > #define MSR_VSX __MASK(MSR_VSX_LG) /* Enable VSX */
> > #define MSR_POW __MASK(MSR_POW_LG) /* Enable Power Management */
> > diff -r b59861a64e13 arch/powerpc/kernel/fpu.S
> > --- a/arch/powerpc/kernel/fpu.S Thu May 20 13:24:53 2010 +0400
> > +++ b/arch/powerpc/kernel/fpu.S Thu May 20 13:55:10 2010 +0400
> > @@ -57,6 +57,9 @@
> > _GLOBAL(load_up_fpu)
> > mfmsr r5
> > ori r5,r5,MSR_FP
> > +#ifdef CONFIG_XILINX_SOFTFPU
> > + oris r5,r5,MSR_AP@h
> > +#endif
> > #ifdef CONFIG_VSX
> > BEGIN_FTR_SECTION
> > oris r5,r5,MSR_VSX@h
> > @@ -85,6 +88,9 @@
> > toreal(r5)
> > PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
> > li r10,MSR_FP|MSR_FE0|MSR_FE1
> > +#ifdef CONFIG_XILINX_SOFTFPU
> > + oris r10,r10,MSR_AP@h
> > +#endif
> > andc r4,r4,r10 /* disable FP for previous task */
> > PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
> > 1:
> > @@ -94,6 +100,9 @@
> > mfspr r5,SPRN_SPRG3 /* current task's THREAD (phys) */
> > lwz r4,THREAD_FPEXC_MODE(r5)
> > ori r9,r9,MSR_FP /* enable FP for current */
> > +#ifdef CONFIG_XILINX_SOFTFPU
> > + oris r9,r9,MSR_AP@h
> > +#endif
> > or r9,r9,r4
> > #else
> > ld r4,PACACURRENT(r13)
> > @@ -124,6 +133,9 @@
> > _GLOBAL(giveup_fpu)
> > mfmsr r5
> > ori r5,r5,MSR_FP
> > +#ifdef CONFIG_XILINX_SOFTFPU
> > + oris r5,r5,MSR_AP@h
> > +#endif
> > #ifdef CONFIG_VSX
> > BEGIN_FTR_SECTION
> > oris r5,r5,MSR_VSX@h
> > @@ -145,6 +157,9 @@
> > beq 1f
> > PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
> > li r3,MSR_FP|MSR_FE0|MSR_FE1
> > +#ifdef CONFIG_XILINX_SOFTFPU
> > + oris r3,r3,MSR_AP@h
> > +#endif
> > #ifdef CONFIG_VSX
> > BEGIN_FTR_SECTION
> > oris r3,r3,MSR_VSX@h
> > diff -r b59861a64e13 arch/powerpc/kernel/head_40x.S
> > --- a/arch/powerpc/kernel/head_40x.S Thu May 20 13:24:53 2010 +0400
> > +++ b/arch/powerpc/kernel/head_40x.S Thu May 20 13:55:10 2010 +0400
> > @@ -420,7 +420,19 @@
> > addi r3,r1,STACK_FRAME_OVERHEAD
> > EXC_XFER_STD(0x700, program_check_exception)
> >
> > +/* 0x0800 - FPU unavailable Exception */
> > +#ifdef CONFIG_PPC_FPU
> > + START_EXCEPTION(0x0800, FloatingPointUnavailable)
> > + NORMAL_EXCEPTION_PROLOG
> > + beq 1f; \
> > + bl load_up_fpu; /* if from user, just load it up */ \
> > + b fast_exception_return; \
> > +1: addi r3,r1,STACK_FRAME_OVERHEAD; \
> > + EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
> > +#else
> > EXCEPTION(0x0800, Trap_08, unknown_exception, EXC_XFER_EE)
> > +#endif
> > +
> > EXCEPTION(0x0900, Trap_09, unknown_exception, EXC_XFER_EE)
> > EXCEPTION(0x0A00, Trap_0A, unknown_exception, EXC_XFER_EE)
> > EXCEPTION(0x0B00, Trap_0B, unknown_exception, EXC_XFER_EE)
> > @@ -432,7 +444,7 @@
> >
> > EXCEPTION(0x0D00, Trap_0D, unknown_exception, EXC_XFER_EE)
> > EXCEPTION(0x0E00, Trap_0E, unknown_exception, EXC_XFER_EE)
> > - EXCEPTION(0x0F00, Trap_0F, unknown_exception, EXC_XFER_EE)
> > + EXCEPTION(0x0F20, Trap_0F, unknown_exception, EXC_XFER_EE)
>
> Is this change required to support the FPU? It looks like something
> that belongs in a separate patch.
Well, it's not exactly necessary - it's just a stub for "APU Unavailable
Exception". I'll move it to another patch.
>
> > /* 0x1000 - Programmable Interval Timer (PIT) Exception */
> > START_EXCEPTION(0x1000, Decrementer)
> > @@ -821,8 +833,10 @@
> > * The PowerPC 4xx family of processors do not have an FPU, so this just
> > * returns.
> > */
> > +#ifndef CONFIG_PPC_FPU
> > _ENTRY(giveup_fpu)
> > blr
> > +#endif
> >
> > /* This is where the main kernel code starts.
> > */
> > diff -r b59861a64e13 arch/powerpc/platforms/Kconfig
> > --- a/arch/powerpc/platforms/Kconfig Thu May 20 13:24:53 2010 +0400
> > +++ b/arch/powerpc/platforms/Kconfig Thu May 20 13:55:10 2010 +0400
> > @@ -333,4 +333,9 @@
> > bool "Xilinx PCI host bridge support"
> > depends on PCI && XILINX_VIRTEX
> >
> > +config XILINX_SOFTFPU
> > + bool "Xilinx Soft FPU"
> > + select PPC_FPU
> > + depends on XILINX_VIRTEX_4_FX && !PPC40x_SIMPLE && !405GP && !405GPR
> > +
>
> Hmmm. There should be a nicer way of doing this, but this will do for now.
>
> Otherwise, this patch looks good to me. Josh, what do you think?
>
> Cheers,
> g.
>
--
Regards, Sergey Temerkhanov,
Cifronic ZAO
^ permalink raw reply
* Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
From: Michael Ellerman @ 2010-05-26 15:13 UTC (permalink / raw)
To: David Howells
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, Linux Kernel Mailing List, Millton Miller,
David Gibson, linuxppc-dev@ozlabs.org, Alan Stern, Paul Mackerras,
Andrew Morton, prasad, Roland McGrath
In-Reply-To: <4250.1274867681@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]
On Wed, 2010-05-26 at 10:54 +0100, David Howells wrote:
> K.Prasad <prasad@linux.vnet.ibm.com> wrote:
>
> > > My understanding is weak function definitions must appear in a different C
> > > file than their call sites to work on some toolchains.
> > >
> >
> > Atleast, there are quite a few precedents inside the Linux kernel for
> > __weak functions being invoked from the file in which they are defined
> > (arch_hwblk_init, arch_enable_nonboot_cpus_begin and hw_perf_disable to
> > name a few).
> > Moreover the online GCC docs haven't any such constraints mentioned.
>
> I've seen problems in this area. gcc sometimes inlines a weak function that's
> in the same file as the call point.
See the functions in kernel/softirq.c for example, and commits 43a256322
and b2e2fe996 - though unhelpfully they don't mention the gcc version. A
bit of googling suggests it was probably "gcc version 4.1.1 20060525
(Red Hat 4.1.1-1)" in that case.
But the example of hw_perf_enable() (which is weak in the same unit),
suggests maybe this isn't a bug many people are hitting in practice
anymore.
Having said that the #define foo foo pattern is reasonably neat and
avoids the problem altogether, see eg. arch_setup_msi_irqs.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-booke: Move loadcam_entry back to asm code to fix SMP ftrace
From: Michael Ellerman @ 2010-05-26 14:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1274726319-4673-3-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
On Mon, 2010-05-24 at 13:38 -0500, Kumar Gala wrote:
> When we build with ftrace enabled its possible that loadcam_entry would
> have used the stack pointer (even though the code doesn't need it). We
> call loadcam_entry in __secondary_start before the stack is setup. To
> ensure that loadcam_entry doesn't use the stack pointer the easiest
> solution is to just have it in asm code.
You could move it to a separate file and have that not built with the
ftrace options (-pg etc.) - but maybe that's not easier.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/44x: icon: select SM502 and frame buffer console support
From: Josh Boyer @ 2010-05-26 12:54 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <1274870190-4712-1-git-send-email-agust@denx.de>
On Wed, May 26, 2010 at 12:36:30PM +0200, Anatolij Gustschin wrote:
>Enables SM502 frame buffer and framebuffer console
>in the default config file
>
>Signed-off-by: Anatolij Gustschin <agust@denx.de>
Thanks. I put this in my -next branch. Hopefully Ben pulls soon.
josh
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Josh Boyer @ 2010-05-26 12:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1274445754.1931.65.camel@pasglop>
On Fri, May 21, 2010 at 10:42:34PM +1000, Benjamin Herrenschmidt wrote:
>On Fri, 2010-05-21 at 06:22 -0400, Josh Boyer wrote:
>> On Fri, May 21, 2010 at 07:11:28PM +1000, Benjamin Herrenschmidt wrote:
>> >Hi Linus !
>> >
>> >Here's the powerpc batch for this merge window.
>> >
>> >Most of it is in arch/powerpc, a few powerpc specific drivers are hit
>> >too, including removing one that has been unused (and unselectable in
>> >Kconfig) for a long time (hdpuftrs), probably remains of a long dead
>> >platform.
>>
>> You missed my updated pull request. I still have some patches sitting in my
>> -next branch that should go in.
>
>Allright, I'll add them asap. Might have to wait for monday tho.
You still haven't pulled these, so I added another small defconfig change for
Icon. Very trivial. Updated diffstat below.
josh
The following changes since commit 99ec28f183daa450faa7bdad6f932364ae325648:
FUJITA Tomonori (1):
powerpc: Remove unused 'protect4gb' boot parameter
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next
Anatolij Gustschin (1):
powerpc/44x: icon: select SM502 and frame buffer console support
Benjamin Herrenschmidt (1):
powerpc/44x: Fix UART clocks on 440SPe
Stefan Roese (2):
powerpc/44x: Add reset-type to katmai.dts
powerpc/44x: Add basic ICON PPC440SPe board support
Tirumala Marri (1):
powerpc/44x: Adding PCI-E support for PowerPC 460SX based SOC.
arch/powerpc/boot/4xx.c | 12 +-
arch/powerpc/boot/dts/icon.dts | 447 +++++++++
arch/powerpc/boot/dts/katmai.dts | 1 +
arch/powerpc/boot/dts/redwood.dts | 122 +++
arch/powerpc/configs/44x/icon_defconfig | 1451 ++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/Kconfig | 11 +
arch/powerpc/platforms/44x/ppc44x_simple.c | 3 +-
arch/powerpc/sysdev/ppc4xx_pci.c | 119 +++
arch/powerpc/sysdev/ppc4xx_pci.h | 58 ++
9 files changed, 2217 insertions(+), 7 deletions(-)
create mode 100644 arch/powerpc/boot/dts/icon.dts
create mode 100644 arch/powerpc/configs/44x/icon_defconfig
^ permalink raw reply
* Re: [PATCHv2] [RFC] Xilinx Virtex 4 FX Soft FPU support
From: Josh Boyer @ 2010-05-26 11:50 UTC (permalink / raw)
To: Grant Likely; +Cc: Sergey Temerkhanov, linuxppc-dev, John Linn
In-Reply-To: <AANLkTimJUqD6n9LHGZcWEkHFKvSRJsHJ9gQYMNBsIBu1@mail.gmail.com>
On Tue, May 25, 2010 at 03:38:47PM -0600, Grant Likely wrote:
>Hmmm. There should be a nicer way of doing this, but this will do for now.
>
>Otherwise, this patch looks good to me. Josh, what do you think?
I don't have any additional comments. I agree with Grant on the points he
raised, and otherwise it also looks good to me.
josh
^ 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