* Re: invalid Kconfig "select" for MPC5121_ADS_CPLD
From: Grant Likely @ 2009-06-13 16:21 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux PPC Mailing List, Wolfgang Denk
In-Reply-To: <alpine.LFD.2.00.0906131109260.23298@localhost>
On Sat, Jun 13, 2009 at 9:11 AM, Robert P. J. Day<rpjday@crashcourse.ca> wr=
ote:
>
> =A0arch/powerpc/platforms/512x/Kconfig: =A0select MPC5121_ADS_CPLD
5121 support in mainline is half-baked. Wolfgang is working on a
patch series to update it (undergone one review cycle on the mailing
list). I don't know if he has published a git tree containing the
current state.
BTW, it is helpful to cc: the relevant maintainers when asking
questions about particular SoCs.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* invalid Kconfig "select" for MPC5121_ADS_CPLD
From: Robert P. J. Day @ 2009-06-13 15:11 UTC (permalink / raw)
To: Linux PPC Mailing List
arch/powerpc/platforms/512x/Kconfig: select MPC5121_ADS_CPLD
no such config directive anywhere.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH] sdhci: Add support for hosts that are only capable of 1-bit transfers
From: Grant Likely @ 2009-06-13 15:40 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Pierre Ossman, devicetree-discuss, sdhci-devel
In-Reply-To: <20090611201545.GA15942@oksana.dev.rtsoft.ru>
On Thu, Jun 11, 2009 at 2:15 PM, Anton
Vorontsov<avorontsov@ru.mvista.com> wrote:
> Some hosts (hardware configurations, or particular SD/MMC slots) may
> not support 4-bit bus. For example, on MPC8569E-MDS boards we can
> switch between serial (1-bit only) and nibble (4-bit) modes, thought
> we have to disable more peripherals to work in 4-bit mode.
>
> Along with some small core changes, this patch modifies sdhci-of
> driver, so that now it looks for "mode" property in the device-tree.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> Pierre, I'm not sure if a quirk would be appropriate here. If so,
> I can redo the patch with FORCE_1_BIT_DATA quirk.
>
> Thanks,
>
> =A0Documentation/powerpc/dts-bindings/fsl/esdhc.txt | =A0 =A02 ++
> =A0drivers/mmc/host/sdhci-of.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0| =A0 =A07 +++++++
> =A0drivers/mmc/host/sdhci-pci.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=
=A0 =A01 +
> =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 | =A0 =A02 +-
> =A04 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documenta=
tion/powerpc/dts-bindings/fsl/esdhc.txt
> index 5093ddf..298b865 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> @@ -10,6 +10,8 @@ Required properties:
> =A0 - interrupts : should contain eSDHC interrupt.
> =A0 - interrupt-parent : interrupt source phandle.
> =A0 - clock-frequency : specifies eSDHC base clock frequency.
> + =A0- mode : specifies eSDHC mode, valid values are: "1-bit" and "4-bit"=
.
> + =A0 =A0If mode is unspecified, then 4-bit mode is assumed.
In light of Pierre's comment that 4-bit is mandatory and this is a
deviation, perhaps it would be better to define an empty property to
indicate that only 1-bit transfers work. Maybe something along the
lines of "sdhc-1-bit-only"?
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH RFC] powerpc: perf_counter: Enable use of software counters on 32-bit powerpc
From: Paul Mackerras @ 2009-06-13 12:30 UTC (permalink / raw)
To: benh, linuxppc-dev; +Cc: Ingo Molnar, Peter Zijlstra, linux-kernel
This enables the perf_counter subsystem on 32-bit powerpc. Since we
don't have any support for hardware counters on 32-bit powerpc yet,
only software counters can be used.
Besides selecting HAVE_PERF_COUNTERS for 32-bit powerpc as well as
64-bit, the main thing this does is add an implementation of
set_perf_counter_pending(). This needs to arrange for
perf_counter_do_pending() to be called when interrupts are enabled.
Rather than add code to local_irq_restore as 64-bit does, the 32-bit
set_perf_counter_pending() generates an interrupt by setting the
decrementer to 1 so that a decrementer interrupt will become pending
in 1 or 2 timebase ticks (if a decrementer interrupt isn't already
pending). When interrupts are enabled, timer_interrupt() will be
called, and some new code in there calls perf_counter_do_pending().
We use a per-cpu array of flags to indicate whether we need to call
perf_counter_do_pending() or not.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
This patch depends on my 2 patches that provide an atomic64_t
implementation on 32-bit powerpc.
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/hw_irq.h | 5 ++++-
arch/powerpc/include/asm/perf_counter.h | 8 ++++++++
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/time.c | 25 +++++++++++++++++++++++++
arch/powerpc/platforms/Kconfig.cputype | 1 -
6 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3f0a983..c531abc 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -126,6 +126,7 @@ config PPC
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS if PPC64
select GENERIC_ATOMIC64 if PPC32
+ select HAVE_PERF_COUNTERS
config EARLY_PRINTK
bool
diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index b7f8f4a..5b7ebf9 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -131,6 +131,8 @@ static inline int irqs_disabled_flags(unsigned long flags)
struct irq_chip;
#ifdef CONFIG_PERF_COUNTERS
+
+#ifdef CONFIG_PPC64
static inline unsigned long test_perf_counter_pending(void)
{
unsigned long x;
@@ -154,8 +156,9 @@ static inline void clear_perf_counter_pending(void)
"r" (0),
"i" (offsetof(struct paca_struct, perf_counter_pending)));
}
+#endif /* CONFIG_PPC64 */
-#else
+#else /* CONFIG_PERF_COUNTERS */
static inline unsigned long test_perf_counter_pending(void)
{
diff --git a/arch/powerpc/include/asm/perf_counter.h b/arch/powerpc/include/asm/perf_counter.h
index cc7c887..df6c1fe 100644
--- a/arch/powerpc/include/asm/perf_counter.h
+++ b/arch/powerpc/include/asm/perf_counter.h
@@ -9,6 +9,7 @@
* 2 of the License, or (at your option) any later version.
*/
#include <linux/types.h>
+#include <linux/percpu.h>
#define MAX_HWCOUNTERS 8
#define MAX_EVENT_ALTERNATIVES 8
@@ -53,12 +54,19 @@ extern struct power_pmu *ppmu;
#define PPMU_LIMITED_PMC_REQD 2 /* have to put this on a limited PMC */
#define PPMU_ONLY_COUNT_RUN 4 /* only counting in run state */
+#ifdef CONFIG_PPC64
struct pt_regs;
extern unsigned long perf_misc_flags(struct pt_regs *regs);
#define perf_misc_flags(regs) perf_misc_flags(regs)
+#endif /* CONFIG_PPC64 */
extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
+#ifdef CONFIG_PPC32
+DECLARE_PER_CPU(u8, perf_counter_pending);
+extern void set_perf_counter_pending(void);
+#endif
+
/*
* The power_pmu.get_constraint function returns a 64-bit value and
* a 64-bit mask that express the constraints between this event and
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index a2c6834..26db8ae 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -94,7 +94,7 @@ obj64-$(CONFIG_AUDIT) += compat_audit.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
-obj-$(CONFIG_PERF_COUNTERS) += perf_counter.o power4-pmu.o ppc970-pmu.o \
+obj64-$(CONFIG_PERF_COUNTERS) += perf_counter.o power4-pmu.o ppc970-pmu.o \
power5-pmu.o power5+-pmu.o power6-pmu.o \
power7-pmu.o
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 48571ac..f9b718c 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -52,6 +52,7 @@
#include <linux/jiffies.h>
#include <linux/posix-timers.h>
#include <linux/irq.h>
+#include <linux/perf_counter.h>
#include <asm/io.h>
#include <asm/processor.h>
@@ -524,6 +525,26 @@ void __init iSeries_time_init_early(void)
}
#endif /* CONFIG_PPC_ISERIES */
+#if defined(CONFIG_PERF_COUNTERS) && defined(CONFIG_PPC32)
+DEFINE_PER_CPU(u8, perf_counter_pending);
+
+extern void set_perf_counter_pending(void)
+{
+ get_cpu_var(perf_counter_pending) = 1;
+ set_dec(1);
+ put_cpu_var(perf_counter_pending);
+}
+
+#define test_perf_counter_pending() __get_cpu_var(perf_counter_pending)
+#define clear_perf_counter_pending() __get_cpu_var(perf_counter_pending) = 0
+
+#else /* CONFIG_PERF_COUNTERS && CONFIG_PPC32 */
+
+#define test_perf_counter_pending() 0
+#define clear_perf_counter_pending()
+
+#endif /* CONFIG_PERF_COUNTERS && CONFIG_PPC32 */
+
/*
* For iSeries shared processors, we have to let the hypervisor
* set the hardware decrementer. We set a virtual decrementer
@@ -550,6 +571,10 @@ void timer_interrupt(struct pt_regs * regs)
set_dec(DECREMENTER_MAX);
#ifdef CONFIG_PPC32
+ if (test_perf_counter_pending()) {
+ clear_perf_counter_pending();
+ perf_counter_do_pending();
+ }
if (atomic_read(&ppc_n_lost_interrupts) != 0)
do_IRQ(regs);
#endif
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 732ee93..9da795e 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -1,7 +1,6 @@
config PPC64
bool "64-bit kernel"
default n
- select HAVE_PERF_COUNTERS
help
This option selects whether a 32-bit or a 64-bit kernel
will be built.
^ permalink raw reply related
* Re: [PATCH] sdhci: Add support for hosts that are only capable of 1-bit transfers
From: Pierre Ossman @ 2009-06-13 11:05 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, devicetree-discuss, sdhci-devel
In-Reply-To: <20090611201545.GA15942@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
On Fri, 12 Jun 2009 00:15:45 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> Some hosts (hardware configurations, or particular SD/MMC slots) may
> not support 4-bit bus. For example, on MPC8569E-MDS boards we can
> switch between serial (1-bit only) and nibble (4-bit) modes, thought
> we have to disable more peripherals to work in 4-bit mode.
>
> Along with some small core changes, this patch modifies sdhci-of
> driver, so that now it looks for "mode" property in the device-tree.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> Pierre, I'm not sure if a quirk would be appropriate here. If so,
> I can redo the patch with FORCE_1_BIT_DATA quirk.
>
I'd prefer a quirk, yes. 4-bit support is mandated so this would be a
deviation from the spec and such should always be handled by quirks for
clarity.
(I do think it is silly that they made it mandatory though considering
the embedded market)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Paul Mackerras @ 2009-06-13 7:10 UTC (permalink / raw)
To: benh, torvalds, akpm, linuxppc-dev, linux-kernel
Many processor architectures have no 64-bit atomic instructions, but
we need atomic64_t in order to support the perf_counter subsystem.
This adds an implementation of 64-bit atomic operations using hashed
spinlocks to provide atomicity. For each atomic operation, the address=
of the atomic64_t variable is hashed to an index into an array of 16
spinlocks. That spinlock is taken (with interrupts disabled) around th=
e
operation, which can then be coded non-atomically within the lock.
On UP, all the spinlock manipulation goes away and we simply disable
interrupts around each operation. In fact gcc eliminates the whole
atomic64_lock variable as well.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Linus, Andrew: OK if this goes in via the powerpc tree?
include/asm-generic/atomic64.h | 42 ++++++++++
lib/Kconfig | 6 ++
lib/Makefile | 2 +
lib/atomic64.c | 175 ++++++++++++++++++++++++++++++++=
++++++++
4 files changed, 225 insertions(+), 0 deletions(-)
create mode 100644 include/asm-generic/atomic64.h
create mode 100644 lib/atomic64.c
diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomi=
c64.h
new file mode 100644
index 0000000..b18ce4f
--- /dev/null
+++ b/include/asm-generic/atomic64.h
@@ -0,0 +1,42 @@
+/*
+ * Generic implementation of 64-bit atomics using spinlocks,
+ * useful on processors that don't have 64-bit atomic instructions.
+ *
+ * Copyright =A9 2009 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#ifndef _ASM_GENERIC_ATOMIC64_H
+#define _ASM_GENERIC_ATOMIC64_H
+
+typedef struct {
+=09long long counter;
+} atomic64_t;
+
+#define ATOMIC64_INIT(i)=09{ (i) }
+
+extern long long atomic64_read(const atomic64_t *v);
+extern void=09 atomic64_set(atomic64_t *v, long long i);
+extern void=09 atomic64_add(long long a, atomic64_t *v);
+extern long long atomic64_add_return(long long a, atomic64_t *v);
+extern void=09 atomic64_sub(long long a, atomic64_t *v);
+extern long long atomic64_sub_return(long long a, atomic64_t *v);
+extern long long atomic64_dec_if_positive(atomic64_t *v);
+extern long long atomic64_cmpxchg(atomic64_t *v, long long o, long lon=
g n);
+extern long long atomic64_xchg(atomic64_t *v, long long new);
+extern int=09 atomic64_add_unless(atomic64_t *v, long long a, long lon=
g u);
+
+#define atomic64_add_negative(a, v)=09(atomic64_add_return((a), (v)) <=
0)
+#define atomic64_inc(v)=09=09=09atomic64_add(1LL, (v))
+#define atomic64_inc_return(v)=09=09atomic64_add_return(1LL, (v))
+#define atomic64_inc_and_test(v) =09(atomic64_inc_return(v) =3D=3D 0)
+#define atomic64_sub_and_test(a, v)=09(atomic64_sub_return((a), (v)) =3D=
=3D 0)
+#define atomic64_dec(v)=09=09=09atomic64_sub(1LL, (v))
+#define atomic64_dec_return(v)=09=09atomic64_sub_return(1LL, (v))
+#define atomic64_dec_and_test(v)=09(atomic64_dec_return((v)) =3D=3D 0)=
+#define atomic64_inc_not_zero(v) =09atomic64_add_unless((v), 1LL, 0LL)=
+
+#endif /* _ASM_GENERIC_ATOMIC64_H */
diff --git a/lib/Kconfig b/lib/Kconfig
index 9960be0..bb1326d 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -194,4 +194,10 @@ config DISABLE_OBSOLETE_CPUMASK_FUNCTIONS
config NLATTR
=09bool
=20
+#
+# Generic 64-bit atomic support is selected if needed
+#
+config GENERIC_ATOMIC64
+ bool
+
endmenu
diff --git a/lib/Makefile b/lib/Makefile
index 34c5c0e..8e9bcf9 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -95,6 +95,8 @@ obj-$(CONFIG_DMA_API_DEBUG) +=3D dma-debug.o
=20
obj-$(CONFIG_GENERIC_CSUM) +=3D checksum.o
=20
+obj-$(CONFIG_GENERIC_ATOMIC64) +=3D atomic64.o
+
hostprogs-y=09:=3D gen_crc32table
clean-files=09:=3D crc32table.h
=20
diff --git a/lib/atomic64.c b/lib/atomic64.c
new file mode 100644
index 0000000..c5e7255
--- /dev/null
+++ b/lib/atomic64.c
@@ -0,0 +1,175 @@
+/*
+ * Generic implementation of 64-bit atomics using spinlocks,
+ * useful on processors that don't have 64-bit atomic instructions.
+ *
+ * Copyright =A9 2009 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <linux/types.h>
+#include <linux/cache.h>
+#include <linux/spinlock.h>
+#include <linux/init.h>
+#include <asm/atomic.h>
+
+/*
+ * We use a hashed array of spinlocks to provide exclusive access
+ * to each atomic64_t variable. Since this is expected to used on
+ * systems with small numbers of CPUs (<=3D 4 or so), we use a
+ * relatively small array of 16 spinlocks to avoid wasting too much
+ * memory on the spinlock array.
+ */
+#define NR_LOCKS=0916
+
+/*
+ * Ensure each lock is in a separate cacheline.
+ */
+static union {
+=09spinlock_t lock;
+=09char pad[L1_CACHE_BYTES];
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+
+static inline spinlock_t *lock_addr(const atomic64_t *v)
+{
+=09unsigned long addr =3D (unsigned long) v;
+
+=09addr >>=3D L1_CACHE_SHIFT;
+=09addr ^=3D (addr >> 8) ^ (addr >> 16);
+=09return &atomic64_lock[addr & (NR_LOCKS - 1)].lock;
+}
+
+long long atomic64_read(const atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+void atomic64_set(atomic64_t *v, long long i)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter =3D i;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+void atomic64_add(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter +=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+long long atomic64_add_return(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter +=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+void atomic64_sub(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter -=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+long long atomic64_sub_return(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter -=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_dec_if_positive(atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter - 1;
+=09if (val >=3D 0)
+=09=09v->counter =3D val;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_cmpxchg(atomic64_t *v, long long o, long long n)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09if (val =3D=3D o)
+=09=09v->counter =3D n;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_xchg(atomic64_t *v, long long new)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09v->counter =3D new;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+int atomic64_add_unless(atomic64_t *v, long long a, long long u)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09int ret =3D 1;
+
+=09spin_lock_irqsave(lock, flags);
+=09if (v->counter !=3D u) {
+=09=09v->counter +=3D a;
+=09=09ret =3D 0;
+=09}
+=09spin_unlock_irqrestore(lock, flags);
+=09return ret;
+}
+
+static int init_atomic64_lock(void)
+{
+=09int i;
+
+=09for (i =3D 0; i < NR_LOCKS; ++i)
+=09=09spin_lock_init(&atomic64_lock[i].lock);
+=09return 0;
+}
+
+pure_initcall(init_atomic64_lock);
--=20
1.6.0.4
^ permalink raw reply related
* [PATCH 2/2] powerpc: Use generic atomic64_t implementation on 32-bit processors
From: Paul Mackerras @ 2009-06-13 7:10 UTC (permalink / raw)
To: benh, torvalds, akpm, linuxppc-dev, linux-kernel
>From 02fccb02e29bc24e84a5b2ea6ea5d63779247408 Mon Sep 17 00:00:00 2001
From: Paul Mackerras <paulus@samba.org>
Date: Sat, 13 Jun 2009 16:24:03 +1000
Subject:
This makes 32-bit powerpc use the generic atomic64_t implementation.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/atomic.h | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index cdc9a6f..3f0a983 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -125,6 +125,7 @@ config PPC
select USE_GENERIC_SMP_HELPERS if SMP
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS if PPC64
+ select GENERIC_ATOMIC64 if PPC32
config EARLY_PRINTK
bool
diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
index b7d2d07..4012483 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -470,6 +470,9 @@ static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#else /* __powerpc64__ */
+#include <asm-generic/atomic64.h>
+
#endif /* __powerpc64__ */
#include <asm-generic/atomic-long.h>
--
1.6.0.4
^ permalink raw reply related
* Re: linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-06-13 5:06 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, ppc-dev, linux-kernel, linux-next, paulus, Linus
In-Reply-To: <20090612141118.GK32105@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
Hi Ingo,
On Fri, 12 Jun 2009 16:11:18 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> But that's axiomatic, isnt it? linux-next build-tests PowerPC as the
> first in the row of tests - so no change that was in linux-next can
> ever cause a build failure on PowerPC, right?
Not really. I build a powerpc ppc64_defconfig and an x86_64 allmodconfig
between merging most trees. At the end of the day, I do the following
builds before releasing linux-next:
powerpc allnoconfig
powerpc64 allnoconfig
powerpc ppc44x_defconfig
powerpc allyesconfig
i386 defconfig
sparc64 defconfig
sparc defconfig
Which clearly doesn't cover all possible configs, but is a start and
catches a lot (the powerpc allyesconfig is only 64 bit).
Then after release, linux-next gets built for a lot of architectures and
configs (see http://kisskb.ellerman.id.au/kisskb/branch/9/). A couple of
people also do randconfig builds which find all sorts of things.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-06-13 4:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, ppc-dev, linux-kernel, linux-next, paulus, Linus
In-Reply-To: <20090612134428.GC32105@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
Hi Ingo,
On Fri, 12 Jun 2009 15:44:28 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> In terms of test coverage, at least for our trees, less than 1% of
> the bugs we handle get reported in a linux-next context - and most
> of the bugs that get reported (against say the scheduler tree) are
> related to rare architectures.
I expect that most bugs get reported and fixed before code gets to
linux-next (in fact one of the prerequisites for being in linux-next is
that code has been tested as well as possible).
> In fact, i checked, there were _zero_ x86 bugs reported against
> linux-next and solved against it between v2.6.30-rc1 and v2.6.30:
>
> git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/
>
> Doing it over the full cycle shows one commit altogether - a Xen
> build failure. In fact, i just checked the whole stabilization cycle
> for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were
> only 5 linux-next originated patches, most of them build failures.
Nice set of figures. For some other context, between April 6 and June 9
(2.6.30-rc1 to 2.6.30) I sent 50 emails with subjects like "linux-next:
xxx tree build failure". What results from those emails? I sometimes
don't even hear back. Almost all of the failures get fixed.
A lot of these probably also get discovered independently. I don't
really care as long as they do get fixed.
One of those failures was a sparc build failure due to a change in the
tip-core tree (see commit d2de688891909b148efe83a6fc9520a9cd6015f0).
Another report produced commit 27b19565fe4ca5b0e9d2ae98ce4b81ca728bf445.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.31] ehca: Tolerate dynamic memory operations and huge pages
From: Roland Dreier @ 2009-06-13 4:50 UTC (permalink / raw)
To: Hannes Hering; +Cc: alexs, linux-kernel, ewg, linuxppc-dev, raisch, ossrosch
In-Reply-To: <200906091559.24661.hannes.hering@linux.vnet.ibm.com>
OK, one major issue with this patch and a few minor nits.
First, the major issue is that I don't see anything in the patch that
changes the code in ehca_mem_notifier() in ehca_main.c:
case MEM_GOING_ONLINE:
case MEM_GOING_OFFLINE:
/* only ok if no hca is attached to the lpar */
spin_lock_irqsave(&shca_list_lock, flags);
if (list_empty(&shca_list)) {
spin_unlock_irqrestore(&shca_list_lock, flags);
return NOTIFY_OK;
} else {
spin_unlock_irqrestore(&shca_list_lock, flags);
if (printk_timed_ratelimit(&ehca_dmem_warn_time,
30 * 1000))
ehca_gen_err("DMEM operations are not allowed"
"in conjunction with eHCA");
return NOTIFY_BAD;
}
But your patch description says:
> This patch implements toleration of dynamic memory operations....
But it seems you're still going to hit the same NOTIFY_BAD case above
after your patch. So something doesn't compute for me. Could you
explain more?
Second, a nit:
> +#define EHCA_REG_MR 0
> +#define EHCA_REG_BUSMAP_MR (~0)
and you pass these as the reg_busmap parm in:
> int ehca_reg_mr(struct ehca_shca *shca,
> struct ehca_mr *e_mr,
> u64 *iova_start,
> @@ -991,7 +1031,8 @@
> struct ehca_pd *e_pd,
> struct ehca_mr_pginfo *pginfo,
> u32 *lkey, /*OUT*/
> - u32 *rkey) /*OUT*/
> + u32 *rkey, /*OUT*/
> + int reg_busmap)
and test it as:
> + if (reg_busmap)
> + ret = ehca_reg_bmap_mr_rpages(shca, e_mr, pginfo);
> + else
> + ret = ehca_reg_mr_rpages(shca, e_mr, pginfo);
So the ~0 for true looks a bit odd. One option would be to make
reg_busmap a bool, since that's how you're using it, but then you lose
the nice self-documenting macro where you call things.
So I think it would be cleaner to do something like
enum ehca_reg_type {
EHCA_REG_MR,
EHCA_REG_BUSMAP_MR
};
and make the "int reg_busmap" parameter into "enum ehca_reg_type reg_type"
and have the code become
+ if (reg_type == EHCA_REG_BUSMAP_MR)
+ ret = ehca_reg_bmap_mr_rpages(shca, e_mr, pginfo);
+ else if (reg_type == EHCA_REG_MR)
+ ret = ehca_reg_mr_rpages(shca, e_mr, pginfo);
+ else
+ ret = -EINVAL
or something like that.
> +struct ib_dma_mapping_ops ehca_dma_mapping_ops = {
> + .mapping_error = ehca_dma_mapping_error,
> + .map_single = ehca_dma_map_single,
> + .unmap_single = ehca_dma_unmap_single,
> + .map_page = ehca_dma_map_page,
> + .unmap_page = ehca_dma_unmap_page,
> + .map_sg = ehca_dma_map_sg,
> + .unmap_sg = ehca_dma_unmap_sg,
> + .dma_address = ehca_dma_address,
> + .dma_len = ehca_dma_len,
> + .sync_single_for_cpu = ehca_dma_sync_single_for_cpu,
> + .sync_single_for_device = ehca_dma_sync_single_for_device,
> + .alloc_coherent = ehca_dma_alloc_coherent,
> + .free_coherent = ehca_dma_free_coherent,
> +};
I always think structures like this are easier to read if you align the
'=' signs. But no big deal.
> + ret = ehca_create_busmap();
> + if (ret) {
> + ehca_gen_err("Cannot create busmap.");
> + goto module_init2;
> + }
> +
> ret = ibmebus_register_driver(&ehca_driver);
> if (ret) {
> ehca_gen_err("Cannot register eHCA device driver");
> ret = -EINVAL;
> - goto module_init2;
> + goto module_init3;
> }
>
> ret = register_memory_notifier(&ehca_mem_nb);
> if (ret) {
> ehca_gen_err("Failed registering memory add/remove notifier");
> - goto module_init3;
> + goto module_init4;
Having to renumber unrelated things is when something changes is why I
don't like this style of error path labels. But I think it's well and
truly too late to fix that in ehca.
- R.
^ permalink raw reply
* build failure in PPC mpc5200_psc_ac97
From: Jon Smirl @ 2009-06-12 23:25 UTC (permalink / raw)
To: linuxppc-dev, lkml
The new driver for AC97 on the mpc5200 has landed in front of Timur's
patch implementing spin_event_timeout(). Timur's patch is in
powerpc-next which hasn't been merged yet. mpc5200_psc_ac97 will build
ok after this merge happens.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] net/fs_enet: Allow use_rmii to be set in OF
From: Ken MacLeod @ 2009-06-12 21:34 UTC (permalink / raw)
To: linuxppc-dev
Allow use_rmii in fs_platform_info to be set in the OF device tree
using phy-mode="rmii".
Signed-off-by: Ken MacLeod <ken@bitsko.slc.ut.us>
---
drivers/net/fs_enet/fs_enet-main.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index a9cbc31..57879be 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1043,6 +1043,7 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
struct fs_platform_info *fpi;
const u32 *data;
const u8 *mac_addr;
+ const char *str;
int privsize, len, ret = -ENODEV;
fpi = kzalloc(sizeof(*fpi), GFP_KERNEL);
@@ -1057,6 +1058,10 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
fpi->cp_command = *data;
}
+ str = of_get_property(ofdev->node, "phy-mode", &len);
+ if (str != NULL && !strcasecmp(str, "rmii"))
+ fpi->use_rmii = 1;
+
fpi->rx_ring = 32;
fpi->tx_ring = 32;
fpi->rx_copybreak = 240;
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Kumar Gala @ 2009-06-12 18:01 UTC (permalink / raw)
To: Dan Williams
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Li Yang,
Timur Tabi
In-Reply-To: <4A329278.3010607@intel.com>
On Jun 12, 2009, at 12:38 PM, Dan Williams wrote:
> Kumar Gala wrote:
>> On Jun 12, 2009, at 4:23 AM, Li Yang wrote:
>>> On Thu, Jun 11, 2009 at 11:17 PM, Ira
>>> Snyder<iws@ovro.caltech.edu> wrote:
>>>> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>>>>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>>>>>
>>>>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>
>>>>>> wrote:
>>>>>>> Adding Kumar to the CC: list, since he might pick up the patch.
>>>>>>>
>>>>>> Acked-by: Dan Williams <dan.j.williams@intel.com>
>>>>>>
>>>>>> I agree with taking this through Kumar's tree.
>>>>> I'm going through patches for .31.. Should I still pick this
>>>>> up? Going
>>>>> forward should I pick up fsldma patches?
>>>>>
>>>> I'm fine with that, but you should probably talk to Li Yang
>>>> (added to
>>>> CC). He's gotten in contact with me a few times recently.
>>> I am fine with both ways for this patch as it is only related to
>>> Freescale register details. But in general I think patches should
>>> go
>>> through functional subsystem, as they usually would need insight of
>>> the subsystem architecture. I prefer the way that the patch acked
>>> or
>>> signed-off by Freescale guys and push upstream through Dan's tree as
>>> most other subsystems did. Unless Dan prefers to ack the subsystem
>>> architectural part of each patch and have them pushed other way.
>> I agree w/this and just wanting to see what Dan's preference is.
>
> I'll take fsldma patches through the dmaengine tree with Leo's ack/
> sign-off. That last request was a one-off because I had nothing
> else to push and the discussion was very architecture specific.
Sounds good to me. I expect you to pick up this patch for .31
- k
^ permalink raw reply
* [PATCH] fbdev/xilinxfb: Fix improper casting and tighen up probe path
From: Grant Likely @ 2009-06-12 17:57 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, benh, john.linn
From: Grant Likely <grant.likely@secretlab.ca>
The xilinxfb driver is improperly casting a physical address to a
u32, and the probe routine isn't as straight forward as it could be.
(discovered by gcc spitting out warnings on most recent change to
xilinxfb driver).
This patch fixes the cast and simplifies the probe path.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
John, can you please test and verify this fix is correct?
Thanks,
g.
drivers/video/xilinxfb.c | 59 ++++++++++++++++++----------------------------
1 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 7a868bd..b68b331 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -124,7 +124,6 @@ struct xilinxfb_drvdata {
registers */
dcr_host_t dcr_host;
- unsigned int dcr_start;
unsigned int dcr_len;
void *fb_virt; /* virt. address of the frame buffer */
@@ -325,8 +324,8 @@ static int xilinxfb_assign(struct device *dev,
drvdata->regs);
}
/* Put a banner in the log (for DEBUG) */
- dev_dbg(dev, "fb: phys=%p, virt=%p, size=%x\n",
- (void *)drvdata->fb_phys, drvdata->fb_virt, fbsize);
+ dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
+ (unsigned long long)drvdata->fb_phys, drvdata->fb_virt, fbsize);
return 0; /* success */
@@ -404,9 +403,7 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
u32 tft_access;
struct xilinxfb_platform_data pdata;
struct resource res;
- int size, rc;
- int start = 0, len = 0;
- dcr_host_t dcr_host;
+ int size, rc, start;
struct xilinxfb_drvdata *drvdata;
/* Copy with the default pdata (not a ptr reference!) */
@@ -414,35 +411,39 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
dev_dbg(&op->dev, "xilinxfb_of_probe(%p, %p)\n", op, match);
+ /* Allocate the driver data region */
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ dev_err(&op->dev, "Couldn't allocate device private record\n");
+ return -ENOMEM;
+ }
+
/*
* To check whether the core is connected directly to DCR or PLB
* interface and initialize the tft_access accordingly.
*/
p = (u32 *)of_get_property(op->node, "xlnx,dcr-splb-slave-if", NULL);
-
- if (p)
- tft_access = *p;
- else
- tft_access = 0; /* For backward compatibility */
+ tft_access = p ? *p : 0;
/*
* Fill the resource structure if its direct PLB interface
* otherwise fill the dcr_host structure.
*/
if (tft_access) {
+ drvdata->flags |= PLB_ACCESS_FLAG;
rc = of_address_to_resource(op->node, 0, &res);
if (rc) {
dev_err(&op->dev, "invalid address\n");
- return -ENODEV;
+ goto err;
}
-
} else {
+ res.start = 0;
start = dcr_resource_start(op->node, 0);
- len = dcr_resource_len(op->node, 0);
- dcr_host = dcr_map(op->node, start, len);
- if (!DCR_MAP_OK(dcr_host)) {
- dev_err(&op->dev, "invalid address\n");
- return -ENODEV;
+ drvdata->dcr_len = dcr_resource_len(op->node, 0);
+ drvdata->dcr_host = dcr_map(op->node, start, drvdata->len);
+ if (!DCR_MAP_OK(drvdata->dcr_host)) {
+ dev_err(&op->dev, "invalid DCR address\n");
+ goto err;
}
}
@@ -467,26 +468,12 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
if (of_find_property(op->node, "rotate-display", NULL))
pdata.rotate_screen = 1;
- /* Allocate the driver data region */
- drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata) {
- dev_err(&op->dev, "Couldn't allocate device private record\n");
- return -ENOMEM;
- }
dev_set_drvdata(&op->dev, drvdata);
+ return xilinxfb_assign(&op->dev, drvdata, res.start, &pdata);
- if (tft_access)
- drvdata->flags |= PLB_ACCESS_FLAG;
-
- /* Arguments are passed based on the interface */
- if (drvdata->flags & PLB_ACCESS_FLAG) {
- return xilinxfb_assign(&op->dev, drvdata, res.start, &pdata);
- } else {
- drvdata->dcr_start = start;
- drvdata->dcr_len = len;
- drvdata->dcr_host = dcr_host;
- return xilinxfb_assign(&op->dev, drvdata, 0, &pdata);
- }
+ err:
+ kfree(drvdata);
+ return -ENODEV;
}
static int __devexit xilinxfb_of_remove(struct of_device *op)
^ permalink raw reply related
* Re: [PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
From: Kyle McMartin @ 2009-06-12 17:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <55D4E406-B6C5-471F-B7FF-86106CCC0ABF@kernel.crashing.org>
On Fri, Jun 12, 2009 at 09:04:52AM -0500, Kumar Gala wrote:
>> On UP, all the spinlock manipulation goes away and we simply disable
>> interrupts around each operation. In fact gcc eliminates the whole
>> atomic64_lock variable as well.
>>
>> Signed-off-by: Paul Mackerras <paulus@samba.org>
>> ---
>> Compile-tested only at this stage, which is why it's [RFC].
>
> any reason not to make this lib/asm generic? Seems like it isn't ppc
> specific.
>
Indeed... PA-RISC uses these for all atomics, since we have no useful
atomic insns to implement them... I'd be happy to submit a cleanup after
you merge this, if you don't have time to ahead of time.
regards, Kyle
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Dan Williams @ 2009-06-12 17:38 UTC (permalink / raw)
To: Kumar Gala
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Li Yang,
Timur Tabi
In-Reply-To: <24633D89-D4EC-4C27-8B7F-3992EFE50989@kernel.crashing.org>
Kumar Gala wrote:
> On Jun 12, 2009, at 4:23 AM, Li Yang wrote:
>
>> On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu>
>> wrote:
>>> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>>>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>>>>
>>>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>
>>>>> wrote:
>>>>>> Adding Kumar to the CC: list, since he might pick up the patch.
>>>>>>
>>>>> Acked-by: Dan Williams <dan.j.williams@intel.com>
>>>>>
>>>>> I agree with taking this through Kumar's tree.
>>>> I'm going through patches for .31.. Should I still pick this up?
>>>> Going
>>>> forward should I pick up fsldma patches?
>>>>
>>> I'm fine with that, but you should probably talk to Li Yang (added to
>>> CC). He's gotten in contact with me a few times recently.
>> I am fine with both ways for this patch as it is only related to
>> Freescale register details. But in general I think patches should go
>> through functional subsystem, as they usually would need insight of
>> the subsystem architecture. I prefer the way that the patch acked or
>> signed-off by Freescale guys and push upstream through Dan's tree as
>> most other subsystems did. Unless Dan prefers to ack the subsystem
>> architectural part of each patch and have them pushed other way.
>
> I agree w/this and just wanting to see what Dan's preference is.
I'll take fsldma patches through the dmaengine tree with Leo's
ack/sign-off. That last request was a one-off because I had nothing
else to push and the discussion was very architecture specific.
Thanks,
Dan
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Kumar Gala @ 2009-06-12 15:03 UTC (permalink / raw)
To: Li Yang
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238, linux-kernel,
linuxppc-dev, Dan Williams, Timur Tabi
In-Reply-To: <2a27d3730906120223w9f30b7ewfd22eb328e3a23d3@mail.gmail.com>
On Jun 12, 2009, at 4:23 AM, Li Yang wrote:
> On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu>
> wrote:
>> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>>>
>>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>>>
>>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>
>>>> wrote:
>>>>> Adding Kumar to the CC: list, since he might pick up the patch.
>>>>>
>>>>
>>>> Acked-by: Dan Williams <dan.j.williams@intel.com>
>>>>
>>>> I agree with taking this through Kumar's tree.
>>>
>>> I'm going through patches for .31.. Should I still pick this up?
>>> Going
>>> forward should I pick up fsldma patches?
>>>
>>
>> I'm fine with that, but you should probably talk to Li Yang (added to
>> CC). He's gotten in contact with me a few times recently.
>
> I am fine with both ways for this patch as it is only related to
> Freescale register details. But in general I think patches should go
> through functional subsystem, as they usually would need insight of
> the subsystem architecture. I prefer the way that the patch acked or
> signed-off by Freescale guys and push upstream through Dan's tree as
> most other subsystems did. Unless Dan prefers to ack the subsystem
> architectural part of each patch and have them pushed other way.
I agree w/this and just wanting to see what Dan's preference is.
- k
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 14:23 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612141118.GK32105@elte.hu>
On Fri, 2009-06-12 at 16:11 +0200, Ingo Molnar wrote:
> > Maybe. But maybe it's representative... so far in this merge
> > window, 100% of the powerpc build and runtime breakage upstream
> > comes from stuff that didn't get into -next before.
>
> But that's axiomatic, isnt it? linux-next build-tests PowerPC as the
> first in the row of tests - so no change that was in linux-next can
> ever cause a build failure on PowerPC, right?
I'd have to check with Stephen but I think linux-next tests a whole
bunch of archs each round. Anyway, the idea is, just don't get things
upstream before the at least had a chance to go through that little bit
of integration testing .. Is it -that- hard ?
Oh and before you ask me, yes, I do the same mistakes, and I have been
caught too merging things at the last minute that ended up broken and
that could have been caught by -next... I'm just trying to advocate the
idea that we all try to improve in that area :-)
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 14:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612140730.GJ32105@elte.hu>
> Uhm, the bug you are making a big deal of would have been found and
> fixed by Paulus a few hours after any such mail - and probably by me
> too as i do daily cross builds to Power.
>
> So yes, we had a bug, but any extra linux-next hoops would not have
> prevented it: i could still have messed up by getting lured by that
> nice piece of Power7 hardware enablement patch on the last day ;-)
>
> So the bug was my fault for being too fast-and-loose with that
> particular patch, creating a ~5-commits-hop build breakage bisection
> window on Power.
>
> Now that i'm sufficiently chastised, can we now move on please? :)
Sure we can :-) My point is, get a break before you merge upstream :-)
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 14:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244815574.7172.171.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> > >
> > > > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > > > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > > > or nack so that we can get a chance to do that final pass of ironing out
> > > > the mechanical bugs before we hit the main tree.
> > >
> > > Let me add a little bit more background to my reasoning here and why I
> > > think having this integration testing step is so valuable...
> > >
> > > It all boils down to bisection and having a bisectable tree.
> >
> > I think you are way too concentrated on this particular incident,
> > and you are generalizing it into something that is not so in
> > practice.
>
> Maybe. But maybe it's representative... so far in this merge
> window, 100% of the powerpc build and runtime breakage upstream
> comes from stuff that didn't get into -next before.
But that's axiomatic, isnt it? linux-next build-tests PowerPC as the
first in the row of tests - so no change that was in linux-next can
ever cause a build failure on PowerPC, right?
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 14:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244814976.7172.164.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
>
> > This is certainly doable for agreeable features - which is the bulk
> > - and it is being done.
> >
> > But this is a catch-22 for _controversial_ new features - which
> > perfcounters clearly was, in case you turned off your lkml
> > subscription ;-)
>
> I didn't :-) My point here is that Linus can make a decision with
> an email -before- merging so that -next gets a chance, at least
> for a couple of days, to do the integration testing once the
> controversy has been sorted by his highness.
Uhm, the bug you are making a big deal of would have been found and
fixed by Paulus a few hours after any such mail - and probably by me
too as i do daily cross builds to Power.
So yes, we had a bug, but any extra linux-next hoops would not have
prevented it: i could still have messed up by getting lured by that
nice piece of Power7 hardware enablement patch on the last day ;-)
So the bug was my fault for being too fast-and-loose with that
particular patch, creating a ~5-commits-hop build breakage bisection
window on Power.
Now that i'm sufficiently chastised, can we now move on please? :)
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 14:06 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612134940.GD32105@elte.hu>
On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> >
> > > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > > or nack so that we can get a chance to do that final pass of ironing out
> > > the mechanical bugs before we hit the main tree.
> >
> > Let me add a little bit more background to my reasoning here and why I
> > think having this integration testing step is so valuable...
> >
> > It all boils down to bisection and having a bisectable tree.
>
> I think you are way too concentrated on this particular incident,
> and you are generalizing it into something that is not so in
> practice.
Maybe. But maybe it's representative... so far in this merge window,
100% of the powerpc build and runtime breakage upstream comes from stuff
that didn't get into -next before.
Some of the runtime breakage in powerpc-next comes from my own bugs,
indeed, and fortunately I caught it before I asked Linus to pull.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
From: Kumar Gala @ 2009-06-12 14:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18994.17381.129339.162342@cargo.ozlabs.ibm.com>
On Jun 12, 2009, at 7:02 AM, Paul Mackerras wrote:
> 32-bit powerpc processors have no 64-bit atomic instructions, but we
> will
> need atomic64_t in order to support the perf_counter subsystem on 32-
> bit
> processors.
>
> This adds an implementation of 64-bit atomic operations using hashed
> spinlocks to provide atomicity. For each atomic operation, the
> address
> of the atomic64_t variable is hashed to an index into an array of 16
> spinlocks. That spinlock is taken (with interrupts disabled) around
> the
> operation, which can then be coded non-atomically within the lock.
>
> On UP, all the spinlock manipulation goes away and we simply disable
> interrupts around each operation. In fact gcc eliminates the whole
> atomic64_lock variable as well.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> Compile-tested only at this stage, which is why it's [RFC].
any reason not to make this lib/asm generic? Seems like it isn't ppc
specific.
- k
^ permalink raw reply
* Re: "next" branch update
From: Benjamin Herrenschmidt @ 2009-06-12 13:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev list
In-Reply-To: <ed82fe3e0906120654m22f38569jea21dfaf9449c34c@mail.gmail.com>
On Fri, 2009-06-12 at 08:54 -0500, Timur Tabi wrote:
> On Fri, Jun 12, 2009 at 2:29 AM, Benjamin
> Herrenschmidt<benh@kernel.crashing.org> wrote:
> > I pushed the following commits, along with merging Linus tree in today.
>
> Is there a reason you keep ignoring my patch?
Other than I hate you ? just kidding :-)
> [PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout()
>
> There is PowerPC code in the ALSA tree that depends on my patch, so
> that code will break if you don't push my patch upstream.
I know, and you may have noticed I haven't sent a pull request to Linus
yet... I was planning on scrubbing patchwork once more today and got
sidetracked with fixing the breakage that went into mainline already
while I was not looking :-)
I haven't closed powerpc-next, I know I'm late, but don't worry, your
patch is on my todo list.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
From: Kumar Gala @ 2009-06-12 13:58 UTC (permalink / raw)
To: Li Yang; +Cc: Zhang Wei, netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <2a27d3730906120627l112030b3wa11ea5aa3fcb1087@mail.gmail.com>
On Jun 12, 2009, at 8:27 AM, Li Yang wrote:
> On Thu, Jun 11, 2009 at 9:32 PM, Kumar
> Gala<galak@kernel.crashing.org> wrote:
>>
>> On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote:
>>
>>>> On May 12, 2009, at 3:35 AM, Li Yang wrote:
>>>>
>>>>> Add the mapping functions used to support direct IO memory
>>>>> access of
>>>>> rapidIO.
>>>>>
>>>>> Signed-off-by: Zhang Wei <zw@zh-kernel.org>
>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>
>>>> Use inbnd/outbnd instead of inb/outb which make one think of
>>>> byte level io accessors.
>>>>
>>>> As I look at this I don't think this is the correct API. I
>>>> think we should be using the DMA mapping API to hide these
>>>> details. The concept of mapping like this seems to be more a
>>>> function of FSL's Address translation/mapping unit (ATMU) than
>>>> anything specific to the RIO bus standard.
>>>
>>> This is a separate RIO block level ATMU. Although it looks like the
>>> system level ATMU, system ATMU doesn't have the knowledge of rapidIO
>>> target device ID. The mapping need to be dynamic, as it's easy to
>>> have
>>> more RIO devices than the outbound windows.
>>
>> I understand that. What I'm saying is the RIO block level ATMU is a
>> Freescale specific detail and not part of any standard RIO bus
>> programming
>> model. We have mapping APIs that we can connect to for this via
>> the DMA API
>> layer.
>
> Ok, I see your point now. Do you mean dma_map_*() for DMA API layer?
> But in my understanding the current dma_map_*() APIs are preparing
> local memory for device to access which is similar to the inbound
> case. Is it suitable to also use them for mapping device's space for
> CPU access? Can you give an example of using this API for Address
> Translation and Mapping purpose?
Yes, I meant the dma_map_*() API. Any system with a true IOMMU uses
the dma_map_ layer as the way to do address translation.
- k
^ 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