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.