[PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state

[Wang Dongsheng-B40534]

> -----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 at 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 at 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.