On Mon, 2010-04-26 at 17:22 -0700, David Daney wrote:
[...]
> > Some time ago we needed to handle multiple (virtual) address-spaces
> > (in TO_CAC/TO_UNCAC as well as in virt_to_phys and the like) for
> > SGI's Indigo2/R10k and Octane (neither could run a 32bit kernel).
> > So in addrspace.h we provided
> > #ifdef CONFIG_64BIT
> > static inline unsigned long kernel_physaddr(unsigned long kva)
> > {
> > if((kva&0xffffffff80000000UL)==0xffffffff80000000UL)
> > return CPHYSADDR(kva);
> > return XPHYSADDR(kva);
> > }
> > #else
> > #define kernel_physaddr CPHYSADDR
> > #endif
> > while mach-ipXX/spaces.h defined
> > #define TO_PHYS(x) ( kernel_physaddr(x))
> > #define TO_CAC(x) (CAC_BASE | kernel_physaddr(x))
> > #define TO_UNCAC(x) (UNCAC_BASE | kernel_physaddr(x))
> > which did the job.
> > But at that time these defines didn't meet much acceptance for general
> > use in 64bit kernels. Now, to my amusement, some modern processor
> > (and/or system) seems to urge this kind of address-handling again ;-)
> >
> >
>
> FWIW, that seems cleaner than what I did (actually I didn't try my
> code). That should be the default definition for 64-bit kernels I think.
Should we let this stuff be a common implementation? then we can also
provide the TO_CAC(), TO_PHYS(), TO_UNCAC() to the 32bit kernel and
remove some #ifdef from the kernel, for example:
> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> index 1a4dd65..fb8cd40 100644
> --- a/arch/mips/kernel/traps.c
> +++ b/arch/mips/kernel/traps.c
> @@ -1557,12 +1557,7 @@ static char panic_null_cerr[] __cpuinitdata =
> void __cpuinit set_uncached_handler(unsigned long offset, void *addr,
> unsigned long size)
> {
> -#ifdef CONFIG_32BIT
> - unsigned long uncached_ebase = KSEG1ADDR(ebase);
> -#endif
> -#ifdef CONFIG_64BIT
> unsigned long uncached_ebase = TO_UNCAC(ebase);
> -#endif
>
And I have found lots of places have used KSEG1ADDR() in the kernel source code,
If the TO_UNCAC() for 32bit is provided, then we can also replace it by TO_UNCAC().
I will try to make a patch for it.
Regards,
Wu Zhangjin
