ARM: mm: Fix max_mapnr with recent max*pfn updates

With commit  26ba47b1 {ARM: 7805/1: mm: change max*pfn to include
the physical offset of memory}, the max_pfn already contain
PHYS_PFN_OFFSET, so it shouldn't be taken into account again.

While at it, use use set_max_mapnr() helper.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ARM: mm: Don't allow resizing of memblock data until "low" memory is not mapped

If allowed by call to memblock_allow_resize() - The Memblock core will
try to allocate additional memory and rearrange its internal data in
case, if there are more then INIT_MEMBLOCK_REGIONS(128) memory regions
of any type have been allocated. If this happens before Low memory is
mapped (which is done now by map_lowmem()) the system will hang, because
the Memblock core will try to operate with virtual addresses which
aren't mapped yet.

In ARM code, the memblock resizing is allowed (memblock_allow_resize())
from arm_memblock_init() which is called before map_lowmem(), so
this may lead to an error as described above.

Hence, allow Memblock resizing later during init, from bootmem_init()
when all appropriate mappings are ready.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ARM: mm: Remove bootmem code and switch to NO_BOOTMEM

Now with dma_mask series merged and max*pfn has consistent meaning on ARM
as rest of the arch's thanks to RMK's mega series, lets switch ARM code
to NO_BOOTMEM. With NO_BOOTMEM change, now we use memblock allocator to
reserve space for crash kernel to have one less dependency with nobootmem
allocator wrapper.

Tested with both flat memory and sparse (faked) memory models with highmem
enabled.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ktest: Add special variable ${KERNEL_VERSION}

Add a special variable that can be used in other variables called
${KERNEL_VERSION}. This will embed the current kernel version into
the variable. For example:

WARNINGS_FILE = ${OUTPUT_DIR}/warnings-${KERNEL_VERSION}

If the current version is v3.8 then the WARNINGS_FILE will become

  ${OUTPUT_DIR}/warnings-v3.8

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
ktest: Add eval '=~' command to modify variables in config file

With the added variable ${KERNEL_VERSION}, it is useful to be
able to use parts of it for other variables.

For example, if you want to create a warnings file for each major
kernel version to test sub versions against you can create
your warnings file with like this:

  WARNINGS_FILE = warnings-file-${KERNEL_VERSION}

But this may add 3.8.12 or something, and we want all 3.8.* to
use the same file, and 3.10.* to use another file, and so on.
With the eval command we can, by adding:

  WARNINGS_FILE =~ s/(-file-\d+\.\d+).*/$1/

Which will chop off the extra characters after the 3.8.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
ARM: dts: Add support for sbc-3xxx with cm-t3730

This adds support for CompuLab SBC-T3530, also known as cm-t3730:

http://compulab.co.il/products/sbcs/sbc-t3530/

It seems that with the sbc-3xxx mainboard is also used on
SBC-T3517 and SBC-T3730 with just a different CPU module:

http://compulab.co.il/products/sbcs/sbc-t3517/
http://compulab.co.il/products/sbcs/sbc-t3730/

So let's add a common omap3-sb-t35.dtsi and then separate SoC
specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and
omap3-sbc-t3517.dts.

I've tested this with SBC-T3730 as that's the only one I have.
At least serial, both Ethernet controllers, MMC, and wl12xx WLAN
work.

Note that WLAN seems to be different for SBC-T3530. And SBC-T3517
may need some changes for the EMAC Ethernet if that's used
instead of the smsc911x.

Cc: devicetree@vger.kernel.org
Cc: Mike Rapoport <mike@compulab.co.il>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
clk: at91: fix pmc_clk_ids data type attriubte

Fix pmc_clk_ids data type attribute (__initdata -> __initconst).

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
ARM: at91: switch Calao QIL-A9260 board to DT

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
[nicolas.ferre@atmel.com: typo, nodes in address ascending order, shrink cmdline]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
ARM: versatile: move GPIO2 and GPIO3 to core

Move GPIO2 and GPIO3 to be registered from the core as this is
certainly available on Versatile AB as well, not just the PB.
GPIO2 is used for reading board status and GPIO3 is unused,
but it does not hurt to register it anyway.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ARM: versatile: update defconfig

This updates the Versatile defconfig to the thing saved by
savedefconfig so we don't get confusing diffs when trying to
modify other options.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ARM: versatile: enable GPIOLIB and PL061 by default

Select the GPIOLIB and PL061 in the Versatile defconfig, as this
is present on all boards, and so we get compile and test coverage
for this.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ARM: versatile: build using EABI

This should work just fine on this purely v5 platform, so let's
config it for EABI by default.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ARM: versatile: enable LEDs by default

This adds the LEDs and triggers used by the Versatile boards to
the default configuration.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
localmodconfig: Add config depends by default settings

Currently localmodconfig will miss dependencies from the default option.
For example:

config FOO
	default y if BAR || ZOO

If FOO is needed for a module and is set to '=m', and so are BAR or ZOO,
localmodconfig will not see that BOO or ZOO are also needed for the foo
module, and will incorrectly disable them.

Link: http://lkml.kernel.org/r/20131218175137.162937350@goodmis.org

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
drm/bochs: new driver

DRM driver for (virtual) vga cards using the bochs dispi
interface, such as the qemu standard vga (qemu -vga std).

Don't bother supporting anything but 32bpp for now, even
though the virtual hardware is able to do that.

Known issue: mmap(/dev/fb0) doesn't work.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/radeon: improve ring debugfs a bit

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/radeon: report the real offset in radeon_sa_bo_dump_debug_info

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/radeon: update fence values in before reporting them

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/radeon: cleanup radeon_ttm debugfs handling

Otherwise we not necessary export the right information.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/radeon: add VRAM debugfs access v3

Not very fast, but makes it possible to access even the
normally inaccessible parts of VRAM from userspace.

v2: use MM_INDEX_HI for >2GB mem access, add default_llseek
v3: set inode size in the open callback

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>