On Wed, Mar 20, 2013 at 09:45:24AM -0700, David Daney wrote: > On 03/20/2013 09:27 AM, Jayachandran C wrote: > >Allow usage of scratch register for current pgd even when > >MIPS_PGD_C0_CONTEXT is not configured. MIPS_PGD_C0_CONTEXT is set > >for 64r2 platforms to indicate availability of Xcontext for saving > >cpuid, thus freeing Context which was used for cpuid to be used for > >saving PGD. This option was also tied to using a scratch register for > >storing PGD. > > > >This commit will allow usage of scratch register to store the current > >pgd if one can be allocated for the platform, even when > >MIPS_PGD_C0_CONTEXT is not set. The cpu id will be kept in the CP0 > >Context register in this case. > > > The point of MIPS_PGD_C0_CONTEXT is really to indicate that the PGD > pointer is stored in a register (or portion thereof) and that > setting the PGD is done by calling into uasm generated code. > > Perhaps we should rename this Kconfig vairable so that its name > indicates its function, or remove it altogether if possible, and > machine generate the setting of the PGD pointer even when it is > stored in the array in memory. Removing the MIPS_PGD_C0_CONTEXT Kconfig variable does not look feasible. The processor id is used by get_saved_sp macro and it needs to know at compile time whether the processor id is in Context or Xcontext. We could call it something like MIPS_PROCESSOR_ID_IN_XCONTEXT (if it would not affect too many config files). The second part (generating code for setting PGD pointer in pgd_current) is already in the patch. This generated code also saves PGD to the scratch register if one was allocated. JC.
