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.
additional minor changes:
* rename PAGE_SIZE register MH_PAGE_SIZE in yamato/22/yamato_genreg.h (although this is an unused debug file so far)
* remove references to stdio files in gsl_debug_pm4.c (will come in handy later)
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)
* mutex, events, sleeps, process id unabstracted
* defines for function types (inline, extern) unabstracted
* defines for debug assert change name (KOS_ASSERT -> DEBUG_ASSERT) and left disabled
* driver now warns, if logging is enabled, that interruptible mutex locks are interrupted (which never happens in reality but it fixes a warning)
* remove fine grained locking "feature" since it's not enabled (and Qualcomm's public driver does not even implement it)
* refine mutex initialization where it's still present - don't try and allocate mutex structures where they're always used, just make them parts of the structure (struct mutex * -> struct mutex)
* whitespace police
