Now everything is one big memarena instead of a separate PHYS and EMEM,
and instead of having to micromanage the split between Z160 (always PHYS
here) and GPU (99% of it's allocations come out of EMEM), we give blocks
from the same memory pool.
This should effect some more efficient allocation strategies and allow
Xorg acceleration to proceed with much less movement of data (when it
evicts for low memory in PHYS, it moves it to userspace and uses pixman
to render everything, which is CPU intensive) at the potential cost of
leaving slightly less memory around for the 3D GPU, but userspace apps
using the GPU should be doing better with texture management so as not
to soak up >32MiB of reserved GPU memory needlessly.
Moving away from gsl_memmgr to genalloc is not desirable right now since
the driver requires multiple allocation alignment orders and genalloc can
only really guarantee a minimum alignment (i.e. size of allocation
represented by each bit in the allocation bitmap).
Moving to a dma_alloc_coherent/writecombine-only model also poses a
problem since significant amounts of code expects to be able to find the
"base" GPU memory address and with individual allocations instead of a
pooled area, there is no such thing.
Signed-off-by: Matt Sealey <matt@genesi-usa.com>
* increase from 64MB to 96MB total memory
* after some testing it seems that PHYS can be quite small compared
to EMEM, therefore make the aperture split 16MB/80MB
Mistakenly applied this to 2.6.31 all those years ago while doing
experiments on later kernels. Actually it depends on several other
patches which never got applied.
This reverts commit 9dda27bbe8.
Signed-off-by: Matt Sealey <matt@genesi-usa.com>
It's a bit like Terminus, but more rounded and less harsh on the eyes. Ubuntu has shipped
it as their default console font for years, before they switched to the "Ubuntu" font. Putting
this in the kernel has practically no benefit except to reduce the amount of "glitching"
swapping the built-in kernel console font for a new one halfway through boot when you see the
kernel output on a screen.
Note to gain the benefit of it not swapping the font around again when "consolefont" or
similar service starts, you need to set your font to Uni3-Fixed16.psf.gz or something very
similar.
The AMD gpu driver memory manager is stupid to allocating
a memory block from the first free block. Neither check the
best fit free block. Here just add a little codes to
let allocation to find a best size fitted free block.
To avoid memory fragement.
Signed-off-by: Xinyu Chen <xinyu.chen@freescale.com>
increase max process number to fix gsl_kmod open issue
Signed-off-by: xianzhong <b07117@freescale.com>
Signed-off-by: Richard Liu <r66033@freescale.com>
Conflicts:
drivers/mxc/amd-gpu/include/gsl_buildconfig.h
No userspace users except a reference in libkgsl.so which is never called.
kgsl_device_clock() is left in (but preprocessed out) since it has a fairly
interesting behavior in turning the autogating on and off which is not the
same as turning the actual clocks on and off and could be useful with
modification for further refinement of power management at a later date.
kgsl_device_regwrite() still exists as it is used for a single point in
the driver (reading timestamp for Z430 ringbuffer) dependent on a build
flag. This flag is not enabled but it is not within the scope of this
patch to actually change this (if it is ever enabled it will be quite
obvious what to do - use kgsl_yamato_regwrite directly as it is entirely
Z430-specific)
This is implemented in the "current" userspace libkgsl.so but in fact
since the ioctl is deprecated, there are no users for it and no evidence
of it ever being used in real life can be presented. Therefore we can
just take out the few things it does and it's single-use dependencies.
Such an old version of BFS is not maintained and while it gave us some
noticable benefits, it is not worth dealing with the problems it could
cause.
This reverts commit 469d88e87d.
Such an old version of BFS is not maintained and while it gave us some
noticable benefits, it is not worth dealing with the problems it could
cause.
This reverts commit 4259e4284d.
May be some more cleanups with this, it is not clear which tuners and devices
relate to each other so some drivers may be being built without dependent
tuners - V4L2 is such a mess. Either way this cuts down build time and install
footprint and affects practically nobody.
May be some more cleanups with this, it is not clear which tuners and devices
relate to each other so some drivers may be being built without dependent
tuners - V4L2 is such a mess. Either way this cuts down build time and install
footprint and affects practically nobody.
