Signed-off-by: Rebecca Schultz <rschultz@google.com>
pmem: Use the thread group leader insted of the current thread.
Instead of keeping track of the current thread, use the thread group leader
Signed-off-by: Rebecca Schultz <rschultz@google.com>
pmem: Add some apis to reference and flush pmem files by file struct
The api to refer to pmem files by fd should be depricated, it can
cause problems if a processes fd table changes while the kernel is processing
data in a pmem file. This change adds the safer api.
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
pmem: Remove unused depricated fd api to pmem.
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
pmem: Remove error message when calling get_pmem_addr
This call is used from the mdp driver to determine if the memory
is in pmem or in the fb. We will encounter this case during normal operation
so this error message should be removed.
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
pmem: Add include sched.h to fix compile errors
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
pmem: remove HW3D_* ioctls
Signed-off-by: Dima Zavin <dima@android.com>
pmem: Expose is_pmem_file to the in-kernel users.
Signed-off-by: Dima Zavin <dima@android.com>
pmem: Make the exposed functions be noops if CONFIG_ANDROID_PMEM is not set.
Signed-off-by: Dima Zavin <dima@android.com>
misc: pmem: don't flush if file was opened with O_SYNC
Change-Id: I067218658a0d7f7ecc1fe73e9ff6b0c3b3054653
Signed-off-by: Dima Zavin <dima@android.com>
pmem: Add cache flush ioctl for pmem buffers
Change-Id: I9156bad829e8c65087f122b48cc57638902fab12
Signed-off-by: Dima Zavin <dima@android.com>
Allow multiple pmem master mmap()s.
Signed-off-by: Jamie Gennis <jgennis@google.com>
Change-Id: Icbe619c92e0ebb391f0a93f81937705452a67d87
pmem: convert data_list_sem to a mutex
Also rename a function that now conflicts with a new
define in asm/pgtable.h
Change-Id: I4798048cb8dece1bc03604e7d0b03d86e0c0ef7f
Signed-off-by: Dima Zavin <dima@android.com>
Conflicts:
drivers/misc/Kconfig
drivers/misc/Makefile
When connecting usb or the charger the device would often go back to sleep
before the charge led and screen turned on.
Change-Id: I01def6d86ddece0d4e31d2a91d176ed0975b6b9d
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Conflicts:
drivers/power/power_supply_core.c
Since wall time can jump backwards, it cannot be used to determine if one
event occured before another or for how long a key was pressed.
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Allows userspace code to process input events while
the device appears to be asleep.
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Conflicts:
drivers/input/evdev.c
When we resume we only know how many whole seconds has elapsed.
These errors would accumulate in delta. We now only set the delta
if it would change by more than two seconds. If we drift back by
by more than a second add one in resume.
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Drivers can now create alarms that will use an hrtimer while the
system is running and the rtc to wake up from suspend.
Signed-off-by: Arve Hjønnevåg <arve@android.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.
* 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)
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.
