- 01 Dec, 2009 9 commits
-
-
Zhao Yakui authored
Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Zhao Yakui authored
We not only check the device type, but also check the addin_offset. If the addin_offset is zero, it won't be initialized. Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Zhao Yakui authored
Use the child device array to decide whether the given DP output should be initialized. If the given DP port can't be found in child device array, it is not present and won't be initialized. Signed-off-by:
-
Zhao Yakui authored
Use the child device array to decide whether the given HDMI output should be initialized. If the given HDMI port can't be found in child device array, it is not present and won't be initialized. Signed-off-by:
-
Zhao Yakui authored
On some laptops there is no HDMI/DP. But the xrandr still reports several disconnected HDMI/display ports. In such case the user will be confused. >DVI1 disconnected (normal left inverted right x axis y axis) >DP1 disconnected (normal left inverted right x axis y axis) >DVI2 disconnected (normal left inverted right x axis y axis) >DP2 disconnected (normal left inverted right x axis y axis) >DP3 disconnected (normal left inverted right x axis y axis) This patch set is to use the child device parsed in VBT to decide whether the HDMI/DP/LVDS/TV should be initialized. Parse the child device from VBT. The device class type is also added for LFP, TV, HDMI, DP output. https://bugs.freedesktop.org/show_bug.cgi?id=22785Signed-off-by:
-
Kristian Høgsberg authored
Otherwise the chip may scribble over free memory. Signed-off-by:
Kristian Høgsberg <krh@bitplanet.net> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Kristian Høgsberg authored
This also extends the mutex to cover fbc disabling, which is safe. Signed-off-by:
-
Kristian Høgsberg authored
Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Shaohua Li authored
if no VBT is present, crt_ddc_bus will be left at 0, and cause us to use that for the GPIO register offset. That's never a valid register offset, so let the "undefined" value be 0 instead of -1. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
- 30 Nov, 2009 5 commits
-
-
Chris Wilson authored
In commit d2d9f232, the guard for a valid video mode was removed. This caused the regression: kernel crash during kms graphic boot on Intel GM4500 platform https://bugzilla.redhat.com/show_bug.cgi?id=540218 This patches changes the logic slightly not to rely on a coupled variable, but to just check whether the video_modes is valid before dereferencing. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
When switching to interruptible sleeps in the overlay code, I've forgotten to recover from interruptions at one site. This resulted in the overlay still running when it should have been switched off. This in turn caused a hang on resume because it tried to disable the (not-running) overlay in preparation for the resume modeset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24980 Tested-by: maximlevitsky@gmail.com Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
I've suspected some bug there wrt to suspend, but that was not the case. Clean up the code anyway. Signed-off-by:
-
Shaohua Li authored
HW guys have an evaluation about the impact about EOS, and say the impact is quite small, so they have removed EOS detection support. This patch removes EOS feature. revert commit 04302965 directly reverting it gives a hunk error, so please use this one. Signed-off-by:
-
Shaohua Li authored
20ms delay is quite big and the routine isn't called in atomic context. better use msleep to let other tasks run. This can reduce cpu time used by Xorg, so potentially boost boot. Signed-off-by:
-
- 25 Nov, 2009 6 commits
-
-
Shaohua Li authored
In failure path, make sure encoder is cleaned up, otherwise there is a kernel oops. Signed-off-by:
-
Zhenyu Wang authored
In disable sequence, all output ports on PCH have to be disabled before PCH transcoder, but LVDS port was left always enabled. This one fixes that by disable LVDS port properly during pipe disable process, and resolved stability issue seen on Ironlake. Also move panel fitting disable time just after pipe disable to align with the spec. Signed-off-by:
-
Zhao Yakui authored
The DPLL calculation logic for 9xx platform is changed in: commit 652c393a Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Aug 17 13:31:43 2009 -0700 drm/i915: add dynamic clock frequency control Maybe we will get the different M/N/P combination with that by using the previous dpll calculation logic. So restore the DPLL calculation logic for 9xx platform. Signed-off-by:
-
Zhao Yakui authored
Enumerate the LVDS panel timing info entry list in VBT to check whether the LVDS downclock is found. If found, the downclock is also used to switch dynamically between low and high frequency for LVDS. Signed-off-by:
-
Zhao Yakui authored
If more than one mode with the same resolution defined in EDID has different refresh rate, it is thought that the downclock is found for LVDS. We will program the different FPx0/1 register so that we can select dynamically between the low and high frequency. On the g4x platform we will use the CxSR feature to switch the different refresh rate if the LVDS downclock feature is supported. Signed-off-by:
-
Eric Anholt authored
Execbufs involve quite a bit of payload, to the extent that cache misses show up in the profiles here, and a suspicion that some of those cachelines may get evicted and then reloaded in the subsequent copy. This is still abstracted like drm_calloc_large since we want to check for size overflow, and because we want to choose between kmalloc and vmalloc on the fly. cairo's interface for malloc-with-calloc's-args was used as the model. Signed-off-by:
-
- 05 Nov, 2009 20 commits
-
-
Eric Anholt authored
-
Daniel Vetter authored
Somehow the case for G33 got dropped while porting from ums code. This made a 400MHz chip into a 133MHz one which resulted in the unnecessary enabling of double wide pipe mode which in turn screwed up the overlay code. Nothing else (than the overlay code) seems to be affected. This fixes fdo.org bug #24835 Signed-off-by:
-
Zhenyu Wang authored
Enable display hotplug irqs from Ibex Peak (PCH). Signed-off-by:
-
Zhao Yakui authored
Add the support of ACPI opregion on Ironlake so that the backlight brightness can be adjusted by using ACPI interface >/sys/class/backlight/acpi_video0/brightness Signed-off-by:
-
Jesse Barnes authored
Need to calculate the SR watermark and enable it. Signed-off-by:
-
Kristian Høgsberg authored
Signed-off-by:
Kristian Høgsberg <krh@redhat.com> Signed-off-by:
-
Chris Wilson authored
Create a /debug/dri/%d/i915_wedged file to display the current wedged status, and to enable setting that value. On an i965, this will also trigger a GPU reset. Useful in order to attempt to recover from some error conditions that are not currently caught by the automatic hang detection code. Signed-off-by:
-
Chris Wilson authored
Our work is serialised so allocating per-cpu workqueues is overkill and a waste of resources. Signed-off-by:
-
Zhao Yakui authored
Signed-off-by:
-
Eric Anholt authored
Signed-off-by: -
Zhao Yakui authored
Replace the DRM_DEBUG with DRM_DEBUG_KMS in output device code. Signed-off-by:
-
Zhao Yakui authored
Replace the DRM_DEBUG with DRM_DEBUG_DRIVER in generic i915 driver. Then the debug info can be obtained by adding the boot option of "drm.debug=0x02". At the same time the debug info in increase/decrease clock is also printed by using DRM_DEBUG_DRIVER instead of DRM_DEBUG_KMS. Signed-off-by:
-
Daniel Vetter authored
I've simply overlooked one case in the conversion to interruptible sleeps. Rectify this. Also delete a leftover debug printk. Signed-off-by:
-
Daniel Vetter authored
It's not needed anymore. Signed-off-by:
-
Daniel Vetter authored
At least for the common case of userspace ioctls. When doing a modeset operation, the wait is still uninterruptible. But considering that failing to turn off the overlay when switching off the crtc it's running on hangs the chip, it doesn't complicate matters _very_ much. There's just an unkillable X in addition to a black screen. BUG() about it and explain in the code. Signed-off-by:
-
Daniel Vetter authored
As long as the gpu can keep up, neither the cpu (waiting for gpu) nore the gpu (waiting for vblank to do an overlay flip) stalls. Signed-off-by:
-
Daniel Vetter authored
Now that the cache flushing of the memory based overlay regs works, we can safely switch off the overlay. Beforehand it was only disabled (like in userspace). Signed-off-by:
-
Daniel Vetter authored
This implements intel overlay support for kms via a device-specific ioctl. Thomas Hellstrom brought up the idea of a general ioctl (on dri-devel). We've reached the conclusion that such an infrastructure only makes sense when multiple kms overlay implementations exists, which atm don't (and it doesn't look like this is gonna change). Open issues: - Runs in sync with the gpu, i.e. unnecessary waiting. I've decided to wait on this because the hw tends to hang when changing something in this area. I left some dummy functions as infrastructure. - polyphase filtering uses a static table. - uses uninterruptible sleeps. Unfortunately the alternatives may unnecessarily wedged the hw if/when we timeout too early (and userspace only overloaded the batch buffers with stuff worth a few secs of gpu time). Changes since v1: - fix off-by-one misconception on my side. This fixes fullscreen playback. Changes since v2: - add underrun detection as spec'ed for i965. - flush caches properly, fixing visual corruptions. Changes since v4: - fix up cache flushing of overlay memory regs. - killed require_pipe_a logic - it hangs the chip. Tested-By: diego.abelenda@gmail.com (on a 865G) Signed-off-by:
-
Daniel Vetter authored
It is identical to I85X. Use that one instead. Signed-off-by:
-
Daniel Vetter authored
This just waits until the hw passed the current ring position with cmd execution. This slightly changes the existing i915_wait_request function to make uninterruptible waiting possible - no point in returning to userspace while mucking around with the overlay, that piece of hw is just too fragile. Also replace a magic 0 with the symbolic constant (and kill the then superflous comment) while I was looking at the code. Signed-off-by:
-
