Not only do the pageflip work without it at non-native modes (i.e. with
the panel fitter enabled), it also causes normal (non-pageflipped)
modesets to fail.
Reported-by: Adam Jackson <ajax@redhat.com>
Tested-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Wanted-by-for-fixes: Dave Airlie <airlied@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This regression has been introduced in
commit ca9bfa7eed
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jan 28 14:49:20 2012 +0100
drm/i915: fixup interlaced vertical timings confusion, part 1
Unfortunately that commit failed to take into account that the lvds
code does some special adjustements to the crtc timings for upscaling
an centering.
Fix this by explicitly computing crtc timings in the lvds mode fixup
function and setting a special flag in mode->private_flags if the crtc
timings have been adjusted.
v2: Add a comment to explain the new mode driver private flag,
suggested by Eugeni Dodonov.
v3: Kill the confusing and now redundant set_crtcinfo call in
intel_fixed_panel_mode, noticed by Chris Wilson.
Reported-and-Tested-by: Hans de Bruin <jmdebruin@xmsnet.nl>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43071
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to an internal workaround master list, we need to set bit 5
of register 9400 to avoid issues with color blits.
Testing shows that this seems to fix the blitter hangs when fbc is
enabled on snb, thanks to Chris Wilson for figuring this out.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Michael "brot" Groh <michael.groh@minad.de>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to the case where we are changing from one framebuffer to
another, we need to be sure that there are no pending WAIT_FOR_EVENTs on
the pipe for the current framebuffer before switching. If we disable the
pipe, and then try to execute a WAIT_FOR_EVENT it will block
indefinitely and cause a GPU hang.
We attempted to fix this in commit 85345517fe
(drm/i915: Retire any pending operations on the old scanout when switching)
for the case of mode switching, but this leaves the condition where we
are switching off the pipe vulnerable.
There still remains the race condition were a display may be unplugged,
switched off by the core, a uevent sent to notify the DDX and the DDX
may issue a WAIT_FOR_EVENT before it processes the uevent. This window
does not exist if the pipe is only switched off in response to the
uevent. Time to make sure that is so...
Reported-by: Francis Leblanc <Francis.Leblanc-Lebeau@verint.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36515
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45413
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fixup spelling in comment, noticed by Eugeni.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Noticed by staring at intel_reg_dumper diffs. Unfortunately it does
not seem to completely fix the bug.
Still, it's good to get this right, and maybe it helps someplace else.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47117
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is yet another chapter in the ongoing saga of bringing RC6 to Sandy
Bridge machines by default.
Now that we have discovered that RC6 issues are triggered by RC6+ state,
let's try to disable it by default. Plain RC6 is the one responsible for
most energy savings, and so far it haven't given any problems - at least,
none we are aware of.
So with this, when i915_enable_rc6=-1 (e.g., the default value), we'll
attempt to enable plain RC6 only on SNB. For Ivy Bridge, the behavior
stays the same as always - we enable both RC6 and deep RC6.
Note that while this exact patch does not has explicit tested-by's, the
equivalent settings were fixed in 3.3 kernel by a smaller patch. And it
has also received considerable testing through Canonical RC6 task-force
testing at https://wiki.ubuntu.com/Kernel/PowerManagementRC6. Up to date,
it looks like all the known issues are gone.
v2: improve description and reference a couple of open bugs related to
RC6 which seem to be fixed with this change.
References: https://bugs.freedesktop.org/show_bug.cgi?id=41682
References: https://bugs.freedesktop.org/show_bug.cgi?id=38567
References: https://bugs.freedesktop.org/show_bug.cgi?id=44867
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows to select which rc6 modes are to be used via kernel parameter,
via a bitmask parameter. E.g.:
- to enable rc6, i915_enable_rc6=1
- to enable rc6 and deep rc6, i915_enable_rc6=3
- to enable rc6 and deepest rc6, use i915_enable_rc6=5
- to enable rc6, deep and deepest rc6, use i915_enable_rc6=7
Please keep in mind that the deepest RC6 state really should NOT be used
by default, as it could potentially worsen the issues with deep RC6. So do
enable it only when you know what you are doing. However, having it around
could help solving possible future rc6-related issues and their debugging
on user machines.
Note that this changes behavior - previously, value of 1 would enable both
RC6 and deep RC6. Now it should only enable RC6 and deep/deepest RC6
stages must be enabled manually.
v2: address Chris Wilson comments and clean up the code.
References: https://bugs.freedesktop.org/show_bug.cgi?id=42579
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull drm main changes from Dave Airlie:
"This is the main drm pull request, I'm probably going to send two more
smaller ones, will explain below.
This contains a patch that is also in the fbdev tree, but it should be
the same patch, it added an API for hot unplugging framebuffer
devices, and I need that API for a new driver.
It also contains some changes to the i2c tree which Jean has acked,
and one change to moorestown platform stuff in x86.
Highlights:
- new drivers: UDL driver for USB displaylink devices, kms only,
should support correct hotplug operations.
- core: i2c speedups + better hotplug support, EDID overriding via
firmware interface - allows user to load a firmware for a broken
monitor/kvm from userspace, it even has documentation for it.
- exynos: new HDMI audio + hdmi 1.4 + virtual output driver
- gma500: code cleanup
- radeon: cleanups, CS optimisations, streamout support and pageflip
fix
- nouveau: NVD9 displayport support + more reclocking work
- i915: re-enabling GMBUS, finish gpu patch (might help hibernation
who knows), missed irq fixes, stencil tiling fixes, interlaced
support, aliasesd PPGTT support for SNB/IVB, swizzling for SNB/IVB,
semaphore fixes
As well as the usual bunch of cleanups and fixes all over the place.
I've got two things I'd like to merge a bit later:
a) AMD support for all their new radeonhd 7000 series GPU and APUs.
AMD dropped this a bit late due to insane internal review
processes, (please AMD just follow Intel and let open source guys
ship stuff early) however I don't want to penalise people who own
this hardware (since its been on sale for 3-4 months and GPU hw
doesn't exactly have a lifetime in years) and consign them to
using closed drivers for longer than necessary. The changes are
well contained and just plug into the driver new gpu functionality
so they should be fairly regression proof. I just want to give
them a bit of a run on the hw AMD kindly sent me.
b) drm prime/dma-buf interface code. This is just infrastructure
code to expose the dma-buf stuff to drm drivers and to userspace.
I'm not planning on pushing any driver support in this cycle
(except maybe exynos), but I'd like to get the infrastructure code
in so for the next cycle I can start getting the driver support
into the individual drivers. We have started driver support for
i915, nouveau and udl along with I think exynos and omap in
staging. However this code relies on the dma-buf tree being
pulled into your tree first since it needs the latest interfaces
from that tree. I'll push to get that tree sent asap.
(oh and any warnings you see in i915 are gcc's fault from what anyone
can see)."
Fix up trivial conflicts in arch/x86/platform/mrst/mrst.c due to the new
msic_thermal_platform_data() thermal function being added next to the
tc35876x_platform_data() i2c device function..
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (326 commits)
drm/i915: use DDC_ADDR instead of hard-coding it
drm/radeon: use DDC_ADDR instead of hard-coding it
drm: remove unneeded redefinition of DDC_ADDR
drm/exynos: added virtual display driver.
drm: allow loading an EDID as firmware to override broken monitor
drm/exynos: enable hdmi audio feature
drm/exynos: add default pixel format for plane
drm/exynos: cleanup exynos_hdmi.h
drm/exynos: add is_local member in exynos_drm_subdrv struct
drm/exynos: add subdrv open/close functions
drm/exynos: remove module of exynos drm subdrv
drm/exynos: release pending pageflip events when closed
drm/exynos: added new funtion to get/put dma address.
drm/exynos: update gem and buffer framework.
drm/exynos: added mode_fixup feature and code clean.
drm/exynos: add HDMI version 1.4 support
drm/exynos: remove exynos_mixer.h
gma500: Fix mmap frambuffer
drm/radeon: Drop radeon_gem_object_(un)pin.
drm/radeon: Restrict offset for legacy display engine.
...
* tag 'drm-intel-next-2012-03-01' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Only clear the GPU domains upon a successful finish
drm/i915: reenable gmbus on gen3+ again
drm/i915: i2c: unconditionally set up gpio fallback
drm/i915: merge gmbus and gpio i2c adpater into one
drm/i915: merge struct intel_gpio into struct intel_gmbus
i2c: export bit-banging algo functions
drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo
drm/i915: add dev_priv to intel_gmbus
drm/i915: Fix single msg gmbus_xfers writes
drm/i915: error_buffer->ring should be signed
drm/i915: Silence the error message from i915_wait_request()
drm/i915: use the new hdmi_force_audio enum more
drm/i915: No need to search again after retiring requests
drm/i915: Only bump refcnt on objects scheduled for eviction
drm/i915/bios: Downgrade the "signature missing" DRM_ERROR to debug
drm/i915: Ignore LVDS on hp t5745 and hp st5747 thin client
drm/i915: Fixes distorted external screen image on HP 2730p
intel_framebuffer_init does some basic sanity checking of the pixel format,
but is used by the plane code in addition to the primary crtc. So it
needs to contain any formats used in either place.
Add the XBGR8888 format to the checklist so the plane code can use it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
When setting overlay position with x<0, it will divide 0 and make drm
driver crash.
Signed-off-by: Hai Lan <hai.lan@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Manually resolve the conflict between the new enum drm property
helpers in drm-next and the new "force-dvi" option that the "audio" output
property gained in drm-intel-next.
While resolving this conflict, switch the new drm_prop_enum_list to
use the newly introduced enum defines instead of magic values.
Conflicts:
drivers/gpu/drm/i915/intel_modes.c
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel:
drm/i915: do not enable RC6p on Sandy Bridge
drm/i915: gen7: Disable the RHWO optimization as it can cause GPU hangs.
drm/i915: gen7: work around a system hang on IVB
drm/i915: gen7: Implement an L3 caching workaround.
drm/i915: gen7: implement rczunit workaround
For the simple KMS driver case we need some more info about what the preferred
depth and if a shadow framebuffer is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
If you need something really fancy you should be writing a real X.org driver.
v2: drop cursor information, just return an error from the cursor ioctls
and we can make userspace fallback to sw cursor in that case, cursor
info was getting too messy, best to start smaller.
Signed-off-by: Dave Airlie <airlied@redhat.com>
With base on latest findings, RC6p seems to be respondible for RC6-related
issues on Sandy Bridge platform. To work-around those issues, the previous
solution was to completely disable RC6 on Sandy Bridge for the past few
releases, even if plain RC6 was not giving any issues.
What this patch does is preventing RC6p from being enabled on Sandy Bridge
even if users enable RC6 via a kernel parameter. So it won't change the
defaults in any way, but will ensure that if users do enable RC6 manually
it won't break their machines by enabling this extra state.
Proper fix for this (enabling specific RC6 states according to the GPU
generation) were proposed for the -next kernel, but we are too late in the
release process now to pick such changes.
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
With the introduction of the PCH, we gained an LVDS presence pin but we
continued to use the existing logic that asserted that LVDS was only
supported on certain mobile chipsets. However, there are desktop
IronLake systems with LVDS attached which we fail to detect. So for PCH,
trust the LVDS presence pin and quirk all the lying manufacturers.
Tested-by: Daniel Woff <wolff.daniel@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43171
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was pointed by Jesse Barnes. The code now seems to follow the
specification but I don't have an SDVO device to really test this.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* tag 'drm-intel-next-2012-02-07' of git://people.freedesktop.org/~danvet/drm-intel: (29 commits)
drm/i915: Handle unmappable buffers during error state capture
drm/i915: rewrite shmem_pread_slow to use copy_to_user
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
drm/i915: fall through pwrite_gtt_slow to the shmem slow path
drm/i915: add debugfs file for swizzling information
drm/i915: fix swizzle detection for gen3
drm/i915: Remove the upper limit on the bo size for mapping into the CPU domain
drm/i915: add per-ring fault reg to error_state
drm/i915: reject GTT domain in relocations
drm/i915: remove the i915_batchbuffer_info debugfs file
drm/i915: capture error_state also for stuck rings
drm/i915: refactor debugfs create functions
drm/i915: refactor debugfs open function
drm/i915: don't trash the gtt when running out of fences
drm/i915: Separate fence pin counting from normal bind pin counting
drm/i915/ringbuffer: kill snb blt workaround
drm/i915: collect more per ring error state
drm/i915: refactor ring error state capture to use arrays
drm/i915: switch ring->id to be a real id
drm/i915: set AUD_CONFIG N_value_index for DisplayPort
...
This patch replaces the locking from the downclock routines with an assert
to ensure the registers are indeed unlocked. Without this patch, pre-SNB
devices would lock the registers when downclocking which would cause a
WARNING on suspend/resume with downclocking enabled.
Note: To hit this bug, you need to have lvds downclocking enabled.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson
Daniel Vetter
Eugeni Dodonov
Linus Torvalds
Dave Airlie
Jesse Barnes
Philipp Grete
Alban Browaeys
Hai Lan
Paulo Zanoni
Sean Paul