With MMU enabled, there is no need to reserve memory for GPU
at boot time
Signed-off-by: Zhou, Jie <b30303@freescale.com>
(cherry picked from commit 326da1d885108399f4e22d10a8fe341a7a110ffc)
pending indicate the timer has been fired but clock not yet disabled.
This patch fixs the bug that sometimes in irq handle it tries to enable
clock and cause BUG.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
(cherry picked from commit 4b73c7a14fdebbd1240dbb1f5e4efa5b7a65f63c)
seperate interrupt handling and clk_enable for Z160 and Z430
Signed-off-by: Zhou, Jie <b30303@freescale.com>
(cherry picked from commit 7da21af984a50ffb166ab1a088cd2c5d4313537b)
FlashPlayer 11.05 BSP has been fixed to support 32-bit modes so it will function
correctly on Smarttop now. GPU performance hit is still noticable but the extra
colour definition more than makes up for it. Smartbook is not affected.
This reverts commit 1ce3ee7a5a.
* 720p and 1080p are now attempted on DVI monitors on the revelation that some DVI monitors can display real CEA-style modes
* use the fb_find_best_nearest_mode function to better select resolutions and refresh rates
* cleanups
The intent is that if you have a native panel resolution of 1920x1080@60 but this cannot
be displayed, you can find the nearest resolution with the HIGHEST refresh rate (fb_find_nearest_mode
only selects the CLOSEST refresh rate). It also, by virtue of some rather unintended
side effect, picks better matches (1680x1050->1440x900) than find_nearest (1680x1050->1280x1024)
when it comes to widescreen modes.
small optimizations come with this:
* no longer redundantly recalculate refresh rate just to print it when setting resolution
* can use siihdmi_dump_single_modeline to print the modeline for Setting Resolution (more descriptive)
* less variables in use where we don't need var but have mode
* less data copying where we don't need var but have mode (since fb_videomode_to_var sets ~15 fields from mode)
* more const variables passed to functions
*
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.
* use CEA mode 4 (720p60) instead of 19 (720p50) to improve compatibility for fallback mode
* Remove IPU bandwidth warning as this has been worked around to some degree in other parts of the kernel
* Refactor CEA duplicate culling such that on DVI monitors, the CEA mode is removed instead of the IT mode
* Switch siihdmi.useitmodes=1 to force DVI culling behavior on
* Do not enforce lower_margin limit for HDMI on DVI monitors
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).
Due to performance issues, disable 1080p output by default, we will choose a
720p mode first, and if we can't find that, we then try to choose a native
output, and barring that, we default to 1280x720. You should still be able to
add siihdmi.teneighty=1 to your bootargs if you wish to output in 1080p
The root cause is endless GSL_INTR_BLOCK_YDX_CP interrupt.
Apply interrupt status read work around only when yamato started.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
spdif can't playback at system first bootup, write I/O error print out.
This problem is caused by DMA channel not requested before enable spdif dma
trigger register.
Signed-off-by: Zeng Zhaoming <b32542@freescale.com>
The GPU hang when run two cubes together with one video playback.
According to the suggestion from AMD, we'd better not read register
when GPU active, especially for CP block.
Signed-off-by: Zhou, Jie <b30303@freescale.com>
Refresh rate nearness is not calculated or reset when nearest resolution
changes.
This patch resets the refresh rate differential measurement whenever a
new nearest resolution is discovered. This fixes two error cases;
first, wherein the first mode's refresh rate differential is never
calculated and second, when the closest refresh rate from a previous
nearest resolution is erroneously preserved.
Signed-off-by: Andrew Kephart <andrew.kephart@alereon.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
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>
The previous fix of 800x600 fixes the frame buffer issue, but I had the x and
y resolutions switched, and since 640x480 uses less memory, switch to that.
The initial framebuffer is set to 320x240. This seems to cause issues with
plymouth and displaying text, so increase it to default to 800x600. This fixes
the headless boot issue.
* 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
