Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
On Mon, May 31, 2010 at 10:48:32PM +0100, Richard Purdie wrote: > On Mon, 2010-05-31 at 12:09 -0700, Dmitry Torokhov wrote: > > On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: > > > I2C-drivers can use the clientdata-pointer to point to private data. As > > > I2C > > > devices are not really unregistered, but merely detached from their > > > driver, it > > > used to be the drivers obligation to clear this pointer during remove() > > > or a > > > failed probe(). As a couple of drivers forgot to do this, it was agreed > > > that it > > > was cleaner if the i2c-core does this clearance when appropriate, as > > > there is > > > no guarantee for the lifetime of the clientdata-pointer after remove() > > > anyhow. > > > This feature was added to the core with commit > > > e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. > > > > > > As there is no need anymore to clear the clientdata-pointer, remove all > > > current > > > occurrences in the drivers to simplify the code and prevent confusion. > > > > > > Signed-off-by: Wolfram Sang > > > Cc: Jean Delvare > > > --- > > > > > > Some more notes: > > > > > > I waited for rc1 as I knew there were some drivers/patches coming along > > > which > > > needed to be processed, too. > > > > > > I'd suggest that this goes via the i2c-tree, so we get rid of all > > > occurences at > > > once. > > > > > > > Frankly I'd prefer taking input stuff through my tree with the goal of > > .36 merge window just to minimize potential merge issues. This is a > > simple cleanup patch that has no dependencies, so there is little gain > > from doing it all in one go. > > How about asking Linus to take this one now, then its done and we can > all move on rather than queuing up problems for the next merge window? > That should work. Acked-by: Dmitry Torokhov > Acked-by: Richard Purdie > -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Optimise per cpu accesses on 64bit
Now we dynamically allocate the paca array, it takes an extra load
whenever we want to access another cpu's paca. One place we do that a lot
is per cpu variables. A simple example:
DEFINE_PER_CPU(unsigned long, vara);
unsigned long test4(int cpu)
{
return per_cpu(vara, cpu);
}
This takes 4 loads, 5 if you include the actual load of the per cpu variable:
ld r11,-32760(r30) # load address of paca pointer
ld r9,-32768(r30) # load link address of percpu variable
sldi r3,r29,9 # get offset into paca (each entry is 512 bytes)
ld r0,0(r11)# load paca pointer
add r3,r0,r3# paca + offset
ld r11,64(r3) # load paca[cpu].data_offset
ldx r3,r9,r11 # load per cpu variable
If we remove the ppc64 specific per_cpu_offset(), we get the generic one
which indexes into a statically allocated array. This removes one load and
one add:
ld r11,-32760(r30) # load address of __per_cpu_offset
ld r9,-32768(r30) # load link address of percpu variable
sldi r3,r29,3 # get offset into __per_cpu_offset (each entry 8 bytes)
ldx r11,r11,r3 # load __per_cpu_offset[cpu]
ldx r3,r9,r11 # load per cpu variable
Having all the offsets in one array also helps when iterating over a per cpu
variable across a number of cpus, such as in the scheduler. Before we would
need to load one paca cacheline when calculating each per cpu offset. Now we
have 16 (128 / sizeof(long)) per cpu offsets in each cacheline.
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/include/asm/percpu.h
===
--- powerpc.git.orig/arch/powerpc/include/asm/percpu.h 2010-06-01
11:10:16.225954322 +1000
+++ powerpc.git/arch/powerpc/include/asm/percpu.h 2010-06-01
11:32:27.713476455 +1000
@@ -1,7 +1,6 @@
#ifndef _ASM_POWERPC_PERCPU_H_
#define _ASM_POWERPC_PERCPU_H_
#ifdef __powerpc64__
-#include
/*
* Same as asm-generic/percpu.h, except that we store the per cpu offset
@@ -12,9 +11,7 @@
#include
-#define __per_cpu_offset(cpu) (paca[cpu].data_offset)
#define __my_cpu_offset local_paca->data_offset
-#define per_cpu_offset(x) (__per_cpu_offset(x))
#endif /* CONFIG_SMP */
#endif /* __powerpc64__ */
Index: powerpc.git/arch/powerpc/kernel/asm-offsets.c
===
--- powerpc.git.orig/arch/powerpc/kernel/asm-offsets.c 2010-06-01
11:10:16.195958268 +1000
+++ powerpc.git/arch/powerpc/kernel/asm-offsets.c 2010-06-01
11:32:27.713476455 +1000
@@ -194,7 +194,6 @@ int main(void)
DEFINE(PACA_STARTSPURR, offsetof(struct paca_struct, startspurr));
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
- DEFINE(PACA_DATA_OFFSET, offsetof(struct paca_struct, data_offset));
DEFINE(PACA_TRAP_SAVE, offsetof(struct paca_struct, trap_save));
#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
DEFINE(PACA_KVM_SVCPU, offsetof(struct paca_struct, shadow_vcpu));
Index: powerpc.git/arch/powerpc/kernel/setup_64.c
===
--- powerpc.git.orig/arch/powerpc/kernel/setup_64.c 2010-06-01
11:10:16.205958158 +1000
+++ powerpc.git/arch/powerpc/kernel/setup_64.c 2010-06-01 11:32:27.713476455
+1000
@@ -604,6 +604,9 @@ static int pcpu_cpu_distance(unsigned in
return REMOTE_DISTANCE;
}
+unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
+EXPORT_SYMBOL(__per_cpu_offset);
+
void __init setup_per_cpu_areas(void)
{
const size_t dyn_size = PERCPU_MODULE_RESERVE + PERCPU_DYNAMIC_RESERVE;
@@ -628,8 +631,10 @@ void __init setup_per_cpu_areas(void)
panic("cannot initialize percpu area (err=%d)", rc);
delta = (unsigned long)pcpu_base_addr - (unsigned long)__per_cpu_start;
- for_each_possible_cpu(cpu)
- paca[cpu].data_offset = delta + pcpu_unit_offsets[cpu];
+ for_each_possible_cpu(cpu) {
+__per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
+ paca[cpu].data_offset = __per_cpu_offset[cpu];
+ }
}
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: elide struct thread_struct instances from stack
On 01.06.2010, at 00:40, Paul Mackerras wrote: > On Mon, May 31, 2010 at 09:59:13PM +0200, Andreas Schwab wrote: > >> Instead of instantiating a whole thread_struct on the stack use only the >> required parts of it. > > ... > >> +_GLOBAL(kvm_cvt_fd) >> +lfd 0,0(r5) /* load up fpscr value */ >> +MTFSF_L(0) >> +lfs 0,0(r3) >> +stfd0,0(r4) >> +mffs0 >> +stfd0,0(r5) /* save new fpscr value */ >> +blr >> + >> +_GLOBAL(kvm_cvt_df) >> +lfd 0,0(r5) /* load up fpscr value */ >> +MTFSF_L(0) >> +lfd 0,0(r3) >> +stfs0,0(r4) >> +mffs0 >> +stfd0,0(r5) /* save new fpscr value */ >> +blr > > I re-read the relevant part of the PowerPC architecture spec > yesterday, and it seems pretty clear that the FPSCR doesn't affect the > behaviour of lfs and stfs, and is not affected by them. So in fact 4 > out of the 7 instructions in each of those procedures are unnecessary > (and similarly for the cvt_fd/df used in the alignment fixup code). So the rounding control field is not used on lfs? Interesting. I couldn't find a reference to it being used or modified either though. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: elide struct thread_struct instances from stack
On Mon, May 31, 2010 at 09:59:13PM +0200, Andreas Schwab wrote: > Instead of instantiating a whole thread_struct on the stack use only the > required parts of it. ... > +_GLOBAL(kvm_cvt_fd) > + lfd 0,0(r5) /* load up fpscr value */ > + MTFSF_L(0) > + lfs 0,0(r3) > + stfd0,0(r4) > + mffs0 > + stfd0,0(r5) /* save new fpscr value */ > + blr > + > +_GLOBAL(kvm_cvt_df) > + lfd 0,0(r5) /* load up fpscr value */ > + MTFSF_L(0) > + lfd 0,0(r3) > + stfs0,0(r4) > + mffs0 > + stfd0,0(r5) /* save new fpscr value */ > + blr I re-read the relevant part of the PowerPC architecture spec yesterday, and it seems pretty clear that the FPSCR doesn't affect the behaviour of lfs and stfs, and is not affected by them. So in fact 4 out of the 7 instructions in each of those procedures are unnecessary (and similarly for the cvt_fd/df used in the alignment fixup code). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
On Mon, 2010-05-31 at 12:09 -0700, Dmitry Torokhov wrote: > On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: > > I2C-drivers can use the clientdata-pointer to point to private data. As I2C > > devices are not really unregistered, but merely detached from their driver, > > it > > used to be the drivers obligation to clear this pointer during remove() or a > > failed probe(). As a couple of drivers forgot to do this, it was agreed > > that it > > was cleaner if the i2c-core does this clearance when appropriate, as there > > is > > no guarantee for the lifetime of the clientdata-pointer after remove() > > anyhow. > > This feature was added to the core with commit > > e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. > > > > As there is no need anymore to clear the clientdata-pointer, remove all > > current > > occurrences in the drivers to simplify the code and prevent confusion. > > > > Signed-off-by: Wolfram Sang > > Cc: Jean Delvare > > --- > > > > Some more notes: > > > > I waited for rc1 as I knew there were some drivers/patches coming along > > which > > needed to be processed, too. > > > > I'd suggest that this goes via the i2c-tree, so we get rid of all > > occurences at > > once. > > > > Frankly I'd prefer taking input stuff through my tree with the goal of > .36 merge window just to minimize potential merge issues. This is a > simple cleanup patch that has no dependencies, so there is little gain > from doing it all in one go. How about asking Linus to take this one now, then its done and we can all move on rather than queuing up problems for the next merge window? Acked-by: Richard Purdie Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
Hi Dmitry, On Mon, 31 May 2010 12:09:12 -0700, Dmitry Torokhov wrote: > Frankly I'd prefer taking input stuff through my tree with the goal of > .36 merge window just to minimize potential merge issues. This is a > simple cleanup patch that has no dependencies, so there is little gain > from doing it all in one go. If I take the patch in my i2c tree, the aim is to merge it upstream immediately, so merge issues won't exist. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: elide struct thread_struct instances from stack
On 31.05.2010, at 21:59, Andreas Schwab wrote: > Instead of instantiating a whole thread_struct on the stack use only the > required parts of it. > > Signed-off-by: Andreas Schwab > Tested-by: Alexander Graf Avi or Marcelo, please pull this in through kvm.git. Signed-off-by: Alexander Graf Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] KVM: PPC: elide struct thread_struct instances from stack
Instead of instantiating a whole thread_struct on the stack use only the
required parts of it.
Signed-off-by: Andreas Schwab
Tested-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_fpu.h | 27 +
arch/powerpc/kernel/ppc_ksyms.c |4 -
arch/powerpc/kvm/book3s.c| 49 +---
arch/powerpc/kvm/book3s_paired_singles.c | 94 --
arch/powerpc/kvm/fpu.S | 18 ++
5 files changed, 97 insertions(+), 95 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_fpu.h
b/arch/powerpc/include/asm/kvm_fpu.h
index 94f05de..c3d4f05 100644
--- a/arch/powerpc/include/asm/kvm_fpu.h
+++ b/arch/powerpc/include/asm/kvm_fpu.h
@@ -22,24 +22,24 @@
#include
-extern void fps_fres(struct thread_struct *t, u32 *dst, u32 *src1);
-extern void fps_frsqrte(struct thread_struct *t, u32 *dst, u32 *src1);
-extern void fps_fsqrts(struct thread_struct *t, u32 *dst, u32 *src1);
+extern void fps_fres(u64 *fpscr, u32 *dst, u32 *src1);
+extern void fps_frsqrte(u64 *fpscr, u32 *dst, u32 *src1);
+extern void fps_fsqrts(u64 *fpscr, u32 *dst, u32 *src1);
-extern void fps_fadds(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2);
-extern void fps_fdivs(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2);
-extern void fps_fmuls(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2);
-extern void fps_fsubs(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2);
+extern void fps_fadds(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2);
+extern void fps_fdivs(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2);
+extern void fps_fmuls(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2);
+extern void fps_fsubs(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2);
-extern void fps_fmadds(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2,
+extern void fps_fmadds(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
-extern void fps_fmsubs(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2,
+extern void fps_fmsubs(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
-extern void fps_fnmadds(struct thread_struct *t, u32 *dst, u32 *src1, u32
*src2,
+extern void fps_fnmadds(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
-extern void fps_fnmsubs(struct thread_struct *t, u32 *dst, u32 *src1, u32
*src2,
+extern void fps_fnmsubs(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
-extern void fps_fsel(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2,
+extern void fps_fsel(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
#define FPD_ONE_IN(name) extern void fpd_ ## name(u64 *fpscr, u32 *cr, \
@@ -82,4 +82,7 @@ FPD_THREE_IN(fmadd)
FPD_THREE_IN(fnmsub)
FPD_THREE_IN(fnmadd)
+extern void kvm_cvt_fd(u32 *from, u64 *to, u64 *fpscr);
+extern void kvm_cvt_df(u64 *from, u32 *to, u64 *fpscr);
+
#endif
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index bc9f39d..ab3e392 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -101,10 +101,6 @@ EXPORT_SYMBOL(pci_dram_offset);
EXPORT_SYMBOL(start_thread);
EXPORT_SYMBOL(kernel_thread);
-#ifndef CONFIG_BOOKE
-EXPORT_SYMBOL_GPL(cvt_df);
-EXPORT_SYMBOL_GPL(cvt_fd);
-#endif
EXPORT_SYMBOL(giveup_fpu);
#ifdef CONFIG_ALTIVEC
EXPORT_SYMBOL(giveup_altivec);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index b998abf..3fea19d 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -1309,12 +1309,17 @@ extern int __kvmppc_vcpu_entry(struct kvm_run *kvm_run,
struct kvm_vcpu *vcpu);
int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
int ret;
- struct thread_struct ext_bkp;
+ double fpr[32][TS_FPRWIDTH];
+ unsigned int fpscr;
+ int fpexc_mode;
#ifdef CONFIG_ALTIVEC
- bool save_vec = current->thread.used_vr;
+ vector128 vr[32];
+ vector128 vscr;
+ unsigned long uninitialized_var(vrsave);
+ int used_vr;
#endif
#ifdef CONFIG_VSX
- bool save_vsx = current->thread.used_vsr;
+ int used_vsr;
#endif
ulong ext_msr;
@@ -1327,27 +1332,27 @@ int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
/* Save FPU state in stack */
if (current->thread.regs->msr & MSR_FP)
giveup_fpu(current);
- memcpy(ext_bkp.fpr, current->thread.fpr, sizeof(current->thread.fpr));
- ext_bkp.fpscr = current->thread.fpscr;
- ext_bkp.fpexc_mode = current->thread.fpexc_mode;
+ memcpy(fpr, current->thread.fpr, sizeof(current->thread.fpr));
+ fpscr = current->thread.fpscr.val;
+ fpexc_mode = current->thread.fpexc_mode;
#ifdef CONFIG_ALTIVEC
/* Save Altivec state in stack */
- if (save_vec) {
+ used_vr = current->thread.used_vr;
+ if (used_vr) {
if (current->thread.regs->msr & MSR_V
Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
Hi Wolfram, On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: > I2C-drivers can use the clientdata-pointer to point to private data. As I2C > devices are not really unregistered, but merely detached from their driver, it > used to be the drivers obligation to clear this pointer during remove() or a > failed probe(). As a couple of drivers forgot to do this, it was agreed that > it > was cleaner if the i2c-core does this clearance when appropriate, as there is > no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. > This feature was added to the core with commit > e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. > > As there is no need anymore to clear the clientdata-pointer, remove all > current > occurrences in the drivers to simplify the code and prevent confusion. > > Signed-off-by: Wolfram Sang > Cc: Jean Delvare > --- > > Some more notes: > > I waited for rc1 as I knew there were some drivers/patches coming along which > needed to be processed, too. > > I'd suggest that this goes via the i2c-tree, so we get rid of all occurences > at > once. > Frankly I'd prefer taking input stuff through my tree with the goal of .36 merge window just to minimize potential merge issues. This is a simple cleanup patch that has no dependencies, so there is little gain from doing it all in one go. Thanks. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
Andreas Schwab wrote: > Alexander Graf writes: > > >> Mind to send it over so I can take a look at it :)? Getting rid of the >> task_struct structs lying in the stack is certainly a good idea. >> > > Still untested, because rc1 does not boot. > Normal guests work great with the patch and from a quick look over it, it seems sane. I couldn't test the paired single implementation yet, because my userspace app for that is in a flux right now. Either way, thanks a lot for the patch. Mind to wrap it up and submit it? I'll fix breakages later on. Please CC kvm-...@vger.kernel.org and k...@vger.kernel.org, so Avi or Marcelo can pick it up on the KVM tree. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
Alexander Graf writes:
> Mind to send it over so I can take a look at it :)? Getting rid of the
> task_struct structs lying in the stack is certainly a good idea.
Still untested, because rc1 does not boot.
Andreas.
---
arch/powerpc/include/asm/kvm_fpu.h | 29 +
arch/powerpc/kvm/book3s.c| 49
arch/powerpc/kvm/book3s_paired_singles.c | 94 ---
arch/powerpc/kvm/fpu.S | 18 +
4 files changed, 98 insertions(+), 92 deletions(-)
--- linux-2.6.35-rc1.orig/arch/powerpc/include/asm/kvm_fpu.h
+++ linux-2.6.35-rc1/arch/powerpc/include/asm/kvm_fpu.h
@@ -22,24 +22,24 @@
#include
-extern void fps_fres(struct thread_struct *t, u32 *dst, u32 *src1);
-extern void fps_frsqrte(struct thread_struct *t, u32 *dst, u32 *src1);
-extern void fps_fsqrts(struct thread_struct *t, u32 *dst, u32 *src1);
-
-extern void fps_fadds(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2);
-extern void fps_fdivs(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2);
-extern void fps_fmuls(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2);
-extern void fps_fsubs(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2);
+extern void fps_fres(u64 *fpscr, u32 *dst, u32 *src1);
+extern void fps_frsqrte(u64 *fpscr, u32 *dst, u32 *src1);
+extern void fps_fsqrts(u64 *fpscr, u32 *dst, u32 *src1);
+
+extern void fps_fadds(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2);
+extern void fps_fdivs(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2);
+extern void fps_fmuls(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2);
+extern void fps_fsubs(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2);
-extern void fps_fmadds(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2,
+extern void fps_fmadds(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
-extern void fps_fmsubs(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2,
+extern void fps_fmsubs(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
-extern void fps_fnmadds(struct thread_struct *t, u32 *dst, u32 *src1, u32
*src2,
+extern void fps_fnmadds(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
-extern void fps_fnmsubs(struct thread_struct *t, u32 *dst, u32 *src1, u32
*src2,
+extern void fps_fnmsubs(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
-extern void fps_fsel(struct thread_struct *t, u32 *dst, u32 *src1, u32 *src2,
+extern void fps_fsel(u64 *fpscr, u32 *dst, u32 *src1, u32 *src2,
u32 *src3);
#define FPD_ONE_IN(name) extern void fpd_ ## name(u64 *fpscr, u32 *cr, \
@@ -82,4 +82,7 @@ FPD_THREE_IN(fmadd)
FPD_THREE_IN(fnmsub)
FPD_THREE_IN(fnmadd)
+extern void kvm_cvt_fd(u32 *from, u64 *to, u64 *fpscr);
+extern void kvm_cvt_df(u64 *from, u32 *to, u64 *fpscr);
+
#endif
--- linux-2.6.35-rc1.orig/arch/powerpc/kvm/book3s.c
+++ linux-2.6.35-rc1/arch/powerpc/kvm/book3s.c
@@ -1309,12 +1309,17 @@ extern int __kvmppc_vcpu_entry(struct kv
int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
int ret;
- struct thread_struct ext_bkp;
+ double fpr[32][TS_FPRWIDTH];
+ unsigned int fpscr;
+ int fpexc_mode;
#ifdef CONFIG_ALTIVEC
- bool save_vec = current->thread.used_vr;
+ vector128 vr[32];
+ vector128 vscr;
+ unsigned long uninitialized_var(vrsave);
+ int used_vr;
#endif
#ifdef CONFIG_VSX
- bool save_vsx = current->thread.used_vsr;
+ int used_vsr;
#endif
ulong ext_msr;
@@ -1327,27 +1332,27 @@ int __kvmppc_vcpu_run(struct kvm_run *kv
/* Save FPU state in stack */
if (current->thread.regs->msr & MSR_FP)
giveup_fpu(current);
- memcpy(ext_bkp.fpr, current->thread.fpr, sizeof(current->thread.fpr));
- ext_bkp.fpscr = current->thread.fpscr;
- ext_bkp.fpexc_mode = current->thread.fpexc_mode;
+ memcpy(fpr, current->thread.fpr, sizeof(current->thread.fpr));
+ fpscr = current->thread.fpscr.val;
+ fpexc_mode = current->thread.fpexc_mode;
#ifdef CONFIG_ALTIVEC
/* Save Altivec state in stack */
- if (save_vec) {
+ used_vr = current->thread.used_vr;
+ if (used_vr) {
if (current->thread.regs->msr & MSR_VEC)
giveup_altivec(current);
- memcpy(ext_bkp.vr, current->thread.vr, sizeof(ext_bkp.vr));
- ext_bkp.vscr = current->thread.vscr;
- ext_bkp.vrsave = current->thread.vrsave;
+ memcpy(vr, current->thread.vr, sizeof(current->thread.vr));
+ vscr = current->thread.vscr;
+ vrsave = current->thread.vrsave;
}
- ext_bkp.used_vr = current->thread.used_vr;
#endif
#ifdef CONFIG_VSX
/* Save VSX state in stack */
- if (save_vsx && (current->thread.regs->msr & MSR_VSX))
+ used_vsr = current->thread.used_vsr;
+ if (used_vsr
Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: > I2C-drivers can use the clientdata-pointer to point to private data. As I2C > devices are not really unregistered, but merely detached from their driver, it > used to be the drivers obligation to clear this pointer during remove() or a > failed probe(). As a couple of drivers forgot to do this, it was agreed that > it > was cleaner if the i2c-core does this clearance when appropriate, as there is > no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. > This feature was added to the core with commit > e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. > > As there is no need anymore to clear the clientdata-pointer, remove all > current > occurrences in the drivers to simplify the code and prevent confusion. > > Signed-off-by: Wolfram Sang > Cc: Jean Delvare Acked-by: Greg Kroah-Hartman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
Andreas Schwab wrote: > Alexander Graf writes: > > >> On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote: >> >> >>> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote: >>> Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/ppc_ksyms.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) >>> Alex, this is just a temporary fix to remove the build breakage for 40x >>> etc... but please, update KVM to just build-in its own. >>> >> What's the bad part in reusing the existing code? >> > > The bad part is that KVM is wasting a ridiculous amount of stack space > by allocating multiple instances of struct task_struct on it. I have a > patch removing all of it, but I haven't tested it yet. > Mind to send it over so I can take a look at it :)? Getting rid of the task_struct structs lying in the stack is certainly a good idea. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: > I2C-drivers can use the clientdata-pointer to point to private data. As I2C > devices are not really unregistered, but merely detached from their driver, it > used to be the drivers obligation to clear this pointer during remove() or a > failed probe(). As a couple of drivers forgot to do this, it was agreed that > it > was cleaner if the i2c-core does this clearance when appropriate, as there is > no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. > This feature was added to the core with commit > e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. > > As there is no need anymore to clear the clientdata-pointer, remove all > current > occurrences in the drivers to simplify the code and prevent confusion. > > Signed-off-by: Wolfram Sang Acked-by: Mark Brown ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
I2C-drivers can use the clientdata-pointer to point to private data. As I2C devices are not really unregistered, but merely detached from their driver, it used to be the drivers obligation to clear this pointer during remove() or a failed probe(). As a couple of drivers forgot to do this, it was agreed that it was cleaner if the i2c-core does this clearance when appropriate, as there is no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. This feature was added to the core with commit e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: Wolfram Sang Cc: Jean Delvare --- Some more notes: I waited for rc1 as I knew there were some drivers/patches coming along which needed to be processed, too. I'd suggest that this goes via the i2c-tree, so we get rid of all occurences at once. I used get_maintainers with --no-git, otherwise the cc-list would have gotten too excessive IMHO. I think the number of included mailing-lists will do. The removal was done using coccinelle and reviewed manually. drivers/hwmon/adt7411.c |2 -- drivers/hwmon/asc7621.c |2 -- drivers/hwmon/f75375s.c |2 -- drivers/hwmon/g760a.c |2 -- drivers/hwmon/lm73.c |1 - drivers/hwmon/lm75.c |2 -- drivers/hwmon/lm95241.c |1 - drivers/hwmon/tmp102.c|2 -- drivers/hwmon/tmp421.c|2 -- drivers/hwmon/w83781d.c |2 -- drivers/i2c/i2c-smbus.c |1 - drivers/input/keyboard/adp5588-keys.c |1 - drivers/input/keyboard/lm8323.c |2 -- drivers/input/keyboard/max7359_keypad.c |1 - drivers/input/keyboard/qt2160.c |1 - drivers/input/keyboard/tca6416-keypad.c |2 -- drivers/input/misc/ad714x-i2c.c |1 - drivers/input/misc/pcf8574_keypad.c |2 -- drivers/input/mouse/synaptics_i2c.c |1 - drivers/input/touchscreen/ad7879.c|5 + drivers/input/touchscreen/eeti_ts.c |2 -- drivers/input/touchscreen/mcs5000_ts.c|1 - drivers/input/touchscreen/tsc2007.c |2 -- drivers/leds/leds-bd2802.c|2 -- drivers/leds/leds-lp3944.c|1 - drivers/leds/leds-pca9532.c |5 + drivers/leds/leds-pca955x.c |2 -- drivers/macintosh/therm_adt746x.c |2 -- drivers/macintosh/windfarm_lm75_sensor.c |5 + drivers/macintosh/windfarm_max6690_sensor.c |1 - drivers/macintosh/windfarm_smu_sat.c |1 - drivers/media/radio/si470x/radio-si470x-i2c.c |1 - drivers/media/video/mt9m001.c |2 -- drivers/media/video/mt9m111.c |2 -- drivers/media/video/mt9t031.c |2 -- drivers/media/video/mt9t112.c |2 -- drivers/media/video/mt9v022.c |2 -- drivers/media/video/ov772x.c |2 -- drivers/media/video/ov9640.c |2 -- drivers/media/video/rj54n1cb0c.c |2 -- drivers/media/video/tcm825x.c |8 +--- drivers/media/video/tw9910.c |2 -- drivers/mfd/88pm860x-i2c.c|2 -- drivers/mfd/ab3100-core.c |2 -- drivers/mfd/ab3550-core.c |1 - drivers/mfd/adp5520.c |2 -- drivers/mfd/da903x.c |2 -- drivers/mfd/max8925-i2c.c |1 - drivers/mfd/menelaus.c|2 -- drivers/mfd/pcf50633-core.c |2 -- drivers/mfd/tc35892.c |2 -- drivers/mfd/tps65010.c|1 - drivers/mfd/wm8350-i2c.c |2 -- drivers/mfd/wm8400-core.c |2 -- drivers/misc/eeprom/at24.c|1 - drivers/mtd/maps/pismo.c |2 -- drivers/power/max17040_battery.c |2 -- drivers/regulator/lp3971.c|2 -- drivers/regulator/max1586.c |1 - drivers/regulator/max8649.c |2 -- drivers/regulator/max8660.c |1 - drivers/regulator/tps65023-regulator.c|3 --- drivers/rtc/rtc-ds1374.c |2 -- drivers/rtc/rtc-rx8025.c |2 -- drivers/rtc/rtc-s35390a.c |2 -- drivers/staging/dream/synaptics_i2c_rmi.c |2 -- drivers/staging/go7007
Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
Alexander Graf writes: > On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote: > >> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote: >>> Signed-off-by: Benjamin Herrenschmidt >>> --- >>> arch/powerpc/kernel/ppc_ksyms.c |2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> Alex, this is just a temporary fix to remove the build breakage for 40x >> etc... but please, update KVM to just build-in its own. > > What's the bad part in reusing the existing code? The bad part is that KVM is wasting a ridiculous amount of stack space by allocating multiple instances of struct task_struct on it. I have a patch removing all of it, but I haven't tested it yet. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
On Mon, 2010-05-31 at 11:33 +0200, Alexander Graf wrote: > > Alex, this is just a temporary fix to remove the build breakage for > 40x > > etc... but please, update KVM to just build-in its own. > > What's the bad part in reusing the existing code? I'm not saying we should dup the code, but I'm sure we can find a better way for that sort of stuff, along with other base support bits like you normally find in libgcc, to be linked directly with all modules. calling out of modules symbols sucks for perf too anyways. > > Don't we have .o's that are always built into modules nowadays ? > > I don't think I understand what you mean. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote: > On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote: >> Signed-off-by: Benjamin Herrenschmidt >> --- >> arch/powerpc/kernel/ppc_ksyms.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) > > Alex, this is just a temporary fix to remove the build breakage for 40x > etc... but please, update KVM to just build-in its own. What's the bad part in reusing the existing code? > Don't we have .o's that are always built into modules nowadays ? I don't think I understand what you mean. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: halt the system without any broadcast message on the console
On Thu, 2010-05-27 at 17:39 +0200, Bosi Daniele wrote: > > I'd like to avoid this message on the console I'm using because at > production time this has to be a simple serial port for external > peripheral connection. (to do this on the command line we'll leave > empty the "console" field). I'm not sure I understand. If the serial port has to talk to an external periph, then you don't want the console on it, in which case it will not have the broadcast messages. If it's a console, then it will get them ... along with everything else a console gets. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
On Fri, 2010-04-16 at 15:58 +0200, Peter Zijlstra wrote:
>
>
> Hrmm, my brain seems muddled but I might have another solution, let me
> ponder this for a bit..
>
Right, so the thing I was thinking about is taking the group capacity
into account when determining the capacity for a single cpu.
Say the group contains all the SMT siblings, then use the group capacity
(usually larger than 1024) and then distribute the capacity over the
group members, preferring CPUs with higher individual cpu_power over
those with less.
So suppose you've got 4 siblings with cpu_power=294 each, then we assign
capacity 1 to the first member, and the remaining 153 is insufficient,
and thus we stop and the rest lives with 0 capacity.
Now take the example that the first sibling would be running a heavy RT
load, and its cpu_power would be reduced to say, 50, then we still got
nearly 933 left over the others, which is still sufficient for one
capacity, but because the first sibling is low, we'll assign it 0 and
instead assign 1 to the second, again, leaving the third and fourth 0.
If the group were a core group, the total would be much higher and we'd
likely end up assigning 1 to each before we'd run out of capacity.
For power savings, we can lower the threshold and maybe use the maximal
individual cpu_power in the group to base 1 capacity from.
So, suppose the second example, where sibling0 has 50 and the others
have 294, you'd end up with a capacity distribution of: {0,1,1,1}.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
