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: Eric Anholt <eric@anholt.net>
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=24404
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Eric Anholt <eric@anholt.net>
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: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Jakob Bornecrantz <jakob@vmware.com>
Acked-by: Thomas Hellström <thomas@shipmail.org>
Review-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse "Orange Smoothie" Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <yakui.zhao@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
[anholt: hand-applied due to conflicts]
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>
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>
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=22785
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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>
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>
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>
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]
In commit d2d9f2324, 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>
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>
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>
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 043029655816ed4cfc2ed247020ef97e5d637392
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]
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>
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>
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>
The DPLL calculation logic for 9xx platform is changed in:
commit 652c393a3368af84359da37c45afc35a91144960
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>
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>
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>
The driver requires shmfs as the backing filesystem to handle the buffer
objects, so ensure it is selected if the user chooses to build our
driver.
Fixes: Bug 14662 - Dell E5500 kernel panic with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=14662
The revealing nature of the panic is the NULL function pointer
dereference in read_cache_page_async().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Mateusz Kaduk <mateusz.kaduk@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: stable@kernel.org
For CRT hotplug detect status, we have four test results as blue
channel only, green channel only, both blue and green channel, and
no channel attached. Origin code only marks both blue and green channel
case as connected, but ignore other possible connected states. This one
trys to detect CRT by checking no channel attached case instead.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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>
The existing interface only has a pre-order callback. This change
adds an additional parameter for a post-order callback which will
be more useful for bus scans. ACPICA BZ 779.
Also update the external calls to acpi_walk_namespace.
http://www.acpica.org/bugzilla/show_bug.cgi?id=779
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When the framebuffer driver does not publish detailed timing information
for the current video mode, the correct value for the pixclock field is
zero, not -1.
Since pixclock is actually unsigned, the value -1 would be interpreted
as 4294967295 picoseconds (i.e., about 4 milliseconds) by
register_framebuffer() and userspace programs.
This patch allows X.org's fbdev driver to work.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some architectures compute ->vm_page_prot depending on ->vm_flags, so we
need to update the protections after adjusting the flags.
AFAIK this only affects running X under Xen; without this patch you get
lots of coloured blobs on the screen, or maybe a complete lockup. Or
anything really.
But that still depends on lots of out-of-tree stuff, so I don't think
there are any consequences for anyone else. But it is wrong in principle.
Reported-by: Jan Beulich <JBeulich@novell.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On broken EDID we were reporting vga connector to be disconnected
even if ddc probe did found a monitor. This patch report that the
connector is connected on such case. This allow drm to add a fail
safe mode (800x600 at the time of this patch) thus user can boot
and later add a mode which match its monitor capabilities.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
unused_nodes modification needs to be protected by unused_lock spinlock.
Here is an example of an usage where there is no such protection without
this patch.
Process 1: 1-drm_mm_pre_get(this function modify unused_nodes list)
2-spin_lock(spinlock protecting mm struct)
3-drm_mm_put_block(this function might modify unused_nodes
list but doesn't protect modification with unused_lock)
4-spin_unlock(spinlock protecting mm struct)
Process2: 1-drm_mm_pre_get(this function modify unused_nodes list)
At this point Process1 & Process2 might both be doing modification to
unused_nodes list. This patch add unused_lock protection into
drm_mm_put_block to avoid such issue.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
RS400,RC410,RS480 chipset seems to report a lot of false positive
with load detect on TV output. We haven't yet found a way to make
load detect reliable on those chipset, thus just disable it for TV
output. Would avoid user to experience phantom screen because X
believe there is a monitor connected to the TV output.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes RH bugzilla #527874.
On resume the atom posting wasn't working, however vbe posting was
going fine, after 2 weeks over irc, and 8 hrs with the hardware,
I tracked it down to the memory device table and it access the MC
registers via IIO, it appears the rv515 atom iio table might not
be fully functional, so adding a readback before doing a write
either provides enough delay to make things resume correctly.
Thanks to Peng Huang at Red Hat for coming to Brisbane.
Signed-off-by: Dave Airlie <airlied@redhat.com>
An rv515 laptop I got wouldn't startup with a montior plugged in,
found the proper bug hopefully with us not turning off D2VGA
here when we should.
Signed-off-by: Dave Airlie <airlied@redhat.com>
We did this on the userspace side, but we need a similar fix for the
kernel.
Fixes LP #460664.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
AGP resume was broken since we moved to the new init path,
because we never re-enabled AGP on these systems at resume time.
This patch just calls the AGP resume call which just does the reinit
at resume time like the old path did.
Since AGP is pretty much gpu independant I did it outside
the gpu specific code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This matches the X server's fallback modes when using RANDR 1.2.
See also: http://bugzilla.redhat.com/538761
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We'll still fail the block if it fails the EDID checksum though.
See also: http://bugzilla.redhat.com/534120
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This matches the X server's retry logic. Note that we'll only retry if
we get a DDC response but fail validation; legitimately disconnected
outputs will bomb out early.
See also: http://bugzilla.redhat.com/532957
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Without an allocated colormap, FBIOGETCMAP fails. This would make
programs restore an all-black colormap ("links -g") or fail to work
altogether ("mplayer -vo fbdev2").
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When the framebuffer driver does not publish detailed timing information
for the current video mode, the correct value for the pixclock field is
zero, not -1.
Since pixclock is actually unsigned, the value -1 would be interpreted
as 4294967295 picoseconds (i.e., about 4 milliseconds) by
register_framebuffer() and userspace programs.
This patch allows X.org's fbdev driver to work.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I examined several fbdev drivers and foudn the blanking code in
drm_fb_helper to be wrong. This patch fixes the fbdev blanking to behave
like other fbdev drivers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
