Message ID | ABB05CD9C9F68C46A5CEDC7F1543925901027BD3@039-SN2MPN1-021.039d.mgd.msft.net (mailing list archive) |
---|---|
State | Rejected, archived |
Headers | show |
On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote: > > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Tuesday, August 20, 2013 8:39 AM > > To: Wang Dongsheng-B40534 > > Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter > > altivec idle state > > > > It just seems wrong to have an ad-hoc mechanism for running > > core-specific code when we have cputable... If we really need this, > > maybe we should add a "cpu_setup_late" function pointer. > > > > With your patch, when does the power management register get set when > > hot plugging a cpu? > > > Um.. I don't deal with this situation. I will fix it. > __setup/restore_cpu_e6500 looks good. But only bootcpu call __setup_cpu_e6500, not on each cpu. > I think this is a bug. Other CPUs call __restore_cpu_e6500. > > > > As for the PVR check, the upstream kernel doesn't need to care about > > > > rev1, so knowing it's an e6500 is good enough. > > > > > > > But AltiVec idle & PW20 cannot work on rev1 platform. > > > We didn't have to deal with it? > > > > Upstream does not run on rev1. > > > :), But already have customers in the use of rev1. > Why we don't need to care about that? rev1 is not production-qualified. Those customers are supposed to only be using rev1 for evaluation and early development. It's not that we don't care about rev1 now (we have the SDK for that) but that we won't care about it long-term and don't want to have to carry around a bunch of baggage for it. Some of the workarounds are pretty nasty (especially A-006198). -Scott
> -----Original Message----- > From: Wood Scott-B07421 > Sent: Thursday, August 22, 2013 11:19 PM > To: Wang Dongsheng-B40534 > Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc- > dev@lists.ozlabs.org > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter > altivec idle state > > On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote: > > > > > -----Original Message----- > > > From: Wood Scott-B07421 > > > Sent: Tuesday, August 20, 2013 8:39 AM > > > To: Wang Dongsheng-B40534 > > > Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org > > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically > > > enter altivec idle state > > > > > > It just seems wrong to have an ad-hoc mechanism for running > > > core-specific code when we have cputable... If we really need this, > > > maybe we should add a "cpu_setup_late" function pointer. > > > > > > With your patch, when does the power management register get set > > > when hot plugging a cpu? > > > > > Um.. I don't deal with this situation. I will fix it. > > __setup/restore_cpu_e6500 looks good. But only bootcpu call > __setup_cpu_e6500, not on each cpu. > > I think this is a bug. > > Other CPUs call __restore_cpu_e6500. > No, there is bootcore of secondary thread, and other cores of first thread call __restore_cpu_e6500. This flow is correct? > > > > > As for the PVR check, the upstream kernel doesn't need to care > > > > > about rev1, so knowing it's an e6500 is good enough. > > > > > > > > > But AltiVec idle & PW20 cannot work on rev1 platform. > > > > We didn't have to deal with it? > > > > > > Upstream does not run on rev1. > > > > > :), But already have customers in the use of rev1. > > Why we don't need to care about that? > > rev1 is not production-qualified. Those customers are supposed to only > be using rev1 for evaluation and early development. It's not that we > don't care about rev1 now (we have the SDK for that) but that we won't > care about it long-term and don't want to have to carry around a bunch of > baggage for it. Some of the workarounds are pretty nasty (especially A- > 006198). > Thanks.
On Thu, 2013-08-22 at 21:52 -0500, Wang Dongsheng-B40534 wrote: > > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Thursday, August 22, 2013 11:19 PM > > To: Wang Dongsheng-B40534 > > Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc- > > dev@lists.ozlabs.org > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter > > altivec idle state > > > > On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote: > > > > > > > -----Original Message----- > > > > From: Wood Scott-B07421 > > > > Sent: Tuesday, August 20, 2013 8:39 AM > > > > To: Wang Dongsheng-B40534 > > > > Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org > > > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically > > > > enter altivec idle state > > > > > > > > It just seems wrong to have an ad-hoc mechanism for running > > > > core-specific code when we have cputable... If we really need this, > > > > maybe we should add a "cpu_setup_late" function pointer. > > > > > > > > With your patch, when does the power management register get set > > > > when hot plugging a cpu? > > > > > > > Um.. I don't deal with this situation. I will fix it. > > > __setup/restore_cpu_e6500 looks good. But only bootcpu call > > __setup_cpu_e6500, not on each cpu. > > > I think this is a bug. > > > > Other CPUs call __restore_cpu_e6500. > > > No, there is bootcore of secondary thread, and other cores of first thread call __restore_cpu_e6500. This is the upstream list -- there is no e6500 thread support yet. :-) But in the SDK I do see generic_secondary_common_init being called from generic_secondary_thread_init, which means __restore_cpu_e6500 will be called. -Scott
> -----Original Message----- > From: Wood Scott-B07421 > Sent: Friday, August 23, 2013 11:31 PM > To: Wang Dongsheng-B40534 > Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc- > dev@lists.ozlabs.org > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter > altivec idle state > > On Thu, 2013-08-22 at 21:52 -0500, Wang Dongsheng-B40534 wrote: > > > > > -----Original Message----- > > > From: Wood Scott-B07421 > > > Sent: Thursday, August 22, 2013 11:19 PM > > > To: Wang Dongsheng-B40534 > > > Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc- > > > dev@lists.ozlabs.org > > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically > enter > > > altivec idle state > > > > > > On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote: > > > > > > > > > -----Original Message----- > > > > > From: Wood Scott-B07421 > > > > > Sent: Tuesday, August 20, 2013 8:39 AM > > > > > To: Wang Dongsheng-B40534 > > > > > Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org > > > > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically > > > > > enter altivec idle state > > > > > > > > > > It just seems wrong to have an ad-hoc mechanism for running > > > > > core-specific code when we have cputable... If we really need > this, > > > > > maybe we should add a "cpu_setup_late" function pointer. > > > > > > > > > > With your patch, when does the power management register get set > > > > > when hot plugging a cpu? > > > > > > > > > Um.. I don't deal with this situation. I will fix it. > > > > __setup/restore_cpu_e6500 looks good. But only bootcpu call > > > __setup_cpu_e6500, not on each cpu. > > > > I think this is a bug. > > > > > > Other CPUs call __restore_cpu_e6500. > > > > > No, there is bootcore of secondary thread, and other cores of first > thread call __restore_cpu_e6500. > > This is the upstream list -- there is no e6500 thread support yet. :-) > > But in the SDK I do see generic_secondary_common_init being called from > generic_secondary_thread_init, which means __restore_cpu_e6500 will be > called. Thanks.
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 2cfed9e..2a9a718 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -603,6 +603,9 @@ __secondary_start: /* Set thread priority to MEDIUM */ HMT_MEDIUM +#ifdef CONFIG_PPC_BOOK3E + bl call_setup_cpu /* Call setup_cpu for this CPU */ +#endif /* Initialize the kernel stack */ LOAD_REG_ADDR(r3, current_set) sldi r28,r24,3 /* get current_set[cpu#] */ diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index b863b87..7d84bf4 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -55,6 +55,17 @@ _GLOBAL(call_handle_irq) mtlr r0 blr +_GLOBAL(call_setup_cpu) + LOAD_REG_ADDR(r4, cur_cpu_spec) + ld r4, 0(r4) + ld r5, CPU_SPEC_SETUP(r4) + + cmpwi 0, r5, 0 + beqlr + ld r5, 0(r5) + mtctr r5 + bctr + .section ".toc","aw" PPC64_CACHES: .tc ppc64_caches[TC],ppc64_caches