IGDNG mobile chip's LVDS data block removes panel fitting
register definition. So this fixes offset for LVDS timing
block parsing. Thanks for Michael Fu to catch this.
Signed-off-by: NZhenyu Wang <zhenyu.z.wang@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

As of 52dc7d32, we could leave an old
linear GTT mapping in place, so that apps trying to GTT-mapped write in
tiled data wouldn't get the fence added, and garbage would get displayed.
Signed-off-by: NEric Anholt <eric@anholt.net>

As we call unmap_mapping_range() twice in identical fashion, refactor
and attempt to explain why we need to call unmap_mapping_range().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

In KMS mode we now use the normal mode-setting paths to set the modes
back to the current configuration, so we don't need to also run the more
limited non-KMS implementation of modesetting for resume.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Restore the modeset for every activated CRTC in course of resume.
This is realized by calling the function of drm_helper_resume_force_mode.
Note: it is meaningful only for the KMS mode.

https://bugs.freedesktop.org/show_bug.cgi?id=21719
https://bugs.freedesktop.org/show_bug.cgi?id=21708
https://bugs.freedesktop.org/show_bug.cgi?id=22285
https://bugs.freedesktop.org/show_bug.cgi?id=22263Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

This is seen on some G41 systems, where the BIOS will consume all but
a few KB of the aperture.  This should be bad for all operating systems, as
it means that the OS can't dynamically manage memory between graphics and
the rest of the system, and OSes that did static memory management
statically add memory in addition to the BIOS allocation anyway.  So, instead
of working around it, just fail out verbosely.

fd.o bug #21574
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NIan Romanick <ian.d.romanick@intel.com>

On some boxes the mobile chipset is used and there is no LVDS device. In such
case we had better not initialize the LVDS output device so that one pipe can
be used for other output device. For example: E-TOP.

But unfortunately the LVDS device is still initialized on the boxes based on
mobile chipset in KMS mode. It brings that this pipe occupied by LVDS can't be
used for other output device.

After checking the acpidump we find that there is no LID device on such boxes.
In such case we can use the LID device to decide whether the LVDS device should
be initialized.

If there is no LID device, we can think that there is no LVDS device. It is
unnecessary to initialize the LVDS output device.
If there exists the LID device, it will continue the current flowchart.

Maybe on some boxes there is no LVDS device but the LID device is found. In
such case it should be added to the quirk list.

http://bugs.freedesktop.org/show_bug.cgi?id=21496
http://bugs.freedesktop.org/show_bug.cgi?id=21856
http://bugs.freedesktop.org/show_bug.cgi?id=21127Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[anholt: squashed in style fixups]
Signed-off-by: NEric Anholt <eric@anholt.net>

Make this consistent with the unlock statement. Also fix a
minor typo in debugfs formatting
Signed-off-by: NBen Gamari <bgamari.foss@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This is quite useful for verifying that objects are actually mapped when
they need to be.
Signed-off-by: NBen Gamari <bgamari.foss@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This wasn't even used as far as I could tell and will only confuse
people (like me).
Signed-off-by: NBen Gamari <bgamari.foss@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Usually crt mainly get modes via GPIOA ports.
However on G4X platform we need to probe possible
ports for DVI-I, which could be wired to GPIOD,
then fetch our desired EDID, i.e on DG45ID platform
we successfully fetch EDID by GPIOD port.

It fixed freedesktop.org bug #21084
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

For some reason, the DP clocks were based off a 100MHz reference instead of
the standard 96MHz reference. This caused some DP monitors to fail to lock
to the signal.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Convert many printk calls to DRM_DEBUG calls to reduce kernel log noise
for normal activities. Switch other printk calls to DRM_ERROR or DRM_INFO.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

We are seeing compilation failures on i386 in some environments due
to an undefined reference as below:

    ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!

This is generated due to a raw 64 bit divide in the i915 driver.  Fix up
this raw divide.
Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Currently we implemented basic sdvo lvds function,
But except for sdvo lvds fixed mode, we can not switch
to other modes, otherwise display get black. The patch
handle three operations to enable sdvo lvds. At first
duplicate sdvo fixed mode for adjustment, then according
to fixed mode line valid all modes, at last adjust input
mode to fit our requirement.

Acked by Li Peng <peng.li@linux.intel.com>
Signed-off-by: NMa Ling <ling.ma@intel.com>
Reviewed-by: NIan Romanick <idr@freedesktop.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

All 8xx class chips have the 66/48 split, not just 855.
Signed-off-by: NMa Ling <ling.ma@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

This patch from jbarnes and myself adds FIFO watermark control to the
driver.  This is needed for both power saving features on new platforms
with the so-called "big FIFO" and for controlling FIFO allocation
between pipes in multi-head configurations.

It's also necessary infrastructure to support things like framebuffer
compression and configuration supportability checks (i.e. checking a
configuration against available bandwidth).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This patch enables error detection by enabling several types of error
interrupts.  When an error interrupt is received, the interrupt
handler captures the error state; hopefully resulting in an accurate
set of error data (error type, active head pointer, etc.).  The new
record is then available from sysfs.  The current code will also dump
the error state to the system log.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Remove unused #include <linux/version.h>('s) in
 drivers/gpu/drm/ttm/ttm_bo_util.c
 drivers/gpu/drm/ttm/ttm_bo_vm.c
 drivers/gpu/drm/ttm/ttm_tt.c
Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

TTM need to be initialized before radeon if KMS is enabled otherwise
the kernel will crash hard.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Looks like I managed to mess up most shifts when converting from bitfields. :(

The patch below works on my Thinkpad T500 (as well as on my PowerBook,
where the previous change worked as well, maybe out of luck...). I'd
appreciate more testing and eyes looking over it though.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Tested-by: NMichael Pyne <mpyne@kde.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Some PowerMac firmwares set up a tiling surface at the beginning of VRAM
which messes us up otherwise.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Might lure userspace into trying silly things otherwise.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

smem.start is a physical address which kernel can remap to access
video memory of the fb buffer. We now pin the fb buffer into vram
by doing so we are loosing vram but fbdev need to be reworked to
allow change in framebuffer address.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Sometimes both acpi video and i915 driver are compiled as modules.
And there exists the strict dependency between the two drivers.
The acpi video bus will be unloaded in course of unloading the i915 driver.
If we unload the acpi video driver, then the kernel oops will be triggered.

Add the reference count to avoid unloading the ACPI video bus twice.
The reference count should be checked before unregistering the acpi video bus.
If the reference count is already zero, it won't unregister it again.
And after the acpi video bus is already unregistered, the reference count
will be set to zero.

http://bugzilla.kernel.org/show_bug.cgi?id=13396Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Unitialized fence register could leads to corrupted display. Problem
encountered on MacBooks (revision 1 and 2), directly booting from EFI
or through BIOS emulation.

(bug #21710 at freedestop.org)
Signed-off-by: NGrégoire Henry <henry@pps.jussieu.fr>
Signed-off-by: NEric Anholt <eric@anholt.net>

Remove wrongly added NULL_PACKETS_DURING_VSYNC setting for HDMI.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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.

Similar fix has already been pushed to the 2D driver to fix fdo bug
applied to the VBIOS reader, and things look sane).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

We used load_detect_temp flag to determine whether to set tv to the test
mode. However if the TV already has a mode set, we still need to set the
test mode to determine connection.  This results in blinking, but there is
no other reliable way to determine TV connection.

freedesktop.org bug #22035
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NEric Anholt <eric@anholt.net>

Also, 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=20951Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Previously the driver would always scale the chosen video mode to fill the
panel.  This adds 1:1 and maintain-aspect-ratio scaling modes.

v2: the drm_calloc/drm_free is replaced by kzalloc/kfree based
on Eric's suggestion.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

We need to save register state *after* idling GEM, clearing the ring,
and uninstalling the IRQ handler, or we might end up saving bogus
fence regs, for one.  Our restore ordering should already be correct,
since we do GEM, ring and IRQ init after restoring the last register
state, which prevents us from clobbering things.

I put this together to potentially address a bug, but I haven't heard
back if it fixes it yet.  However I think it stands on its own, so I'm
sending it in.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Users could accidentally enable AGP but not the Intel AGP support, and get
a DRM that doesn't probe as a result.

Bug #22358.
Signed-off-by: NEric Anholt <eric@anholt.net>

In theory now that the AGP subsystem is using struct page, we should
have on problems enabling GEM on PAE systems.
Signed-off-by: NDave Airlie <airlied@redhat.com>