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.
* improve clock accuracy check from 1/16 to 1/200 of intended clock rate
* properly round pixel clock to the parent and not against a hardcoded 150MHz max rate
* properly fix di external clock divisor to a maximum of 8
Since there isn't a noticable effect on display compatibility in higher values, we may as well not waste time idling for something that already has taken effect.
Net benefit of this is that DVI monitors, due to not requiring an InfoFrame drain time, now change resolution much, much faster than HDMI monitors (which may now take about 50ms longer, but this isn't noticable in benchmarks)
* siihdmi.dvi=1 switch for kernel command line (and sysfs) which will force an HDMI display into DVI sink mode (will disable audio!)
* EDID handling reworked to better match the operational mode described in the manual, and to streamline the DDC bus locking (it will now lock the bus once instead of twice, and get all EDID data while the lock is held instead of trying twice once it realises there is an extension
* more consistently set the DVI/HDMI operational mode every type the System Control register is touched
* set Power Control to "D0" after setting the DVI/HDMI operational mode as a 0x00 write here seems to help latch the previous register set
* misc: renumber "steps" to enable display to match the manual
* only delay for InfoFrame drain time if it's an HDMI sink (DVI sinks do not get sent InfoFrames so there is nothing to drain)
* add a "resolution stabilization" delay (currently 255ms, manual states 50-500ms) in case the IPU is not sending data yet (will be ratcheted down later to make resolution changing faster)
HDMI compatibility has improved somewhat (no more pink lines) and as far as tested with all the test monitors, no breakages have occurred.
Monitor resolution change time has increased due to the stabilization delay, which may not actually be necessary as by the time we have gotten to this point to change resolution it could be assumed the notification through the Linux framebuffer subsystem is more than long enough. Your mileage may vary.
* 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)
* do not power down the chip just because the monitor is still in standby and waking up
* EDID will be requested but if the monitor has not properly powered yet then it will give a default mode
* also fix the symlink error (try remove device vs. make new phys-link, both are phys-link now, so it will remove the phys-link attribute before recreating it)
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>
Essentially where before we simply picked a 1080p or 720p mode and then fall back to
EDID preferred mode, now we basically do
if (teneighty)
if (native is 1680x1050, 1440x900) return native
if (1080p) return 1080p
if (seventwenty)
if (native is 1366x768, 1360x768, 1280x768, 1280x800, 1024x768) return native
if (720p) return 720p
fallback: use preferred mode
This means far more "close to 720p" modes for plasmas are used instead of 720p with
a scaler, and for monitors that SAY they can do 1080p (but it's actually scaled down
or overscanned because native res is smaller) then use panel native instead for a
much better experience.
Tested on every monitor we have available and matches native res on most, and the
best mode fallback is used as per previous mode selection on the few fringe cases
left. Experience is crisper displays.
Note that if teneighty is selected, the modes returned absolutely will suck at video
playback performance - mfw_v4lsink will fail to fullscreen at anything above 1366x768
due to lack of bandwidth. 1440x900 may work if you're lucky. mfw_xvimagesink simply
cannot convert YV12 to YUY2 fast enough to work (and double buffering seems broken).
It is therefore still disabled by default.
Also: add a siihdmi.vic= option, so you can give it any CEA VIC from the CEA spec
(look for an entry in drivers/video/cea861_modes.c and use that number) if it's
still in the modelist.
Requesting specific video modes requires some duplication of option parsing and I
feel that's really not going to give people a reasonable experience, so it's not
being done right now. Investigation into exactly what the mitigating factor for
a lower_margin < 2 actually working is underway so we can cull less modes and give
people much better monitor experience once we get XRandR working.
