Pull request: removal of most instances of mach/memory.h

[Nicolas Pitre]

On Tue, 27 Sep 2011, Russell King - ARM Linux wrote:

> On Mon, Sep 26, 2011 at 07:01:22PM -0400, Nicolas Pitre wrote:
> > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> > 
> > > On Mon, Sep 26, 2011 at 04:00:11PM -0400, Nicolas Pitre wrote:
> > > > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> > > > 
> > > > > On Mon, Sep 26, 2011 at 10:33:28AM -0400, Nicolas Pitre wrote:
> > > > > >       ARM: mach-ep93xx: remove mach/memory.h and Kconfig selection of SDRAM bank
> > > > > 
> > > > > Are you planning to totally kill off ZBOOT_ROM too?  Because removing
> > > > > the zreladdr stuff is doing exactly that.
> > > > 
> > > > It looks like ZBOOT_ROM is not used on that platform at all.  However, 
> > > > the ability to have a single defconfig and binary for the whole platform 
> > > > is something that the mach-ep93xx maintainers are looking for.  Having 
> > > > ZBOOT_ROM depend on and use CONFIG_PHYS_OFFSET would probably makes 
> > > > sense eventually.
> > > 
> > > You miss the point.  Removing zreladdr actively _prevents_ anyone from
> > > then choosing to build a kernel with ZBOOT_ROM enabled targetted for one
> > > platform if that's what they want, because the decompressor then loses
> > > the information it needs to properly locate the kernel.
> > 
> > Sure.  My point is that ZBOOT_ROM should eventually be coupled with 
> > CONFIG_PHYS_OFFSET to derive the zreladdr value.  Like for XIP_KERNEL, 
> > there is no real point having ZBOOT_ROM when ARM_PATCH_PHYS_VIRT is set, 
> > and when not set we have the equivalent zreladdr information elsewhere 
> > already.
> 
> I strongly disagree on a technical point - ARM_PATCH_PHYS_VIRT and
> ZBOOT_ROM are entirely separate options _technically_ - there is no
> inter-dependence between them.  ZBOOT_ROM just needs to know where
> to place the decompressed image, and once it knows that, the kernel
> can discover the P:V translation all by itself.

What's the point having a discoverable P:V translation if you have to 
specify the location of the decompressed image?  Might as well compile 
the kernel with PATCH_PHYS_VIRT turned off in that case.

> Moreover, PHYS_OFFSET does *not* define where the kernel ends up.
> Remember that we sometimes place the kernel 1MB + 32K into the
> physical memory space - you can't encode that into CONFIG_PHYS_OFFSET
> and hope that both PHYS_OFFSET and zreladdr end up at the right place.

Technically, zreladdr = PHYS_OFFSET + TEXT_OFFSET. Always been.
And TEXT_OFFSET is always constant.  Some platforms have restrictions on 
TEXT_OFFSET which is basically making it large enough.  Most other 
platforms don't care.

> So this is argument is actually highly flawed technically.  You're
> trying to combine two things which are actually different.

I don't see why they have to be different.


Nicolas