Skip to contentSkip to conversation

bigphysarea for 2.6.9

PATCH New Nick Martin 1 participant 1 message Nov 15, 2004

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 bigphysarea for 2.6.9

I've pulled the bigphysarea patch[1] foward to 2.6.9. Maybe someone here will find it useful.

I've only tested on i386, but I don't see why it shouldn't work on other architectures.

Enjoy,
-- Nick

[1]: from http://www.polyware.nl/~middelink/En/hob-v4l.html

---------

Documentation/bigphysarea.txt +64 -0
diff -urN linux-2.6.9.orig/Documentation/bigphysarea.txt linux-2.6.9.bigphys/Documentation/bigphysarea.txt
@@ -0,0 +1,64 @@
+Bigphysarea
+===========
+
+This set of functions give you the ability to allocate big
+contineous (DMAable) memory for the entire runtime of Linux.
+Big meaning here more than 128KB, the maximum allocation
+limit of kmalloc(). Due to fragmentation reasons kmalloc()
+is unable to garantee allocs of this order during a prolonged
+run of the kernel. This new pool of memory blob can be used
+during the initialization or use of soundcards of framegrabbers
+which are designed without DMA scatter-gatter capabilities.
+
+For a sample use, see the zoran driver in drivers/char/zr36120_mem.c
+
+Enjoy,
+  Pauline Middelink
+
+How to start
+============
+First add bigphysarea=<number of pages to alloc> to the
+commandline of your kernel. Either do this by adding an
+append= line to your /etc/lilo/conf setup or use some
+magic marker...
+After booting the new kernel there should be a /proc/bigphysarea
+file telling your how many blocks/bytes are available.
+
+The interface description
+=========================
+The big physical area is mainly managed by two functions. The first one,
+
+caddr_t bigphysarea_alloc_pages(int count, int align, int priority)
+
+allocates 'count' pages. The pages are aligned so that there base
+address is a multiple of 'PAGE_SIZE * align'. If you don't need more
+than page alignment, set 'align' to 0 or 1. 'priority' has the same
+meaning as in kmalloc, it can be GFP_ATOMIC (for calls from interrupt
+handlers) or GFP_KERNEL (for usual calls). The base address of the
+allocated area is returned.
+
+Allocation can fail for two reasons, in both cases NULL is
+returned. First, the physical area is scattered too much or there is
+not enough memory, second it is not possible to allocate some memory
+with kmalloc for administration of the physical area (very unlikely).
+
+To free an allocated area, just call
+
+void bigphysarea_free_pages(caddr_t base)
+
+with 'base' set to the value returned by 'bigphysarea_alloc_pages'. 
+
+An example how to use this functions can be found in 'module.c'.
+
+There is still the old interface introduced by M. Welsh:
+
+caddr_t bigphysarea_alloc(int size)
+void bigphysarea_free(caddr_t addr, int size)
+
+The first function allocates 'size' bytes physically continous
+memory. To free the area, bigphysarea_free with a pointer to the area
+and its size has to be called. Due to a new allocation algorithm, the
+size parameter is no longer really needed when freeing an area.
+
+In the current version it is not safe to call any of the functions
+from an interrupt handler.
Makefile +1 -1
diff -urN linux-2.6.9.orig/Makefile linux-2.6.9.bigphys/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 9
-EXTRAVERSION =
+EXTRAVERSION = -bigphys
 NAME=Zonked Quokka
 
 # *DOCUMENTATION*
arch/i386/Kconfig +12 -0
diff -urN linux-2.6.9.orig/arch/i386/Kconfig linux-2.6.9.bigphys/arch/i386/Kconfig
@@ -816,6 +816,18 @@
 
 	  See <file:Documentation/mtrr.txt> for more information.
 
+config BIGPHYS_AREA
+	bool "Big Physical Area"
+        ---help---
+          Enables kernel support for reserving large areas of physical
+          memory at boot-time for use by certain device drivers (such as
+          video framegrabbers, etc.) which require it. To use this
+          feature, boot the kernel with the boot-time option
+          'bigphysarea=nnn' where 'nnn' is the number of pages (a page
+          is usually 4K) to reserve.
+
+          See <file:Documentation/bigphysarea.txt> for more information.
+
 config EFI
 	bool "Boot from EFI support (EXPERIMENTAL)"
 	depends on ACPI
arch/i386/defconfig +2 -0
diff -urN linux-2.6.9.orig/arch/i386/defconfig linux-2.6.9.bigphys/arch/i386/defconfig
@@ -115,6 +115,8 @@
 # CONFIG_HIGHMEM64G is not set
 # CONFIG_MATH_EMULATION is not set
 CONFIG_MTRR=y
+CONFIG_BIGPHYS_AREA=y
+
 # CONFIG_EFI is not set
 CONFIG_IRQBALANCE=y
 CONFIG_HAVE_DEC_LOCK=y
include/linux/bigphysarea.h +31 -0
diff -urN linux-2.6.9.orig/include/linux/bigphysarea.h linux-2.6.9.bigphys/include/linux/bigphysarea.h
@@ -0,0 +1,31 @@
+/* linux/mm/bigphysarea.h, M. Welsh ([email protected])
+ * Copyright (c) 1996 by Matt Welsh.
+ * Extended by Roger Butenuth ([email protected]), October 1997
+ * Extended for linux-2.1.121 till 2.4.0 (June 2000)
+ *     by Pauline Middelink <[email protected]>
+ * Extended for linux-2.6.9 (November 2004)
+ *     by Nick Martin <[email protected]>
+ *
+ * This is a set of routines which allow you to reserve a large (?)
+ * amount of physical memory at boot-time, which can be allocated/deallocated
+ * by drivers. This memory is intended to be used for devices such as
+ * video framegrabbers which need a lot of physical RAM (above the amount
+ * allocated by kmalloc). This is by no means efficient or recommended;
+ * to be used only in extreme circumstances.
+ *
+ */
+
+#ifndef __LINUX_BIGPHYSAREA_H
+#define __LINUX_BIGPHYSAREA_H
+
+#include <linux/types.h>
+
+/* original interface */
+extern caddr_t	bigphysarea_alloc(int size);
+extern void	bigphysarea_free(caddr_t addr, int size);
+
+/* new interface */
+extern caddr_t	bigphysarea_alloc_pages(int count, int align, int priority);
+extern void	bigphysarea_free_pages(caddr_t base);
+
+#endif // __LINUX_BIGPHYSAREA_H
mm/Makefile +1 -0
diff -urN linux-2.6.9.orig/mm/Makefile linux-2.6.9.bigphys/mm/Makefile
@@ -17,4 +17,5 @@
 obj-$(CONFIG_NUMA) 	+= mempolicy.o
 obj-$(CONFIG_SHMEM) += shmem.o
 obj-$(CONFIG_TINY_SHMEM) += tiny-shmem.o
+obj-$(CONFIG_BIGPHYS_AREA) += bigphysarea.o
 
mm/bigphysarea.c +353 -0

353 lines not on this page · raw message