mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-08-05 16:54:27 +00:00
b2cabb0e1d
Yeah, big patch but I couldn't come up with a neat idea of how to split it up further, that wouldn't break dpms on cloned configs somehow. But the changes in dvo/sdvo/crt are all pretty much orthonogal, so it's not too bad a patch. These are the only encoders that support cloning, which requires a few special changes compared to the previous patches. - Compute the desired state of the display pipe by walking all connected encoders and checking whether any has active connectors. To make this clearer, drop the old mode parameter to the crtc dpms function and rename it to intel_crtc_update_dpms. - There's the curious case of intel_crtc->dpms_mode. With the previous patches to remove the overlay pipe A code and to rework the load detect pipe code, the big users are gone. We still keep it to avoid enabling the pipe twice, but we duplicate this logic with crtc->active, too. Still, leave this for now and just push a fake dpms mode into it that reflects the state of the display pipe. Changes in the encoder dpms functions: - We clamp the dpms state to the supported range right away. This is escpecially important for the VGA outputs, where only older hw supports the intermediate states. This (and the crt->adpa_reg patch) allows us to unify the crt dpms code again between all variants (gmch, vlv and pch). - We only enable/disable the output for dvo/sdvo and leave the encoder running. The encoder will be disabled/enabled when we switch the state of the entire output pipeline (which will happen right away for non-cloned setups). This way the duplication is reduced and strange interaction when disabling output ports at the wrong time avoided. The dpms code for all three types of connectors contains a bit of duplicated logic, but I think keeping these special cases separate is simpler: CRT is the only one that hanldes intermediate dpms state (which requires extra logic to enable/disable things in the right order), and introducing some abstraction just to share the code between dvo and sdvo smells like overkill. We can do that once someone bothers to implement cloning for the more modern outputs. But I doubt that this will ever happen. v2: s/crtc/crt/_set_dpms, noticed by Paulo Zanoni. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> |
||
|---|---|---|
| .. | ||
| dvo.h | ||
| dvo_ch7xxx.c | ||
| dvo_ch7017.c | ||
| dvo_ivch.c | ||
| dvo_ns2501.c | ||
| dvo_sil164.c | ||
| dvo_tfp410.c | ||
| i915_debugfs.c | ||
| i915_dma.c | ||
| i915_drv.c | ||
| i915_drv.h | ||
| i915_gem.c | ||
| i915_gem_context.c | ||
| i915_gem_debug.c | ||
| i915_gem_dmabuf.c | ||
| i915_gem_evict.c | ||
| i915_gem_execbuffer.c | ||
| i915_gem_gtt.c | ||
| i915_gem_stolen.c | ||
| i915_gem_tiling.c | ||
| i915_ioc32.c | ||
| i915_irq.c | ||
| i915_reg.h | ||
| i915_suspend.c | ||
| i915_sysfs.c | ||
| i915_trace.h | ||
| i915_trace_points.c | ||
| intel_acpi.c | ||
| intel_bios.c | ||
| intel_bios.h | ||
| intel_crt.c | ||
| intel_ddi.c | ||
| intel_display.c | ||
| intel_dp.c | ||
| intel_drv.h | ||
| intel_dvo.c | ||
| intel_fb.c | ||
| intel_hdmi.c | ||
| intel_i2c.c | ||
| intel_lvds.c | ||
| intel_modes.c | ||
| intel_opregion.c | ||
| intel_overlay.c | ||
| intel_panel.c | ||
| intel_pm.c | ||
| intel_ringbuffer.c | ||
| intel_ringbuffer.h | ||
| intel_sdvo.c | ||
| intel_sdvo_regs.h | ||
| intel_sprite.c | ||
| intel_tv.c | ||
| Makefile | ||