From mboxrd@z Thu Jan 1 00:00:00 1970 From: nico@fluxnic.net (Nicolas Pitre) Date: Fri, 14 Oct 2011 14:01:07 -0400 (EDT) Subject: [PATCH] arm/tegra: select AUTO_ZRELADDR by default In-Reply-To: <201110141827.53906.arnd@arndb.de> References: <1317172068-14872-1-git-send-email-pdeschrijver@nvidia.com> <201110141729.41515.arnd@arndb.de> <74CDBE0F657A3D45AFBB94109FB122FF173BE1A283@HQMAIL01.nvidia.com> <201110141827.53906.arnd@arndb.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 14 Oct 2011, Arnd Bergmann wrote: > On Friday 14 October 2011, Stephen Warren wrote: > > Arnd Bergmann wrote at Friday, October 14, 2011 9:30 AM: > > ... > > > You mention that tegra30 will require AUTO_ZRELADDR. > > > > Well, just to be clear, here's the situation I think: > > > > Tegra20's SDRAM starts at physical address 0. > > > > Tegra30's SDRAM starts at physical address 2G. > > > > To support that, we could either: > > > > a) Introduce a new Kconfig variable for Tegra30, make T20/T30 mutually > > exclusive, and update arch/arm/mach-tegra/Makefile.boot to set zreladdr > > etc. based on the new Tegra30 config variable too. Then, there's no need > > for AUTO_ZRELADDR anywhere. > > > > b) Have no new config variable, build a unified T20/T30 kernel, leave > > Makefile.boot untouched, and rely on using AUTO_ZRELADDR for Tegra30 to > > account for the different SDRAM physical addresses. > > Ok, thanks for the explanation, that makes it much clearer. For > completeness, you could also do both of the above and make T20/T30 mutually > exclusive unless AUTO_ZRELADDR is set. That might be more complex than > necessary, I don't know. The way I'm restructuring things around this is that AUTO_ZRELADDR will always be active by default, just like ARM_PATCH_PHYS_VIRT now. This platform specific exclusion thinking is a step backward so I'd prefer if people would refrain from going there for the moment. Nicolas