Re: include/asm-arm/memory.h changes break zaurus sl-5500 boot

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Mon, Apr 03, 2006 at 05:56:03PM +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 3 Apr 2006 16:44:34 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> 
> > On Mon, 3 Apr 2006 08:36:53 +0100
> > Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > Hmm..from include/asm-arm/arch-clps711x/memory.h
> > 
> > ==
> > /*
> >  * Given a kaddr, LOCAL_MAR_NR finds the owning node of the memory
> >  * and returns the index corresponding to the appropriate page in the
> >  * node's mem_map.
> >  */
> > #define LOCAL_MAP_NR(addr) \
> >         (((unsigned long)(addr) & (NODE_MAX_MEM_SIZE - 1)) >> PAGE_SHIFT)
> > ==
> > 
> > Is this comment wrong ???

The comment isn't entirely accurate.

> All of sub-arch's comment says "Given a kaddr" but all of them just uses
> "offset".  So, paddr can be given as arg. 

Yes.

> __va()(or pfn_to_kaddr()) adds unnecessary calcs, so paddr should be used
> instead of kaddr.

The problem with __va() and pfn_to_kaddr() is that it adds unnecessary
calculation which the compiler can not optimise away.

>From the use of LOCAL_MAP_NR(), we know that it's returning an offset
into a particular node, and that there's a 1:1 relationship between
the virtual and physical addresses within nodes.  That means that
LOCAL_MAP_NR() can take either a virtual address, a physical address,
or even a byte offset into the node.

In turn, that means that we can pass it whatever address we happen to
have available at the time, or whichever is simpler to calculate.

In the cases you're looking at (pfn to map number) giving it pfn <<
PAGE_SHIFT is entirely sufficient, and is in fact optimal for
performance.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/