Otherwise we may end up returning a false positive if some other output & crtc
are on, but not the one in question, again leading to hangs.
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Now that swapbuffers does a scanline wait to avoid tearing, it's
important to take into account the CRTC status to avoid hangs. If we
do a scanline wait when the CRTC is off (due to DPMS for example) we'll
hang the GPU. So add some code to check the CRTC DPMS status to the
i830_covering_crtc function, returning NULL if none of the covering
CRTCs are actually active. KMS vs UMS logic is hidden in new i830*
functions, cleaning up both DRI2 & video paths a bit.
Fixes fdo bug #22383.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Until we get triple buffering, we'll want this so users can avoid taking a
performance hit on apps that render slower than the refresh rate.
Fixes fdo bug #22234.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Apparently the proper way to do this is to use the LFP data pointer block to figure out the LFP data block entry size, then use that plus the panel index to calculate an offset into the LFP data block array.
Fixes fdo bug #19450.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Don't the change the blank/vsync width while doing LVDS scaled modes.
And use the border instead of border minus one.
At the same time, make sure the horizontal border and hsync are even for
the LVDS that works in dual-channel mode. So both horizontal border and hsync
start are also changed to be even, even for the LVDS in single-channel
mode.
https://bugs.freedesktop.org/show_bug.cgi?id=20951
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
We detect TV connect status by setting DAC voltage level override
values as 0.7 voltage for DAC_A/B/C. The corresponding 2-bits shold be 0x2,
In order correctly to set last bit as 0, at first we must clean it.
It fixed freedesktop.org bug #21204
Signed-off-by: Ma Ling <ling.ma@intel.com>
We detect HDMI output connection status by writing to HOT Plug Interrupt
Detect Enable bit in PORT_HOTPLUG_EN. The behavior will generate an specified
interrupt, which is caught by audio driver, but during one detection driver
set all Detect Enable bits of HDMIB, HDMIC and HDMID, which generate wrong
interrupt signals for current output, according to the signals audio driver
misunderstand device status. The patch intends to handle corresponding output
precisely.
It fixed fredesktop bug #21371
Signed-off-by: Ma Ling <ling.ma@intel.com>
Add quirk to solve issue with black screen and hang occuring after closing the
lid with attached external monitor, on Dell Mini.
Fixes fdo bug #21960.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
When the slave address is found for the SDVO port, the SDVO device will
be initialzied.
When the slave address is not found for the SDVO port, it will return
the slave address by using the following flowchart:
a. If the SDVO device info is found for another SDVO port, it will return
the slave address that is not used. For example: if 0x70 is used, then 0x72
is returned.
b. If no SDVO device info is found for another SDVO port, it will return
0x70 for SDVOB and 0x72 for SDVOC.
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The general definition block contains the child device tables, which include
the child device info. For example: device slave address, device dvo port,
device type.
We will get the info of SDVO device by parsing the general definition blocks.
Only when a valid slave address is found, it is regarded as the SDVO device.
And the info of DVO port and slave address is recorded.
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The size of general definition block varies on different platform/machines.
In such case the number of child device is also different.
And it will be better to get the number of child device in general definition
block dynamically.
The number of child device can be calculated by the following formula:
(block_size - block_header_size) /
sizeof( struct child_device_config)
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Under KMS, directRenderingType will get set to DRI_NONE during driver
initialization. When the first batch buffer is allocated, as
directRenderingType is DRI_NONE, the GEM bufmgr would get trashed as
intel_batch_init called a fake-bufmgr specific function.
Signed-off-by: Keith Packard <keithp@keithp.com>
If we don't find xext.pc, disable xvmc instead of failing configure
Also add dependencies on xfixes and dri2proto (src/xvmc/dri2.h includes
<X11/extensions/Xfixes.h> and <X11/extensions/dri2tokens.h>).
In some configurations, it's possible to wait for a scanline outside of
a given CRTC range. Make sure that can't happen to fix multihead cases
with dead space.
Fixes fdo bug #22203.
Signed-off-by: Lukasz Kurylo <Lukasz.Kurylo@gmail.com>
Use pci resource size instead, which will get the correct MMIO range.
New chipset uses obviously larger MMIO range.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Desktop and mobile version of new chipsets are added.
Also do memory config like Intel 4 series chipset.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
GEM pads pixmaps to 512 byte stride and backs them with a kernel side
buffer objects. We typically don't render out of glyph pictures, so
we're incurring a lot of overhead per glyph by allocating a GEM pixmap
per glyph. By looking at the usage hint, we can fall back to
fbCreatePixmap for pixmaps backing glyph pictures, which gives us
a nice tight malloced pixmap. The fast path for text rendering is
compositing from the glyph cache pixmap to the destination, which
shouldn't be significantly affected.
Quick bit of testing:
(firefox-20090601)
xlib-rgba-before 384512.49: 1.01x
xlib-rgba-after 389633.94: 1.00x
The difference being within the margin of error for the benchmark.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Parse SDVO LVDS option section, then according to panel type
fetch fixed mode line from SDVO LVDS DTDS section .
Signed-off-by: Ma Ling <ling.ma@intel.com>
We have two approaches for VGA detections: hot plug detection for 945G onwards
and load pipe detection for Pre-945G. load pipe detection will get one free
pipe ,and set border color as red and blue, then check CRT status by
swf register. Because pipe registers in hires mode are double buffered,
once set force border bit in pipeconf register, we have to wait for
a vblank until it is effective, otherwise result is unstable.
It fixed freedesktop bug #20463
Signed-off-by: Ma Ling <ling.ma@intel.com>
We use force CRT detect trigger bit(1 << 3) to detect VGA in hot plug mode,
which triggers a CRT hotplug/unplug detection cycle independent of the
interrupt enable bit(1 << 9), so keep bit 9.
And although spec says CRT_HOTPLUG_ACTIVATION_PERIOD_64(1 << 8) is only useful
for mobile platform, it is also required to detect vga on G4x platform correctly.
Tested the patch on G45/G43/Q45 platforms with no regressions
It fixed freedesktop.org bug #21120 and part of bug #21210.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Akin to the Xv code, wait for the scanline to be outside the range to be
copied by the DRI2 CopyRegion hook.
Fixes fdo bug #20664.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This reverts commit 4653a7db62.
Eric was getting a little too ambitious about our brave, new world.
We do still want the driver to work with old, non-GEM kernels
after all.
We don't have anything to do with the DRM unless it's GEM-enabled, unless
we were to support GEM-but-not-DRI2, which doesn't seem useful.
Compilation fixes by Carl Worth <cworth@cworth.org>
This will let us configure the server from start to finish with the
most pertinent information available (KMS vs UMS, DRI2 vs non-DRI). Also,
we now close the DRI2 fd at terminate, which we didn't before.
This duplicates some code from DRI1 for getting a master FD like I'd done in
DRI2, but given that we weren't loading DRI1 ourselves, this is also a
bogosity cleanup, and avoids allocating the extra DRI1 private.
The basic problem is that software fallbacks will do single instructions that
copy from one GTT-mapped BO into another GTT-mapped BO. If we can't get both
of them bound simultanously, we fault one in, retry the instruction, fault the
other in (kicking out #1), retry the instruction, fault #1 back in
(kicking out #2), etc.
Note that we'll still get into a nasty spot if you do a composite operation
with a mask where all 3 are big-but-less-than-half-available-aperture, where
you'll thrash. It at least means you'll make progress, though, since each
instruction will only be operating on two BOs at at time, and the situation
seems unlikely.
Bug #20152 (3/3)
Jesse Barnes
Alan Coopersmith
Zou Nan hai
Zhao Yakui
ling.ma@intel.com
Bryce Harrington
Li Peng
Keith Packard
Julien Cristau
Lukasz Kurylo
Zhenyu Wang
Carl Worth
Kristian Høgsberg
Xiang, Haihao
root
Eric Anholt
Adam Jackson
Li Shao Hua