On Sunday 22 August 2010, Andreas Schwab wrote:
> The ioctls are actually compatible, but due to historical mistake the
> numbers differ between 32bit and 64bit.
>
> Signed-off-by: Andreas Schwab
Acked-by: Arnd Bergmann
___
Linuxppc-dev mailing list
L
Hi Ben,
The changes from Dave for 47x (with minor fix), and a device tree update
for the 460ex SATA driver that has been merged upstream now. Please
pull.
josh
The following changes since commit
e32e78c5ee8aadef020fbaecbe6fb741ed9029fd:
powerpc: fix build with make 3.82 (2010-08-09 14:14:05
On Thu, Aug 19, 2010 at 01:19:57PM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2010-08-18 at 11:45 -0500, Dave Kleikamp wrote:
>> Sorry! Forgot to change the subject.
>>
>> Shaggy
>>
>> On Wed, 2010-08-18 at 11:44 -0500, Dave Kleikamp wrote:
>> > Josh,
>> > Here are some bug fixes for the powe
On Thursday 19 August 2010, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Thu, 19 Aug 2010 15:23:23 +1000
>
> > Similar here, but using atomic_long_t instead so it works for 32-bit too
> > for me. I suppose we could make that part common indeed.
> >
> > What about asm-generic/rwsem-
On Friday 20 August 2010, Andreas Schwab wrote:
> See arch/powerpc/platforms/cell/spu_callbacks.c.
>
> * 4. They are optional and we can't rely on them being
> *linked into the kernel. Unfortunately, the cond_syscall
> *helper does not work here as it does not add the necessary
> *
MPIC_U3_HT_IRQS is selected both by PPC_PMAC64 and PPC_MAPLE, but depends
on PPC_MAPLE, so a PPC_PMAC64-only config gets this warning:
warning: (PPC_PMAC64 && PPC_PMAC && POWER4 || PPC_MAPLE && PPC64 && PPC_BOOK3S)
selects MPIC_U3_HT_IRQS which has unmet direct dependencies (PPC_MAPLE)
Fix that
>> I already added the following to arch/powerpc/Makefile.
>>
>> # Prevent GDB from jumping around in the code when trying to single step
>> ifeq ($(CONFIG_DEBUG_KERNEL),y)
>> KBUILD_CFLAGS += -fno-schedule-insns -fno-schedule-insns2
>> endif
>>
>
> much of the kernel can not be build wit
Sorry for the slow response here, I got busy with other work at the end
of last week.
On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
> On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
> > On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> > > The timer/alarm stuff i
On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > My point was that a syscall is better than an ioctl based interface here,
> > which I definitely still think. Given that John knows much more about
> > clocks than I do, we
On Mon, 2010-08-23 at 15:44 +0200, Arnd Bergmann wrote:
>
> * Alpha has an optimization for the uniprocessor case, where the atomic
> instructions get turned into nonatomic additions. The spinlock based
> version uses no locks on UP but disables interrupts for reasons I don't
> understand (nothing
From: Benjamin Herrenschmidt
Date: Tue, 24 Aug 2010 08:01:25 +1000
> On Mon, 2010-08-23 at 15:44 +0200, Arnd Bergmann wrote:
>>
>> * Alpha has an optimization for the uniprocessor case, where the atomic
>> instructions get turned into nonatomic additions. The spinlock based
>> version uses no lo
On 08/19/2010 08:58 AM, Ankita Garg wrote:
Hi Darren,
On Thu, Jul 22, 2010 at 11:24:13AM -0700, Darren Hart wrote:
With some instrumentation we were able to determine that the
preempt_count() appears to change across the extended_cede_processor()
call. Specifically across the plpar_hcall_nore
On Mon, 2010-08-23 at 15:18 -0700, David Miller wrote:
> > I've seen drivers in the past do trylocks at interrupt time ... tho
> I
> > agree it sucks.
>
> Recently there was a thread where this was declared absolutely
> illegal.
>
> Maybe it was allowed, or sort-of worked before, and that's why i
On Fri, Aug 20, 2010 at 12:14 AM, Benjamin Herrenschmidt
wrote:
> static inline int rwsem_is_locked(struct rw_semaphore *sem)
> {
> - return (sem->count != 0);
> + return sem->count != 0;
> }
Does this change make the code do anything different?
--
Timur Tabi
Linux kernel develo
On Fri, 2010-08-20 at 08:43 +0200, Sam Ravnborg wrote:
> > diff --git a/include/asm-generic/rwsem-cmpxchg.h
> > b/include/asm-generic/rwsem-cmpxchg.h
> > new file mode 100644
> > index 000..2b1c859
> > --- /dev/null
> > +++ b/include/asm-generic/rwsem-cmpxchg.h
> > @@ -0,0 +1,183 @@
> > +#ifnd
On Mon, 2010-08-23 at 10:23 +1000, Michael Neuling wrote:
> > Neither lfs nor stfs touch the fpscr, so remove the restore/save of it
> > around them.
>
> Do some 32 bit processors need this?
>
> In 32 bit before the merge, we use to have code that did:
>
> #if defined(CONFIG_4xx) || defined(C
> > Do some 32 bit processors need this?
> >
> > In 32 bit before the merge, we use to have code that did:
> >
> > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> >#define cvt_fd without save/restore fpscr
> > #else
> >#define cvt_fd with save/restore fpscr
> > #end if
> >
> > K
On Wed, 2010-08-11 at 15:34 -0500, Brian King wrote:
> While testing CPU DLPAR, the following problem was discovered.
> We were DLPAR removing the first CPU, which in this case was
> logical CPUs 0-3. CPUs 0-2 were already marked offline and
> we were in the process of offlining CPU 3. After markin
> The way the ifdefs are, it's the other way around. 4xx procs don't need
> to save/restore fpscr and others do.
Hrm, oh well, 601 manual says FPSCR is unaffected too :-)
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
On Aug 22, 2010, at 7:23 PM, Michael Neuling wrote:
>> Neither lfs nor stfs touch the fpscr, so remove the restore/save of it
>> around them.
>
> Do some 32 bit processors need this?
>
> In 32 bit before the merge, we use to have code that did:
>
> #if defined(CONFIG_4xx) || defined(CONFIG_E
> >> Neither lfs nor stfs touch the fpscr, so remove the restore/save of =
> it
> >> around them.
> >=20
> > Do some 32 bit processors need this?=20
> >=20
> > In 32 bit before the merge, we use to have code that did:
> >=20
> > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > #define cvt_fd
I get that with my current stuff:
cc1: warnings being treated as errors
In file included from
/home/benh/linux-powerpc-test/arch/powerpc/platforms/52xx/mpc52xx_common.c:19:
/home/benh/linux-powerpc-test/include/linux/of_gpio.h:74: error: ‘struct
gpio_chip’ declared inside parameter list
/home/be
On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote:
> On Friday 20 August 2010, Andreas Schwab wrote:
> > See arch/powerpc/platforms/cell/spu_callbacks.c.
> >
> > * 4. They are optional and we can't rely on them being
> > *linked into the kernel. Unfortunately, the cond_syscall
> > *
Hi Linus !
Here's a few powerpc bits & fixes for 2.6.36, some of them for some of
the new stuff that went in, along with the powerpc rwsem update to
atomic_long_t (not yet moved to asm-generic) and wiring up of some new
syscalls.
Cheers,
Ben.
The following changes since commit d1b113bb028999e82a
24 matches
Mail list logo
