Adding members to struct cpu_functions

[Mark Tinguely]

>  >> =A0either, for the same reason. The compiler can not inline a call
>  >> =A0through a function pointer.
>  >>
>  >> =A0In which case, why not create a bunch of headers files with the
>  >> =A0pattern cpufunc_myarch.h, in which all functions would be declared
>  >> =A0inline? Something like:
>  >>
>  >> =A0static inline l2_l_entry(vm_addr_t pa, int prot, int cache);
>  >> =A0static inline l2_s_entry(vm_addr_t pa, int prot, int cache);
>  >> =A0...
>  >> =A0which would then be included by pmap.c and friends.
>  >
>  > I think they need to be regular function calls because assembly routines
>  > call the per-cpu functions. A few simple macros would save the branch to =
>  NOP
>  > functions.
>  >
>
>  I'm not sure what you mean by that: would macros be ok, in your
>  opinion? I am a bit puzzled because I see a contradiction with the
>  previous sentence that requires the functions to be callable from the
>  assembly code. Obviously I am misinterpreting, so would you mind
>  clarifying, please?
>
>  I think it is important to notice that even though cache management
>  relies a lot on assembly function, I haven't found any page table
>  management done in assembly past locore.S. I think using macros for
>  page table management functions can be done. For cache management,
>  however, I agree that having different pmap.c files is probably the
>  way to go. In both cases, I am still curious to see what Nathan will
>  come up with.

You are correct, the page tables routines are pmap.c oriented.
I extended clean up thought to all the cpu specific functions.
There are cpu specific functions that are NOPs that we branch to
and back again. I was just throwing out a global re-organization
thought.

>  I took a more thorough look at pmap, and there is indeed lots of
>  machine-specific code, especially at the beginning. And when it comes
>  to cpufunc, it's all about #ifdefs. Since I'm still working on the
>  cleanup for the beagleboard, I will declare cpufuncs in an
>  armv6-specific file. Let's call it cpufunc_armv6.c. I am struggling
>  with another MMU problem at the moment, but I'll try to come up asap
>  with a patch for pmap.c. It will replace hardcoded values with
>  machine-defined macros, for reference.

I think you are running that processor in v5 mode. There is still some
individuals looking at a cache problem with recent code. I still believe,
we need to add the PVF_REF flag when adding the new unmanaged (PVF_UNMAN)
pv_entry, so pmap_fix_cache() will clean write back the cache and remove
the tlb. That and the changes to remove dangling allocations.

--Mark.