- 02 Dec, 2009 1 commit
-
-
Zhao Yakui authored
We were always looking for the PORT_IDPB entry. Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net>
-
- 01 Dec, 2009 22 commits
-
-
Eric Anholt authored
This is a sync of a fix I made in the old UMS code. If the BIOS uses the GMBUS and doesn't clear that setup, then our bit-banging I2C can fail, leading to monitors not being detected. Signed-off-by: -
Zhao Yakui authored
Without this, on some boots the TV wouldn't be detected. Testing showed 15ms to be insufficient. https://bugs.freedesktop.org/show_bug.cgi?id=24290 https://bugs.freedesktop.org/show_bug.cgi?id=20785Signed-off-by:
Yan Seiner <yan@seiner.com> Signed-off-by:
-
Kristian Høgsberg authored
Signed-off-by:
Kristian Høgsberg <krh@bitplanet.net> Signed-off-by:
-
Li Peng authored
In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by:
Li Peng <peng.li@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: hand-applied for conflicts with overlay changes] Signed-off-by:
-
Adam Jackson authored
Otherwise, I'd get stuck in a loop where (afaict) output scan would trigger a TV interrupt, which would trigger a scan, etc. TV load detection not being the fastest thing in the world, X would process requests very slowly. https://bugs.freedesktop.org/show_bug.cgi?id=24404Signed-off-by:
Adam Jackson <ajax@redhat.com> Acked-by:
-
Chris Wilson authored
Only update the render-clock on transition from busy to idle and vice versa, or else we burn a significant percentage of the cpu just rewriting the register -- not quite as power-friendly as intended ;-) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Adam Jackson authored
Assume that either the presence of an LVDS entry in the VBT or an ACPI lid device indicates an LVDS device. ACPI lid alone is not sufficient. Signed-off-by:
-
Eric Anholt authored
Signed-off-by: -
Jesse Barnes authored
Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by:
-
Jesse Barnes authored
We don't actually know which frame number the flip will complete on, so userspace needs a specific flip notification to tell it when the last flip completed. Signed-off-by:
-
Kristian Høgsberg authored
Acked-by:
Jakob Bornecrantz <jakob@vmware.com> Acked-by:
Thomas Hellström <thomas@shipmail.org> Review-by:
-
Eric Anholt authored
-
Zhenyu Wang authored
PineView only has 2 ports for LVDS and CRT. Don't enable other ports for it. Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Zhao Yakui authored
Signed-off-by:
-
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:
-
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 authored
This also extends the mutex to cover fbc disabling, which is safe. Signed-off-by:
-
Kristian Høgsberg authored
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:
-
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:
-
- 18 Nov, 2009 6 commits
-
-
Dave Airlie authored
-
Kristian Høgsberg authored
This adds a page flipping ioctl to the KMS API. The ioctl takes an fb ID and a ctrc ID and flips the crtc to the given fb at the next vblank. The ioctl returns immediately but the flip doesn't happen until after any rendering that's currently queued up against the new framebuffer is done. After submitting a page flip, any execbuffer involving the old front buffer will block until the flip is completed. Optionally, a vblank event can be generated when the swap eventually happens. Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Andres Salomon authored
In drm_version, actually check the results from function calls so that we're not potentially passing garbage back to userspace. Signed-off-by:
Andres Salomon <dilinger@collabora.co.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andres Salomon authored
Don't inline it; the compiler can figure it out. Comments added that are based upon my interpretation of the code. Hopefully they're correct. :) Signed-off-by:
-
Andres Salomon authored
There are a few more macros in drmP.h that are unused; DRM_GET_PRIV_SAREA, DRM_ARRAY_SIZE, and DRM_WAITCOUNT can go away completely. Unfortunately, DRM_COPY is still used in one place, but we can at least move it to where it's used. It's an awful looking macro.. [akpm: fix overeagerness] Signed-off-by:
-
Andres Salomon authored
i915_gem_proc.c appears to have been the last user of the DRM_PROC_* macros, and it has gone away. The macros should die as well. Signed-off-by:
-
