* Re: [PATCH RFC] powerpc: perf_counter: Enable use of software counters on 32-bit powerpc
From: Ingo Molnar @ 2009-06-13 21:16 UTC (permalink / raw)
To: Paul Mackerras, Mike Frysinger; +Cc: Peter Zijlstra, linux-kernel, linuxppc-dev
In-Reply-To: <18995.39910.109998.926269@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> +extern void set_perf_counter_pending(void);
btw., Mike Frysinger pointed out that this prototype should be in
include/linux/perf_counter.h, not spread out in every architecture
pointlessly.
Ingo
^ permalink raw reply
* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Ingo Molnar @ 2009-06-13 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: akpm, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <alpine.LFD.2.01.0906131323270.3237@localhost.localdomain>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, 13 Jun 2009, Linus Torvalds wrote:
> >
> > On Sat, 13 Jun 2009, Paul Mackerras wrote:
> > >
> > > Linus, Andrew: OK if this goes in via the powerpc tree?
> >
> > Ok by me.
>
> Btw, do 32-bit architectures really necessarily want 64-bit
> performance counters?
>
> I realize that 32-bit counters will overflow pretty easily, but I
> do wonder about the performance impact of doing things like hashed
> spinlocks for 64-bit counters. Maybe the downsides of 64-bit perf
> counters on such architectures might outweight the upsides?
We account all sorts of non-hw bits via atomic64_t as well - for
example time related counters in nanoseconds - which wrap 32 bits at
4 seconds.
There's also security/stability relevant bits:
counter->id = atomic64_inc_return(&perf_counter_id);
We dont really want that ID to wrap ever - it could create a leaking
of one PMU context into another. (We could rewrite it by putting a
global lock around it, but still - this is a convenient primitive.)
In select places we might be able to reduce the use of atomic64_t
(that might make performance sense anyway) - but to get rid of all
of them would be quite painful. We initially started with a 32-bit
implementation and it was quite painful with fast-paced units.
So since Paul has already coded the wrappers up ... i'd really
prefer that, unless there's really compelling reasons not to do it.
Ingo
^ permalink raw reply
* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Linus Torvalds @ 2009-06-13 20:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linux-kernel, linuxppc-dev
In-Reply-To: <alpine.LFD.2.01.0906131312470.3237@localhost.localdomain>
On Sat, 13 Jun 2009, Linus Torvalds wrote:
>
> On Sat, 13 Jun 2009, Paul Mackerras wrote:
> >
> > Linus, Andrew: OK if this goes in via the powerpc tree?
>
> Ok by me.
Btw, do 32-bit architectures really necessarily want 64-bit performance
counters?
I realize that 32-bit counters will overflow pretty easily, but I do
wonder about the performance impact of doing things like hashed spinlocks
for 64-bit counters. Maybe the downsides of 64-bit perf counters on such
architectures might outweight the upsides?
Linus
^ permalink raw reply
* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Linus Torvalds @ 2009-06-13 20:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linux-kernel, linuxppc-dev
In-Reply-To: <18995.20685.227683.561827@cargo.ozlabs.ibm.com>
On Sat, 13 Jun 2009, Paul Mackerras wrote:
>
> Linus, Andrew: OK if this goes in via the powerpc tree?
Ok by me.
Linus
^ permalink raw reply
* Re: [PATCH] powerpc/mpc52xx/mtd: fix mtd-ram access for 16-bit Local Plus Bus
From: Grant Likely @ 2009-06-13 17:09 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development, devicetree-discuss, dwmw2
In-Reply-To: <1244911551.3423.0@antares>
On Sat, Jun 13, 2009 at 10:45 AM, Albrecht Dre=DF<albrecht.dress@arcor.de> =
wrote:
> Am 11.06.09 18:27 schrieb(en) Grant Likely:
>>>
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *(u16 *)buf =3D *((volatile u16 *)(vdest =
- 1));
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 buf[1] =3D *((u8 *)src);
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *((volatile u16 *)(vdest - 1)) =3D *(u16 =
*)buf;
>>
>> what is the purpose of volatile here? =A0If you need io barriers, then u=
se
>> the in_/out_be16 macros.
>
> Yes, you're right - should be completely superfluous here. =A0A result of=
copy
> & paste without thinking... :-(
>
>> Blech. =A0ugly #ifdef and not really multiplatform safe (yeah, I know it
>> shouldn't break non-5200 platforms, but it does have an undesirable impa=
ct).
>> =A0There's got to be a better way.
>
> Ouch, yes - I completely forgot the possibility of multi-platform builds.
>
> Am 11.06.09 19:28 schrieb(en) Grant Likely:
>>
>> So; the solution to me seems to be on an MPC5200 platform replace the
>> offending hooks with MPC5200 specific variants at runtime.
>
> Will re-work the patch that way! =A0BTW, a dumb question: what is the pro=
per
> way to determine which cpu the system is running on? =A0Check the CPU nod=
e of
> the of tree?
In this case I'd walk up the parent nodes in the tree looking for an
"fsl,mpc5200-lpb" compatible value. That way you only apply the
workaround if the device is on the locaplus bus, and not for example
below the PCI bus.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/mpc52xx/mtd: fix mtd-ram access for 16-bit Local Plus Bus
From: Albrecht Dreß @ 2009-06-13 16:45 UTC (permalink / raw)
To: Grant Likely; +Cc: Linux PPC Development, dwmw2
In-Reply-To: <fa686aa40906110927w60a5a74alaa3420b9bf3f3e44@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
Am 11.06.09 18:27 schrieb(en) Grant Likely:
>> + *(u16 *)buf = *((volatile u16 *)(vdest - 1));
>> + buf[1] = *((u8 *)src);
>> + *((volatile u16 *)(vdest - 1)) = *(u16 *)buf;
>
> what is the purpose of volatile here? If you need io barriers, then
> use the in_/out_be16 macros.
Yes, you're right - should be completely superfluous here. A result of
copy & paste without thinking... :-(
> Blech. ugly #ifdef and not really multiplatform safe (yeah, I know
> it shouldn't break non-5200 platforms, but it does have an
> undesirable impact). There's got to be a better way.
Ouch, yes - I completely forgot the possibility of multi-platform
builds.
Am 11.06.09 19:28 schrieb(en) Grant Likely:
> So; the solution to me seems to be on an MPC5200 platform replace the
> offending hooks with MPC5200 specific variants at runtime.
Will re-work the patch that way! BTW, a dumb question: what is the
proper way to determine which cpu the system is running on? Check the
CPU node of the of tree?
Thanks, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* 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
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