If enabled MMU, there is AXI read/write error on MX508 when run
OpenVG CTS.
Besides, change EMEM1 size to 10MB by default to make gpu driver
work on MX50_ARM2 board with 128MB memory installed.
Signed-off-by: Jie Zhou <b30303@freescale.com>
Remove GSL_MMU_TRANSLATION_ENABLED macro originally used for conditional
compile, and replace it with runtime check to support one mx5x image
Signed-off-by: Jie Zhou <b30303@freescale.com>
When X-accel is enabled, uio driver is used for X server to access
z160 device, so in gsl, we should not operate z160 to avoid conflicts
Signed-off-by: Jie Zhou <b30303@freescale.com>
If dual display enabled, the second one may not be able to set
correct clock rate if it's from ext clk.
Signed-off-by: Jason Chen <b02280@freescale.com>
The uioinfo should be cleaned up when uninstall, otherwise re-install
failure of uio_pdrv_genirq.ko will happen.
Signed-off-by: Jie Zhou <b30303@freescale.com>
It seems that for USB IP on Freescale MX5x processors, it needs >750
usec for the reset to complete. This change should not hurt any other
EHCI hardware.
Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Features:
- Low metadata overhead (just 4 bytes per object)
- O(1) Alloc/Free - except when we have to call system page allocator to
get additional memory.
- Very low fragmentation: In all tests, xvmalloc memory usage is within 12%
of "Ideal".
- Pool based allocator: Each pool can grow and shrink.
- It maps pages only when required. So, it does not hog vmalloc area which
is very small on 32-bit systems.
SLUB allocator could not be used due to fragmentation issues:
http://code.google.com/p/compcache/wiki/AllocatorsComparison
Data here shows kmalloc using ~43% more memory than TLSF and xvMalloc
is showed ~2% more space efficiency than TLSF (due to smaller metadata).
Creating various kmem_caches can reduce space efficiency gap but still
problem of being limited to low memory exists. Also, it depends on
allocating higher order pages to reduce fragmentation - this is not
acceptable for ramzswap as it is used under memory crunch (its a swap
device!).
SLOB allocator could not be used do to reasons mentioned here:
http://lkml.org/lkml/2009/3/18/210
* Implementation:
It uses two-level bitmap search to find free list containing block of
correct size. This idea is taken from TLSF (Two-Level Segregate Fit)
allocator and is well explained in its paper (see [Links] below).
* Limitations:
- Poor scalability: No per-cpu data structures (work in progress).
[Links]
1. Details and Performance data:
http://code.google.com/p/compcache/wiki/xvMallochttp://code.google.com/p/compcache/wiki/xvMallocPerformance
2. TLSF memory allocator:
home: http://rtportal.upv.es/rtmalloc/
paper: http://rtportal.upv.es/rtmalloc/files/MRBC_2008.pdf
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Features:
- Low metadata overhead (just 4 bytes per object)
- O(1) Alloc/Free - except when we have to call system page allocator to
get additional memory.
- Very low fragmentation: In all tests, xvmalloc memory usage is within 12%
of "Ideal".
- Pool based allocator: Each pool can grow and shrink.
- It maps pages only when required. So, it does not hog vmalloc area which
is very small on 32-bit systems.
SLUB allocator could not be used due to fragmentation issues:
http://code.google.com/p/compcache/wiki/AllocatorsComparison
Data here shows kmalloc using ~43% more memory than TLSF and xvMalloc
is showed ~2% more space efficiency than TLSF (due to smaller metadata).
Creating various kmem_caches can reduce space efficiency gap but still
problem of being limited to low memory exists. Also, it depends on
allocating higher order pages to reduce fragmentation - this is not
acceptable for ramzswap as it is used under memory crunch (its a swap
device!).
SLOB allocator could not be used do to reasons mentioned here:
http://lkml.org/lkml/2009/3/18/210
* Implementation:
It uses two-level bitmap search to find free list containing block of
correct size. This idea is taken from TLSF (Two-Level Segregate Fit)
allocator and is well explained in its paper (see [Links] below).
* Limitations:
- Poor scalability: No per-cpu data structures (work in progress).
[Links]
1. Details and Performance data:
http://code.google.com/p/compcache/wiki/xvMallochttp://code.google.com/p/compcache/wiki/xvMallocPerformance
2. TLSF memory allocator:
home: http://rtportal.upv.es/rtmalloc/
paper: http://rtportal.upv.es/rtmalloc/files/MRBC_2008.pdf
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wed, 24 Mar 2010 08:04:11 +0000 (17:04 +0900)
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
Picked out manually from 5a0e3ad6af8660be21ca98a971cd00f331318c05 so we don't break further ramzswap updates when cherry-picking
Currently, we crash (issue BUG_ON) if backing swap
disk size is zero. This can happen is user specified
an extended partition or simply a bad disk as backing
swap. A crash is really an unpleasant surprise to user
for such trivial problems.
Now, we check for this condition and simply fail device
initialization if this is the case.
Additional cleanups:
* use static for all functions
* remove extra newline between functions
* memset backing_swap_name to NULL on device reset
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ramzswap_free_page() already handles the case for zero filled
pages. So, remove redundant logic for the same in ramzswap_write().
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently, we return 0 if create_device() fails and 1 otherwise.
Now, proper error code is returned from create_device() and the
same is propagated as module error code from ramzswap_init().
Also added some cleanups for ramzswap_init(), improving function
structure.
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ramzswap block size needs to be set equal to PAGE_SIZE to
avoid receiving any unaligned block I/O requests (happens
due to readahead logic during swapon). These unaligned
accesses produce unnecessary I/O errors, scaring users.
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Make sure we flush block device before freeing all metadata
during reset ioctl.
Signed-off-by: Nitin Gupta <ngupta@vflar.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
64-bit stats corruption was observed when ramzswap was
used on SMP systems. To prevent this, use separate spinlock
to protect these stats.
Also, replace stat_*() with rzs_stat*() to avoid possible
conflict with core kernel code.
Eventually, these will be converted to per-cpu counters
if this driver finds use on large scale systems and this
locking is found to affect scalability.
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If create_device is failed, it can't free gendisk and request_queue of
preceding devices. It cause memory leak.
This patch fixes it.
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove d-cache hack in ramzswap driver that was needed
to workaround a bug in ARM version of update_mmu_cache()
which caused stale data in d-cache to be transferred to
userspace. This bug was fixed by git commit:
787b2faadc4356b6c2c71feb42fb944fece9a12f
This also brings down one entry in TODO file.
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Creates RAM based block devices (/dev/ramzswapX) which can be
used (only) as swap disks. Pages swapped to these are compressed
and stored in memory itself.
The module is called ramzswap.ko. It depends on:
- xvmalloc memory allocator (compiled with this driver)
- lzo_compress.ko
- lzo_decompress.ko
See ramzswap.txt for usage details.
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As a side effect of not doing this, the V4L driver would happily go off and touch a framebuffer address that was invalid, and there may have been a slight SNAFU with a divide by zero on the VPU framebuffer.
Arnaud Patard from Mandriva noticed these a long while ago, but now here they are.
BUG: these are temporary hacks, let's try and work out why line_length is 0..
