We should use current channel 'status' bits to clear DP aux channel's
done and error bits, instead of using the channel setting bits, that
will set send/busy bit again to initiate new transaction.
This also includes also some minor cleanup.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
During pipe DPMS off, instead of busy waiting pipe off, insert
delays during wait and don't loop after enough tries which matches
spec requirement. Also try to match DPMS on path by disable FDI TX
PLL in DPMS off. Disable PF by writing PF_WIN_SZ which really trigger
the update.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This does VGA disable like DDX driver. SR01 bit 5 should be set
before VGA plane disable through control register, otherwise we
might get random crash and lockups.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Now the DVO timing in LVDS data entry is obtained by using the
following step:
a. get the entry size for every LVDS panel data
b. Get the LVDS fp entry for the preferred panel type
c. get the DVO timing by using entry->dvo_timing
In our driver the entry->dvo_timing is related with the size of
lvds_fp_timing. For example: the size is 46.
But it seems that the size of lvds_fp_timing varies on the differnt
platform. In such case we will get the incorrect DVO timing entry
because of the incorrect DVO offset in LVDS panel data entry.
This also removes a hack on new IGDNG to get proper DVO timing.
Calculate the DVO timing offset in LVDS data entry to get the DVO timing
a. get the DVO timing offset in the LVDS fp data entry by using the
pointer definition in LVDS data ptr
b. get the LVDS data entry
c. get the DVO timing by adding the DVO timing offset to data entry
https://bugs.freedesktop.org/show_bug.cgi?id=22787
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
According to investigations from windows team ,hw team,
and our test results on all 4x platofrms available
(gm45, g45b, q45, g45a, g45c, g41a, and g41), we find
currently Hot plug live status and Hot plug interrupt
detection are not reliable, sometime the results from
the two approaches are contradicts. So we chose edid
detection for hdmi output.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
If no planes are enabled, the self-refresh calculation may end up doing
a divide by zero. This patch should prevent that by making sure at
least one of the CRTCs had a valid hdisplay value.
Reported-by: Eric Anholt <eric@anholt.net>
Tested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
If you're pushing a plane hard (i.e. you need most or all of the FIFO
entries just to cover your frame refresh latency), the watermark level
may end up being negative. So fix up the signed vs. unsigned math in
the calculation function to handle this correctly, giving all available
FIFO entries to such a configuration.
Reported-by: Eric Anholt <eric@anholt.net>
Tested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
I discovered several bugs in the FIFO code that was recently applied.
Some of them fell into the "how did this ever work" category, since in
some cases we were using the wrong FIFO size values, and the
calculations ended up being way off.
This patch fixes all the bugs I found, and works well on my GM45, 915GM
and 855GM test machines; but as usual with these sorts of patches
broader testing is definitely requested (in particular this patch
affects 830, 845 and 865 for which I don't have test hardware).
Overall, the patch clarifies the watermark calculation function by
adding some comments and debug info, and making the variable names a
bit clearer. The "get FIFO size" portion of the code has also been
corrected, so we should be able to properly detect the FIFO allocations
for each pipe, for use in the watermark calculation.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
This motherboard thinks it has an LVDS connected, so without this
patch the screen goes blank on the connected VGA monitor. More
information (for the non-KMS case) in fd.o bug #18004.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The 915 and 945 scanout engines can handle frame buffers up to 4096 pixels
wide. Pre-9xx hardware has an 8192 byte stride limit, and so we leave the
existing 2048 max in place.
I'm not sure why we limit the height to the same value; there's no intrinsic
hardware limit in the scanout engine.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This patch refactors the existing error detection and collection code,
placing most of it in i915_handle_error(). Additionally, we introduce a
work queue for scheduling post-crash tasks such as generating a uevent.
Using the uevent facility, userspace should be able to capture a
post-mortem dump for diagnostics.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Vbios will set lvds register correctly based on
current algorithm for lingle/dual Channel LVDS when
system boot, so we can accept this configuration
directly, regardless of LVDS enable status.
It fixed freedesktop.org bug #22262
Signed-off-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Zhenyu Wang <zhenyu.z.wang@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
As of 52dc7d32b8, 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: Eric 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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric 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: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric 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: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian 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=21496http://bugs.freedesktop.org/show_bug.cgi?id=21856http://bugs.freedesktop.org/show_bug.cgi?id=21127
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[anholt: squashed in style fixups]
Signed-off-by: Eric Anholt <eric@anholt.net>
Make this consistent with the unlock statement. Also fix a
minor typo in debugfs formatting
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This is quite useful for verifying that objects are actually mapped when
they need to be.
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Eric 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: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Eric 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: Ma Ling <ling.ma@intel.com>
Signed-off-by: Eric 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: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric 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: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric 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: Andy Whitcroft <apw@canonical.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric 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: Ma Ling <ling.ma@intel.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
All 8xx class chips have the 66/48 split, not just 855.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric 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: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Eric 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: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
TTM need to be initialized before radeon if KMS is enabled otherwise
the kernel will crash hard.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave 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: Michel Dänzer <daenzer@vmware.com>
Tested-by: Michael Pyne <mpyne@kde.org>
Signed-off-by: Dave 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: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Might lure userspace into trying silly things otherwise.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave 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: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave 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=13396
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len 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: Grégoire Henry <henry@pps.jussieu.fr>
Signed-off-by: Eric Anholt <eric@anholt.net>
Remove wrongly added NULL_PACKETS_DURING_VSYNC setting for HDMI.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric 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: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric 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: Ma Ling <ling.ma@intel.com>
Signed-off-by: Eric 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=20951
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric 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: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Zhenyu Wang