Re: clean way to support >32bit addr on 32bit CPU

From: Roland Dreier <roland@topspin.com>
To: Dave <dave.jiang@gmail.com>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.org,
	smaurer@teja.com, linux@arm.linux.org.uk, dsaxena@plexity.net,
	drew.moseley@intel.com
Subject: Re: clean way to support >32bit addr on 32bit CPU
Date: Mon, 10 Jan 2005 16:04:05 -0800	[thread overview]
Message-ID: <52u0poygp6.fsf@topspin.com> (raw)
In-Reply-To: <8746466a050110153479954fd2@mail.gmail.com> (Dave's message of "Mon, 10 Jan 2005 16:34:03 -0700")

    Dave> I have this ARM (XScale) based platform that supports 36bit
    Dave> physical addressing. Due to the way the ATU is designed, the
    Dave> outbound memory translation window is fixed outside the
    Dave> first 4GB of memory space, and thus the need to use 64bit
    Dave> addressing in order to access the PCI bus. After all said
    Dave> and done, the struct resource members start and end must
    Dave> support 64bit integer values in order to work. On a 64bit
    Dave> arch that would be fine since unsigned long is
    Dave> 64bit. However on a 32bit arch one must use unsigned long
    Dave> long to get 64bit. However, if we do that then it would make
    Dave> the 64bit archs to have 128bit start and end and probably
    Dave> wouldn't be something we'd want. What would be a nice clean
    Dave> way to support this that's acceptable to Linux? I guess this
    Dave> issue would be similar to x86-32 PAE would have?

Actually unsigned long long is still 64 bits even on 64-bit Linux
architectures.  However it might make more sense to use an explicit
size for the resource addresses, namely u64.

This XScale architecture seems similar to the PowerPC 440, which also
uses 36-bit addressing for various buses including PCI.  You might
want to take a look at arch/ppc for inspiration.

 - Roland