mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-12-19 09:04:51 +08:00
1a5ef5b7b4
Function ironlake_wait_panel_off should just wait for the power off delay, while function ironlake_wait_panel_power_cycle should wait for the panel cycle (that's required after we turn the panel off, before we enable it again). The problem is that, currently, ironlake_wait_panel_off is waiting not just for the panel to be off, but also for the power cycle delay and the backlight off delay. This function relies on the PP_STATUS bits 3:0, which are not documented and not supposed to be used. A quick analysis of the values we get while waiting quickly shows that power off is reached while bits 3:0 are still 0x1, and the time it takes to become 0x0 is the power cycle delay. On my system with backlight off delay of 200ms, power down delay of 50ms and power cycle delay of 500ms, this is what I get: - Start waiting with value 0x80000008, timestamp 6.429364. - Jumps to 0xa0000003, timestamp 6.431360 (time waited: 0.001996) - Jumps to 0xa0000002, timestamp 6.631277 (time waited: 0.201913) - Jumps to 0x08000001, timestamp 6.681258 (time waited: 0.251894) - Jumps to 0x00000000, timestamp 7.192012 (time waited: 0.762648) As you can see, ironlake_wait_panel_off is sleeping 760ms instead of the expected 50ms: the first 200ms matches the backlight off delay (which we should already have waited for!), then the 50ms for the real panel off delay, then the 500ms for the panel power cycle. This patch makes is look just at bits 31 and 29:28, which will ignore the panel power cycle. And just to be clear: this saves 500ms on my system every time we disable the panel. But we can still save 200ms more (the backlight off delay) on the next patches. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuougseek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> |
||
|---|---|---|
| .. | ||
| armada | ||
| ast | ||
| bochs | ||
| cirrus | ||
| exynos | ||
| gma500 | ||
| i2c | ||
| i810 | ||
| i915 | ||
| mga | ||
| mgag200 | ||
| msm | ||
| nouveau | ||
| omapdrm | ||
| panel | ||
| qxl | ||
| r128 | ||
| radeon | ||
| rcar-du | ||
| savage | ||
| shmobile | ||
| sis | ||
| tdfx | ||
| tegra | ||
| tilcdc | ||
| ttm | ||
| udl | ||
| via | ||
| vmwgfx | ||
| ati_pcigart.c | ||
| drm_agpsupport.c | ||
| drm_auth.c | ||
| drm_buffer.c | ||
| drm_bufs.c | ||
| drm_cache.c | ||
| drm_context.c | ||
| drm_crtc_helper.c | ||
| drm_crtc.c | ||
| drm_debugfs.c | ||
| drm_dma.c | ||
| drm_dp_helper.c | ||
| drm_drv.c | ||
| drm_edid_load.c | ||
| drm_edid.c | ||
| drm_encoder_slave.c | ||
| drm_fb_cma_helper.c | ||
| drm_fb_helper.c | ||
| drm_flip_work.c | ||
| drm_fops.c | ||
| drm_gem_cma_helper.c | ||
| drm_gem.c | ||
| drm_global.c | ||
| drm_hashtab.c | ||
| drm_info.c | ||
| drm_ioc32.c | ||
| drm_ioctl.c | ||
| drm_irq.c | ||
| drm_lock.c | ||
| drm_memory.c | ||
| drm_mipi_dsi.c | ||
| drm_mm.c | ||
| drm_modes.c | ||
| drm_panel.c | ||
| drm_pci.c | ||
| drm_platform.c | ||
| drm_prime.c | ||
| drm_rect.c | ||
| drm_scatter.c | ||
| drm_stub.c | ||
| drm_sysfs.c | ||
| drm_trace_points.c | ||
| drm_trace.h | ||
| drm_usb.c | ||
| drm_vm.c | ||
| drm_vma_manager.c | ||
| Kconfig | ||
| Makefile | ||
| README.drm | ||
************************************************************
* For the very latest on DRI development, please see: *
* http://dri.freedesktop.org/ *
************************************************************
The Direct Rendering Manager (drm) is a device-independent kernel-level
device driver that provides support for the XFree86 Direct Rendering
Infrastructure (DRI).
The DRM supports the Direct Rendering Infrastructure (DRI) in four major
ways:
1. The DRM provides synchronized access to the graphics hardware via
the use of an optimized two-tiered lock.
2. The DRM enforces the DRI security policy for access to the graphics
hardware by only allowing authenticated X11 clients access to
restricted regions of memory.
3. The DRM provides a generic DMA engine, complete with multiple
queues and the ability to detect the need for an OpenGL context
switch.
4. The DRM is extensible via the use of small device-specific modules
that rely extensively on the API exported by the DRM module.
Documentation on the DRI is available from:
http://dri.freedesktop.org/wiki/Documentation
http://sourceforge.net/project/showfiles.php?group_id=387
http://dri.sourceforge.net/doc/
For specific information about kernel-level support, see:
The Direct Rendering Manager, Kernel Support for the Direct Rendering
Infrastructure
http://dri.sourceforge.net/doc/drm_low_level.html
Hardware Locking for the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
A Security Analysis of the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/security_low_level.html