- 01 Dec, 2009 7 commits
-
-
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 <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Zhao Yakui <yakui.zhao@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Eric Anholt <eric@anholt.net>
-
Kristian Høgsberg authored
This also extends the mutex to cover fbc disabling, which is safe. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Kristian Høgsberg authored
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> [anholt: clarified the commit message a bit]
-
- 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: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Zhenyu Wang <zhenyu.z.wang@intel.com> [ickle: Actually reference the correct bug report] Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Eric Anholt <eric@anholt.net>
-
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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <shaohua.li@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> [anholt: fixed up commit message for update that the feature's really gone]
-
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: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
- 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: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <yakui.zhao@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <yakui.zhao@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Zhao Yakui <yakui.zhao@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Eric Anholt <eric@anholt.net>
-
- 05 Nov, 2009 22 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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Zhenyu Wang authored
Enable display hotplug irqs from Ibex Peak (PCH). Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Zhao Yakui <yakui.zhao@intel.com> Tested-by: Zhao Yakui <yakui.zhao@intel.com> [zhenyuw: cleanups, fix typo for checking GSE irq and convert to current irq handling logic.] Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Jesse Barnes authored
Need to calculate the SR watermark and enable it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Kristian Høgsberg authored
Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Chris Wilson authored
Our work is serialised so allocating per-cpu workqueues is overkill and a waste of resources. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Zhao Yakui authored
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Eric Anholt authored
Signed-off-by: Eric Anholt <eric@anholt.net>
-
Zhao Yakui authored
Replace the DRM_DEBUG with DRM_DEBUG_KMS in output device code. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Daniel Vetter authored
It's not needed anymore. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
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 <daniel.vetter@ffwll.ch> [anholt: Resolved against the MADVISE ioctl going in before this one] Signed-off-by: Eric Anholt <eric@anholt.net>
-
Daniel Vetter authored
It is identical to I85X. Use that one instead. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [anholt: fix conflicts against the display function pointer stuff] Signed-off-by: Eric Anholt <eric@anholt.net>
-
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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Daniel Vetter authored
I've wasted half a day hunting a bug that could easily be spotted by gcc. Prevent this from reoccurring. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Jesse Barnes authored
Render standy allows the GPU to power down the render unit when idle. In order for this to work, it needs a page of graphics memory to save state. This patch allocates that page and enables the feature on supported chipsets. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
-