- 22 Jan, 2014 1 commit
-
-
Santosh Shilimkar authored
Introduce memblock memory allocation APIs which allow to support PAE or LPAE extension on 32 bits archs where the physical memory start address can be beyond 4GB. In such cases, existing bootmem APIs which operate on 32 bit addresses won't work and needs memblock layer which operates on 64 bit addresses. So we add equivalent APIs so that we can replace usage of bootmem with memblock interfaces. Architectures already converted to NO_BOOTMEM use these new memblock interfaces. The architectures which are still not converted to NO_BOOTMEM continue to function as is because we still maintain the fal lback option of bootmem back-end supporting these new interfaces. So no functional change as such. In long run, once all the architectures moves to NO_BOOTMEM, we can get rid of bootmem layer completely. This is one step to remove the core code dependency with bootmem and also gives path for architectures to move away from bootmem. The proposed interface will became active if both CONFIG_HAVE_MEMBLOCK and CONFIG_NO_BOOTMEM are specified by arch. In case !CONFIG_NO_BOOTMEM, the memblock() wrappers will fallback to the existing bootmem apis so that arch's not converted to NO_BOOTMEM continue to work as is. The meaning of MEMBLOCK_ALLOC_ACCESSIBLE and MEMBLOCK_ALLOC_ANYWHERE is kept same. [akpm@linux-foundation.org: s/depricated/deprecated/] Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christoph Lameter <cl@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Paul Walmsley <paul@pwsan.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 14 Feb, 2013 1 commit
-
-
Arnd Bergmann authored
We are getting a number of warnings about the use of the deprecated bus_to_virt function in drivers using the ARM ISA DMA API: drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma': drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated (declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations] This is only because that function gets used by the inline set_dma_addr() helper. We know that any driver for the ISA DMA API is correctly using the DMA addresses, so we can change this to use the __bus_to_virt() function instead, which does not warn. After this, there are no remaining drivers that are used on any defconfigs on ARM using virt_to_bus or bus_to_virt, with the exception of the OSS sound driver. That driver is only used on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS on all other platforms and hide the deprecated functions, which is far more effective than marking them as deprecated, in order to avoid any new users of that code. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@arm.linux.org.uk>
-
- 28 Mar, 2012 1 commit
-
-
David Howells authored
Disintegrate asm/system.h for ARM. Signed-off-by:
David Howells <dhowells@redhat.com> cc: Russell King <linux@arm.linux.org.uk> cc: linux-arm-kernel@lists.infradead.org
-
- 13 Sep, 2011 1 commit
-
-
Thomas Gleixner authored
Annotate the low level hardware locks which must not be preempted. In mainline this change documents the low level nature of the lock - otherwise there's no functional difference. Lockdep and Sparse checking will work as usual. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- 18 Jul, 2011 2 commits
-
-
Nicolas Pitre authored
One less dependency on mach/memory.h. Signed-off-by:
Nicolas Pitre <nicolas.pitre@linaro.org>
-
Nicolas Pitre authored
Having this value defined at compile time prevents multiple machines with conflicting definitions to coexist. Move it to a variable in preparation for having a per machine value selected at run time. This is relevant only when CONFIG_ZONE_DMA is selected. Signed-off-by:
Nicolas Pitre <nicolas.pitre@linaro.org>
-
- 12 May, 2011 1 commit
-
-
Russell King authored
The values of ISA_DMA_THRESHOLD and MAX_DMA_ADDRESS are related; one is the physical/bus address, the other is the virtual address. Both need to be kept in step, so rather than having platforms define both, allow them to define a single macro which sets both of these macros appropraitely. Acked-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 10 Jan, 2010 1 commit
-
-
Peter Hüwe authored
A lot of ARM-defconfigs (those without CONFIG_ISA_DMA_API set) fail to build [1][2][3] due to the changes of the patch [PATCH] PCI: Clean up build for CONFIG_PCI_QUIRKS unset by Rafael J. Wysocki (Sat, 2 Jan 2010 22:57:24 +0100) [4] as the referenced variable 'isa_dma_bridge_buggy' in asm/dma.h is enclosed by the CONFIG_ISA_DMA_API conditional all configs without this setting fail to build. I'm not sure wether moving the condition is the right way to solve the issue, but atleast it fixes the issue :) References: [1] http://kisskb.ellerman.id.au/kisskb/buildresult/1983354/ [2] http://kisskb.ellerman.id.au/kisskb/buildresult/1983333/ [3] http://kisskb.ellerman.id.au/kisskb/buildresult/1983337/ [4] http://lkml.org/lkml/2010/1/2/102 Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 02 Jan, 2009 2 commits
-
-
Russell King authored
Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 08 Dec, 2008 1 commit
-
-
Russell King authored
Remove a pointless integer typedef. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 29 Nov, 2008 3 commits
-
-
Russell King authored
This avoids confusion with platform specific DMA implementations in mach/dma.h Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
When ISA_DMA_API is unset, we're not implementing the ISA DMA API, so there's no point in publishing the prototypes via asm/dma.h, nor including the machine dependent parts of that API. This allows us to remove a lot of mach/dma.h files which don't contain any useful code. Unfortunately though, some platforms put their own private non-ISA definitions into mach/dma.h, so we leave these behind and fix the appropriate #include statments. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Move the definition of MAX_DMA_ADDRESS from mach/dma.h to mach/memory.h, thereby placing it along side its relative, ISA_DMA_THRESHOLD. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 07 Aug, 2008 1 commit
-
-
Russell King authored
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 02 Aug, 2008 1 commit
-
-
Russell King authored
Move platform independent header files to arch/arm/include/asm, leaving those in asm/arch* and asm/plat* alone. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 26 Apr, 2006 1 commit
-
-
David Woodhouse authored
Signed-off-by:
David Woodhouse <dwmw2@infradead.org>
-
- 04 Jan, 2006 2 commits
-
-
Russell King authored
Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Allow the compiler to optimise the bus_to_virt(virt_to_bus()) transformation in the ARM ISA DMA interface. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-