>From 02fccb02e29bc24e84a5b2ea6ea5d63779247408 Mon Sep 17 00:00:00 2001
From: Paul Mackerras
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
---
arch/powerpc/Kconfig |1 +
arch/p
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 var
On Fri, 12 Jun 2009 00:15:45 +0400
Anton Vorontsov 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 per
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
On Thu, Jun 11, 2009 at 2:15 PM, Anton
Vorontsov 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 periphe
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 An
On Sat, Jun 13, 2009 at 9:11 AM, Robert P. J. Day wrote:
>
> arch/powerpc/platforms/512x/Kconfig: select 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 publishe
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_b
On Sat, Jun 13, 2009 at 10:45 AM, Albrecht Dreß wrote:
> 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 p
On Sat, 13 Jun 2009, Paul Mackerras wrote:
>
> Linus, Andrew: OK if this goes in via the powerpc tree?
Ok by me.
Linus
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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 overf
* Linus Torvalds 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
* Paul Mackerras 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
___
Linuxppc-dev m
On Saturday 13 June 2009, Paul Mackerras wrote:
> +extern long long atomic64_read(const atomic64_t *v);
> +extern void atomic64_set(atomic64_t *v, long long i);
> +extern void atomic64_add(long long a, atomic64_t *v);
> +extern long long atomic64_add_return(long long a, atomic64_t *v);
> +e
14 matches
Mail list logo
