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.
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.
When kernel_preempt not enable in configure, system bootup hangs
in sdma initialization.
This is caused by sdma initialization waiting for channel0 complete loading
script in queue, and arch_idle happens with action to disable some clocks,
if DDR clock disabled, script loading will failed and SoC hangs.
Solve it by make sure DDR clock is enabled during sdma initialization.
Signed-off-by: Zeng Zhaoming <b32542@freescale.com>
If the internal clock is deadly accurate for the desired mode, that will be used instead
(the accuracy is set to within 1/200th which is well within VESA standards of 1/50th) to
save power.
efikamx changes: for HDMI, try external clock when necessary. For LVDS, don't since there
is some weird clock mess with the binary blob for the LCD panels in the mtl017 driver
which we think is derived from the lack of external clock support in more ancient kernels.
It is fudging the values to both correct some kind of panel EDID bug and also to fix the
potential deviation in clock, but since it's a binary blob it's kind of hard to change.
* bump regulator to 3.3V
* this is safe for all SD cards up to standard
* unfortunately letting it drop to 1.8V is not a workable solution on systems with multiple SD card slots unless they all agree on a low voltage (and currently there is no way for them to communicate this requirement)
3.0V may let most work but in using two cards together it seems that's not enough voltage for
some. Since the regulator can be dropped to 1.8V this won't bode well for two cards with
different capabilities but the regulator probably won't be changed by the current driver in
use. All SD cards regardless of type absolutely must be able to run at 3.3V so this is not a
dangerous change and can only improve the situation, although mileage as always can vary..
Fix system hang due to long time video playback. This issue is only
on i.MX51 platfrom due to changing vpu clock parent in vpu_enable/
disable. Set vpu clock parent to axi_a forever to fix it.
Signed-off-by: Sammy He <r62914@freescale.com>
gpu: pull in some command stream differences from Qualcomm's MSM kernel (might fix some intermittent GPU hangs)
display: enable quick testing of non-mmu operation (hangs X right now)
Optimized version of copy_page() was written with assumption that cache
line size is 32 bytes. On Cortex-A8 cache line size is 64 bytes.
This patch tries to generalize copy_page() to work with any cache line
size if cache line size is multiple of 16 and page size is multiple of
two cache line size.
After this optimization we've got ~25% speedup on OMAP3(tested in
userspace).
There is test for kernelspace which trigger copy-on-write after fork():
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define BUF_SIZE (10000*4096)
#define NFORK 200
int main(int argc, char **argv)
{
char *buf = malloc(BUF_SIZE);
int i;
memset(buf, 0, BUF_SIZE);
for(i = 0; i < NFORK; i++) {
if (fork()) {
wait(NULL);
} else {
int j;
for(j = 0; j < BUF_SIZE; j+= 4096)
buf[j] = (j & 0xFF) + 1;
break;
}
}
free(buf);
return 0;
}
Before optimization this test takes ~66 seconds, after optimization
takes ~56 seconds.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@nokia.com>
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The software division functions never had unwinding annotations
added. Currently, when a division by zero occurs the backtrace shown
will stop at Ldiv0 or some completely unrelated function. Add
unwinding annotations in hopes of getting a more useful backtrace
when a division by zero occurs.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Acked-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
8MB on Smartbook, 32MB on Smarttop. Dynamically allocating the framebuffer for 1920x1080-32 didn't work with the
dynamic method anyway (sigh) due to memory fragmentation.
Also, align framebuffer stride to 32 bytes to fix Z430 acceleration in X
- Reversed ordering in which clocks are disabled. Child clocks should
be disabled before parent (root) clocks.
Signed-off-by: Danny Nold <dannynold@freescale.com>
This fixes some braindead bug in gst_mfw_v4lsink or libipu or some other
userspace code (or maybe a hidden kernel thing) where it cannot work out
what it's doing unless the overlay is /dev/fb2.
Ahmed Ammar originally wrote this for our .35 port but we're backporting it
now in lieu of .35 actually being production ready. Thanks Ahmed!
When the system enters low bus frequency mode by executing the
following operations, the system enters dead loop to check
arm_podf_busy bit:
1. Store the rootfs on SD card.
2. type "echo 8 > /proc/sys/kernel/printk"
3. type "echo 1 > /sys/devices/platform/mxc_dvfs_core.0/enable"
4. type "ifconfig eth0 down"
5. type "echo 1 > /sys/class/graphics/fb0/blank"
6. The system enters low bus frequency mode. And it keeps
to print "ARM_PODF still in busy!!!!"
sys_accept4() was added in kernel 2.6.28, but ARM was not updated
to include it. The number and types of parameters is such that
no ARM-specific processing is needed, so wiring up sys_accept4()
just requires defining __NR_accept4 and adding a direct call in
the syscall entry table.
to modularize these in the grand scheme of things even if this is what Ubuntu
tends to do (it is not as if we have PCI slots and potential for multiple
different options).
MX51 will hang if gpu is running when emi_fast was disabled,
add depends on clock tree to fix it.
Signed-off-by: Zhang Jiejing <jiejing.zhang@freescale.com>
* prep for 2.6.35 and a coexisting "sii9022" driver from Freescale by calling ours "siihdmi" as per the filename
* never put the chip into D3 power off state if we cannot hotplug the chip out of it
* semi-catch setting a mode with a null fb_videomode argument, since this is impossible to perform (there may be other places this needs handling, and there should be a healthy fallback)
* don't perform fb_videomode_to_var for screen blanking, and simplify blanking functions to not require fb_videomode_to_var since they do not actually use them
with very high resolution displays, power management causes serious performance
regressions which we cannot really accept when it comes to video playback
and other features. However, Smartbook display resolution is low enough and
power usage is important enough that we should leave it on for those systems
